>I haven't tried > >export CC=gcc >export CXX=g++ > >in a while, but they used to always "just work" for me To be honest it wouldn't surprise me if it is linked to how the intel compiler is installed on my system. I can probably remove it as we have a distributed system and the applications are installed at each login.
>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? I have added a 100 ms delay into my code and so far (fingers crossed) I have seen no hangs. On centos I have to date not been able to get the new wxWidgets driver to run at all due to the missing library problem I reported previously. Phil On 24 January 2015 at 20:35, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > 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
