On 2015-01-24 16:51-0000 Phil Rosenberg wrote: > Hi Alan > I'm replying to this without my code in front of me, but I wanted to > keep you informed. > >> you can use the CC and CXX environment variables >> _before_ you invoke cmake in an empty build directory, e.g., >> >> export CC="gcc -g" >> export CXX="g++ -g" > I tried that without the -g but it had no effect. I will try with the > -g when I'm back in.
I haven't tried export CC=gcc export CXX=g++ in a while, but they used to always "just work" for me whether or not I added additional compiler options such as -g (which also used to "just work"). And I just checked the CMake-3.0.2 module code, and it appears it still looks for the CC and CXX environment variables. But if you really cannot get it to work with your version of CMake, then let me know that version of CMake, and I will try it here (and if I can confirm the issue I will report it as a CMake regression). >>> [...]So once I get to the bottom of the hangs I will try to sort out the >>> remaining rendering problems and memory leaks. >> >> I did not experience any hangs myself > I have been trying to get past this. I just found out how to attach a > gdb session to a running process and found that the hang occurs in > some gtk module and is a threading deadlock. It occurs before the > first frame is even initialised - the threading is occurring in gtk by > the way, I am not doing any multithreading. So it turns out my > instinct about multiprocess code was correct - it was just that it is > gtk threads that are at fault not my multiprocess code. This problem > has been described by others at > https://forums.wxwidgets.org/viewtopic.php?t=37151&p=151356, and then > at http://trac.wxwidgets.org/ticket/16202. The wxWidgets devs have > blamed an Ubuntu bug, but have put a workaround in their code - > http://trac.wxwidgets.org/changeset/76398/svn-wx. Unfortunately it is > only 9 months old so I guess it will only be in trunk. A workaround > was mentioned on the forum of adding a delay in the initialisation so > I guess I will have to do this. >From the above URL's the speculative consensus seems to be this ugly hang issue is due to some long-standing (many different Ubuntu versions apparently show the wxwidgets hang problem) Ubuntu modification of GTK+. And that hypothesis of Ubuntu-only seems to be confirmed not only by my experience (no hangs on two separate wxwidgets platforms) but also the no-hang experience of many other Linux wxwidgets users. Furthermore, on Ubuntu the timeout fix did not work for all users and the more official fix above (which does not involve timeouts as far as I can tell) is a speculative one. So my advice is to give up on Ubuntu wxwidgets for a development platform until that more official fix propagates and actually is proved to fix the issue. So do you confirm no-hangs (so far) on your CentOS? If so, I would stick with that platform for your development work or use an epa_built result on any Linux platform since that is apparently free of hangs as well (since it builds not only wxwidgets, but an unmodified form of the GTK+ software packages it depends on). In case you are interested in trying the epa_build approach here is the cookbook. 1. Set up required environment variables. source ~software/plplot/HEAD/plplot.git/cmake/epa_build/setup/setup_linux_makefiles (Note you would have to tailor your equivalent of cmake/epa_build/setup/setup_linux_makefiles for your own needs such as your preferred cmake version, the install prefix for all epa_built packages, your preferred compiler flags, etc.) 2. Clean start. Empty your previous build tree and completely remove your previous install tree for epa_build. In my case, I did that with rm -rf /home/wine/newstart/build_script/build_dir-linux/* \ /home/wine/newstart/build_script/install-linux 3. Change directory to empty build tree In my case, cd /home/wine/newstart/build_script/build_dir-linux/ 4. Configure epa_build (this takes advantage of environment variables that are automatically set up as part of sourcing your equivalent of cmake/epa_build/setup/setup_linux_makefiles cmake -DCMAKE_VERBOSE_MAKEFILE=ON -G"$GENERATOR_STRING" \ -DCMAKE_INSTALL_PREFIX:PATH=${INSTALL_PREFIX} \ -DBUILD_THE_BUILDTOOLS=OFF $EPA_BUILD_SOURCE_PATH >& cmake.out 5. Build wxwidgets and the subset of the GTK+ sofware packages it depends on. (This took 45 minutes in my case.) time make build_wxwidgets >& build_wxwidgets.out 6. Let subsequent invocations of CMake find this new wxwidgets version by putting the new wx-config on your PATH In my case PATH=${INSTALL_PREFIX}/bin:$PATH 7. Check the results to see what system dependencies are still left in the epa_built version. ldd ${INSTALL_PREFIX}/lib/libwx_gtk3u_core-3.0.so | \ grep -v ${INSTALL_PREFIX} linux-vdso.so.1 => (0x00007fff673b2000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe48df4e000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fe48d8b3000) libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007fe48d6ac000) libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007fe48d4a5000) libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007fe48d27e000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe48d066000) libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007fe48ce2c000) libtiff.so.4 => /usr/lib/x86_64-linux-gnu/libtiff.so.4 (0x00007fe48cbc6000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe48c9c1000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe48c2a7000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe48bf9f000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe48bd89000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe48bb6d000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe48b7e1000) libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007fe48b5df000) libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007fe48b3d7000) libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007fe48b1cc000) libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007fe48ad60000) libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007fe48ab5d000) libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007fe48a95b000) libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007fe48a755000) libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007fe48a290000) libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007fe48a086000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fe489e65000) libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007fe489c5c000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fe489a4a000) libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007fe4893d3000) libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007fe48918c000) libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fe48885f000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fe488445000) /lib64/ld-linux-x86-64.so.2 (0x00007fe4909a6000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fe488037000) libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 (0x00007fe487e28000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fe487c25000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fe487a1f000) This is certainly still a long list of system dependencies (i.e., libraries not built (yet) by epa_build, but it does appear epa_build has done its job because these all appear to be fundamental system libraries and not system libraries that are normally part of wxwidgets or GTK+. If you do decide to try an epa_built version of wxwidgets and all its GTK+ dependencies, I would be happy to help with any issues you might find. However, I honestly think there will be no issues at all (assuming you have working compilers) since I have just done all the above steps myself, and all those steps are so straightforward so long as your system has the *.so versions (which are installed by installing development versions of the X, etc., packages) of all the above system libraries installed. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
