Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wxwidgets use script issues #210

Closed
smanders opened this issue Aug 20, 2018 · 6 comments
Closed

wxwidgets use script issues #210

smanders opened this issue Aug 20, 2018 · 6 comments
Assignees
Labels
Milestone

Comments

@smanders
Copy link
Owner

the use script should only add an imported wx library if the target doesn't already exist

@smanders smanders added the bug label Aug 20, 2018
@smanders smanders added this to the current milestone Aug 20, 2018
@smanders smanders self-assigned this Aug 20, 2018
smanders pushed a commit that referenced this issue Aug 20, 2018
@smanders
Copy link
Owner Author

commit diff ignoring whitespace 3be2406?w=1

@smanders
Copy link
Owner Author

smanders commented Aug 21, 2018

a current scenario is to build externpro on CentOS 6 and then use the built-on-CentOS-6 version of externpro to build other projects on CentOS 7 -- not really a supported scenario, but something that's currently happening anyway

we're now seeing link errors on CentOS 7

/opt/rh/devtoolset-6/root/usr/libexec/gcc/x86_64-redhat-linux/6.2.1/ld: /opt/extern/externpro-18.08.3-gcc621-64-Linux/lib/libwx_gtk2u_core-3.1.a(corelib_gtk_app.o): undefined reference to symbol 'g_thread_init'
//lib64/libgthread-2.0.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
gmake[2]: *** [Tools/Maps/ElevTest] Error 1

https://isrhub.usurf.usu.edu/petemace/VantageSuper/pull/2777#issuecomment-114074

@smanders
Copy link
Owner Author

explanation of the cause of the link error

the recent changes 0072ddd#diff-1fd8734340c4afa901342dce6ea97a39 to the wx use script (to set IMPORTED targets) basically changed us from using wxWidgets_LIBRARIES (populated by find_package(wxWidgets call) to building up our own list of wx libs and dependencies (for example wxcore dependencies in the cmake list _wx_core_libs: https://github.com/smanders/externpro/blob/18.08.3/projects/use/usexp-wxwidgets-config.cmake#L91-L102)

wxWidgets_LIBRARIES was consistent between CentOS 6 and 7 because it uses some form of wx-config --libs (line breaks inserted to improve readability):

$ {smanders@lin-compile2} /opt/extern/externpro-18.08.3-gcc621-64-Linux
   08/21 10:56:13  > ./bin/wx-config --prefix=. --libs
-L./lib -pthread   
./lib/libwx_gtk2u_xrc-3.1.a 
./lib/libwx_gtk2u_qa-3.1.a 
./lib/libwx_baseu_net-3.1.a 
./lib/libwx_gtk2u_html-3.1.a 
./lib/libwx_gtk2u_adv-3.1.a 
./lib/libwx_gtk2u_core-3.1.a 
./lib/libwx_baseu_xml-3.1.a 
./lib/libwx_baseu-3.1.a 
-pthread -lX11 -lXxf86vm -lSM -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 
-latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 
-lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 
-lgthread-2.0 -lrt -lglib-2.0 
-lwxregexu-3.1 -lwxexpat-3.1 -lwxtiff-3.1 -lwxjpeg-3.1 -lwxpng-3.1 -lwxzlib-3.1 
-ldl -lm 

the problem was that the paths to the wx libraries were absolute and specific to the build system - which would mess up cmake-generated targets files of internpro projects that depend on wx and boost (see issue #194)

so to get the gtk libraries (that you see in wx-config --libs above) I resorted to using pkg-config to get the list https://github.com/smanders/externpro/blob/18.08.3/projects/use/usexp-wxwidgets-config.cmake#L92-L97

however, it appears that there are differences here between CentOS 6 and 7

CentOS 6
$ {smanders@lin-compile2} /opt/extern/externpro-18.08.3-gcc621-64-Linux
   08/22 09:41:05  > pkg-config gtk+-2.0 --modversion
2.24.23

$ {smanders@lin-compile2} /opt/extern/externpro-18.08.3-gcc621-64-Linux
   08/22 09:41:11  > pkg-config gtk+-2.0 --libs
-pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 
-lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 
-lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0  
CentOS 7
-bash-4.2$ pkg-config gtk+-2.0 --modversion
2.24.31
-bash-4.2$ pkg-config gtk+-2.0 --libs
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 
-lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype

notice that gthread-2.0 is missing from CentOS 7? hence the link error

smanders pushed a commit that referenced this issue Aug 22, 2018
* continue to use pkg-config to find GTK3 (there is no FindGTK3.cmake provided by cmake)
* the FindGTK2.cmake appears to find all the correct gtk2 libraries
* using pkg-config to find GTK2 resulted in differences between CentOS 6 and 7
* issue #210 (comment)
@smanders
Copy link
Owner Author

commit diff ignoring whitespace c99b555?w=1

@smanders
Copy link
Owner Author

I held this issue open for a little while to see if I was going to need to somehow detect whether GL and GLU needed to be specified as dependencies for the wx gl library https://github.com/smanders/externpro/blob/18.08.3/projects/use/usexp-wxwidgets-config.cmake#L109 -- everything and everywhere I've built and linked (Ubuntu, CentOS) hasn't required GL and GLU, but that isn't too say that it won't be needed at some point... I just have hesitated to require them and I'm not even sure the best way to detect that they're on the system and required

wx.cmake does require that OpenGL is found (during cmake-step of externpro build) https://github.com/smanders/externpro/blob/18.08.3/projects/wx.cmake#L59-L68 - it just seems heavy-handed to require projects using wxWidgets from externpro to also have OpenGL development packages installed when they may not even need the wx gl library

From: Brett Francis
Sent: Thursday, August 23, 2018 3:00 PM
To: Vantage_SysEngr
Cc: VIPC_PMs; Steven Woolsey; Scott M Anderson; Chris Heaps
Subject: RC23 and failed to load libGLU.so.1

System Guys,

After looking at the RC23 issue, we believe that we have identified the source of the problem.

It appears that the DRACO plugin is the source of the dependency on libglu1-mesa package and not VANTAGE. It appears that we have been masking this dependency because VANTAGE has been causing libglu1-mesa packate to be installed up to RC22. With RC23, this dependency was removed. It appears that the reason the product generators didn’t come up cleanly and that you couldn’t run workflows was because we couldn’t load DRACO without this library. Removing the DRACO plugin appeared to leave VANTAGE in a working state.

This is my understanding, we can do more testing to confirm if needed.
For now

  1. VANTAGE will not be changing to force the load of the libglu1-mesa package.
  2. The DRACO plugin will need to modified and add this dependency in a future version. This won’t happen for 3.50 unless management directs us to do so.
  3. The system will have to load this library if using the DRACO plugin.

Thanks,
Brett

the VANTAGE RPM doesn't specify any of it's runtime dependencies... yet somehow it appears that yum was detecting libglu1-mesa as a dependency and was installing it with VANTAGE -- until the externpro 18.08 releases which stopped using wx-config --libs (which had the gl libraries in the list)

now it appears that the DRACO plugin (which uses externpro 17.05.1 and VantageShared from the VANTAGE_3-46-1 tag) requires libglu1-mesa (probably because of wx...)

@smanders
Copy link
Owner Author

completed with commits (to the dev branch) referenced above

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant