On Wed, Dec 8, 2010 at 6:24 PM, Alan W. Irwin <[email protected]> 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., > > w...@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. > > softw...@raven> cmake -DCMAKE_INSTALL_PREFIX=/tmp/cmake_install \ > ~/cmake/cmake-2.8.3 >& cmake.out > softw...@raven> cmake --version > cmake version 2.8.3 > softw...@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: > > softw...@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 > [email protected] > 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 _______________________________________________ cmake-developers mailing list [email protected] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
