[cmake-developers] Parallel build of cmake-2.8.3 intermittently fails using "MinGW Makefiles" generator under wine

David Cole david.cole at kitware.com
Thu Dec 9 06:24:49 EST 2010


On Wed, Dec 8, 2010 at 6:24 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca> wrote:
> On 2010-12-04 22:16-0800 Alan W. Irwin wrote:
>
>> So "MinGW Makefiles" is a reasonable workaround for the parallel build
>> troubles I was having with the "MSYS Makefiles" generator on wine.
>> However, I think the next step in debugging those troubles is for
>> somebody with access to Microsoft Windows to try to verify those
>> troubles using the latest MinGW/MSYS tool chain you get with the
>> automatic installer.
>
> Well, I did some further experiments with "MSYS Makefiles" which all
> failed.  Then I tried a clean parallel build of cmake again using
> "MinGW Makefiles".  This time it also failed using exactly the same
> "MinGW Makefiles" build script that previously succeeded. So it
> appears both the "MSYS Makefiles" and "MinGW Makefiles" generators
> create unreliable parallel builds of cmake under wine.
>
> Intermittent failure/success like this is common when there are
> dependency troubles in a project's source code (in this case,
> cmake-2.8.3) since whether or not an error is generated depends
> critically on the timing of the various components of the build.
> Also, the wine development environment toolchain is quite slow so its
> timing is going to be quite different than a Linux build or MS windows
> build on the same machine.
>
> I have attached the compressed (gzip) cmake output and the make -j4
> output for any CMake developer that want's to analyze this "MinGW
> Makefiles" failed parallel build on wine in some detail.  However, it
> appears to me that the critical issue is some of the static libraries
> are getting linked twice, e.g.,
>
> wine at raven> grep "^Linking.*\.a" make_install.out
> Linking CXX static library libcmsys.a
> Linking C static library libcmsys_c.a
> Linking C static library libcmlibarchive.a
> Linking C static library libcmzlib.a
> Linking C static library libcmzlib.a
> Linking C static library libcmcurl.a
> Linking C static library libcmcurl.a
> Linking C static library libcmbzip2.a
> Linking C static library libcmcompress.a
> Linking C static library libcmexpat.a
> Linking CXX static library libCMakeLib.a
>
> It is that second link attempt of libcmcurl.a that causes the critical
> "Z:\home\wine\newstart\MinGW\bin\ranlib.exe: 'libcmcurl.a': No such
> file" error for this particular parallel build using "MinGW
> Makefiles".  Note, on my previous "MinGW Makefiles effort that
> finished without errors, I noticed the same double linking messages,
> but apparently for that run, the time when those double linking
> attempts overlapped was sufficiently different that it didn't cause
> the "file not found" error.
>
> To investigate further, under Linux with the usual gcc tool chain,
> gmake, etc., I did a parallel build of cmake following what was done
> for the wine build above.
>
> software at raven> cmake -DCMAKE_INSTALL_PREFIX=/tmp/cmake_install \
> ~/cmake/cmake-2.8.3 >& cmake.out
> software at raven> cmake --version
> cmake version 2.8.3
> software at raven> make -j4 install >& make_install.out
>
> That finished without obvious errors.  I haven't bother attaching
> those *.out files,  but there were duplicate linking messages
> in this case as well:
>
> software at raven> grep "^Linking.*\.a" make_install.out Linking C static
> library libcmzlib.a
> Linking C static library libcmcompress.a
> Linking C static library libcmbzip2.a
> Linking C static library libcmbzip2.a
> Linking C static library libcmexpat.a
> Linking CXX static library libcmsys.a
> Linking C static library libcmlibarchive.a
> Linking C static library libcmlibarchive.a
> Linking C static library libcmForm.a
> Linking C static library libcmcurl.a
> Linking C static library libcmcurl.a
> Linking CXX static library libCMakeLib.a
> Linking CXX static library libCMakeLib.a
> Linking CXX static library libCPackLib.a
> Linking CXX static library libCTestLib.a
>
> Does this mean the duplicate linking messages (which both for wine and
> Linux occur only for some of the static libraries) are some artifact
> that should be ignored pending a bug fix to clean that up, or does it
> mean the links are actually happening twice on Linux as well?  If the
> latter, that means the potential also exists under Linux to have
> errors due to duplicate link steps, but because the component timing
> is different under Linux than it is under wine, by chance no error is
> currently generated under Linux.
>
> My next step is to try a parallel build of PLplot under wine using
> both generators.  The PLplot build does not use quite as many
> instances of add_custom_command (with the potential to screw up
> associated target and file dependencies) as the CMake build (118
> instances for PLplot versus 180 instances CMake), but nevertheless it
> is a good test of whether either/both the "MinGW Makefiles" and "MSYS
> Makefiles" generators are capable of producing reliable parallel
> builds with a completely independent and quite complex build system.
>
> Meanwhile, I would appreciate some response here from the CMake
> developers at least about the duplicate Linking message issue noted
> above as well whether they have ever seen a reliable parallel build of
> cmake-2.8.x with either of the "MSYS Makefiles" or "MinGW Makefiles"
> generators?
>
> 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); PLplot scientific plotting software
> package (plplot.org); 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
> __________________________
> _______________________________________________
> cmake-developers mailing list
> cmake-developers at cmake.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
>
>

We generate "ok to use with parallel make" makefiles on all platforms
to the best of our knowledge. If parallel make doesn't work on a
certain platform, then it is likely a deficiency of the make on the
platform...

This seems like it would be a problem independent of CMake: do you
build other large (non-CMake-driven) projects successfully in parallel
on this platform?

I'm not sure about the duplicate "Linking ... library" messages.
Hopefully Brad or Bill will chime in on this one.


David



More information about the cmake-developers mailing list