[CMake] CMake 2.8.6-rc3 ready for testing!

David Cole david.cole at kitware.com
Tue Sep 20 16:21:06 EDT 2011


On Tue, Sep 20, 2011 at 4:14 PM, Alan W. Irwin
<irwin at beluga.phys.uvic.ca> wrote:
> On 2011-09-20 13:01-0700 Alan W. Irwin wrote:
>
>> On 2011-09-20 11:56-0700 Alan W. Irwin wrote:
>>
>>> I don't want to overly dilute what seems to be your really important
>>> message that there are serious build problems for cmake-2.8.6-rc3, but
>>> if nothing else, your post should galvanize lots of testing of
>>> cmake-2.8.6-rc3 which is a "good thing".  When I did such build
>>> testing myself, the optimized build of PLplot appears to be OK for
>>> cmake-2.8.6-rc3 on at least my platform.
>>
>> P.S. I should have mentioned that the bug concerned FindThreads.cmake,
>> and the PLplot build system does use "find_package(Threads)" for the
>> xwin device driver.  So I am a bit surprised I am not seeing the issue
>> for an optimized build that includes that device driver.
>
> P.P.S.  Strike that.  I found the issue at PLplot run-time, not build
> time for CMake-2.8.6-rc3 (probably because the PLplot library
> dynamically loads device drivers such as xwin).  So I strongly second
> Orion's call for a fix before 2.8.6 is released.
>
> Here is the evidence:
>
> software at raven> examples/c/x01c -dev xwin
> PLplot library version: 5.9.8
> examples/c/x01c: symbol lookup error:
> /home/software/plplot_svn/HEAD/build_dir/drivers/xwin.so: undefined
> symbol: pthread_mutexattr_init
>
> software at raven> ldd -r drivers/xwin.so |grep undefine
> undefined symbol: pthread_mutexattr_settype     (drivers/xwin.so)
> undefined symbol: pthread_create        (drivers/xwin.so)
> undefined symbol: pthread_mutexattr_init        (drivers/xwin.so)
> undefined symbol: pthread_cancel        (drivers/xwin.so)
> undefined symbol: pthread_join  (drivers/xwin.so)
>
> Thanks, Orion, for catching this problem.  Recently, I have become
> quite lazy about testing cmake RC's because normally they just
> work.  But cmake-2.8.6-rc3 is definitely an exception to that
> rule and a general wakeup call for everyone to thoroughly test
> the CMake RC's both at build time _and_ run time.
>
> 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
> __________________________
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>

I will be reverting the commits associated with the bad bug fix
mentioned here, so that we will end up with "equivalent to 2.8.5"
behavior with respect to this.

We'll have to shoot for a real fix for next time.

Thanks,
David


More information about the CMake mailing list