Re: [Boost-build] Need help testing whether Boost Jam compiles on different platforms.

Subject: Re: [Boost-build] Need help testing whether Boost Jam compiles on different platforms.
From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2012-08-27 08:38:03

   Hi.

>>    Could someone please try to compile it under other platforms?
>> Especially, some unix/linux variants and mingw.
>
> At [1] are build logs for the following platforms and compilers:
>
> * AIX 5.3 - gcc, vacpp
> * Ubuntu Lucid (10.04) - gcc, intel-linux, pathscale, pgi
> * OS X 10.7.4 (XCode 4.4.1) - darwin, gcc
> * Ubuntu Precise (12.04) - gcc
> * Solaris 10 - gcc, sun
> * Windows 7 (mingw-w64 4.7.1) - mingw64, vc10, vc9

   Wow, thanks! Everything I could have wished for and more... :-)

   I've gone through the logs now and fixed what I could.

   I've noticed that the unpatched logs for Windows builds made using 
build.bat start with 'The system cannot find the batch label specified - 
Test_Option'. Since 'Test_Option' is a valid label in that batch file, 
I'm assuming you ran those builds using some sort of an automated setup 
which modifies the build.bat file while it is still running - generally 
a no-no for Windows batch files.

> A quick skimming of the logs reveals that the sun toolset seems to have
> gone crazy with the changes.

   As it seems to be complaining about 'invalid whitespace' in lines 
that surely have no syntax errors in them - it could be that 
Windows-style line endings are confusing it.

> Other toolsets complain about implicit declarations for some things.
> Disregard the linker errors from GCC on AIX, it has never been able to
> link anything but it can compile things.

   So far I've committed the following:

http://svn.boost.org/trac/boost/changeset/80249
   Should clean up 'undeclared function' warnings displayed when 
compiling the class.cpp module using your win7-mingw64, precise, 
osx-darwin & aix53-gcc toolsets (not touched by the original patch).

http://svn.boost.org/trac/boost/changeset/80251
   Fixed a 'pointer to integer of different size' warning displayed when 
building the function.c module using your win7-mingw64 toolset (not 
touched by the original patch).

http://svn.boost.org/trac/boost/changeset/80252
   Fixed a 'OBJECT * to char *' gcc compilation warning displayed when 
compiling the function.c module using your precise, osx-darwin & 
lucid-intel_linux toolsets (not touched by the original patch).

http://svn.boost.org/trac/boost/changeset/80253
   Fixed a '&& within ||' gcc warning displayed when compiling the 
make1.c module using your osx-darwin toolset (not touched by the 
original patch).

http://svn.boost.org/trac/boost/changeset/80255
   Fixed an 'implicitly declared atoi() function' gcc warning displayed 
when compiling the modules/sequence.c module using your osx-darwin & 
lucid-intel_linux toolsets (not touched by the original patch).

http://svn.boost.org/trac/boost/changeset/80256
   Fixed an 'implicitly declared atoi() function' gcc warning displayed 
when compiling the fileunix.c module using your osx-darwin toolset (not 
touched by the original patch).

http://svn.boost.org/trac/boost/changeset/80259
   Added a missing header #include in Boost Jam's mem.h header used when 
compiling with memory allocation profiling support. Fixes related 
'implicitly declared profile_memory() function' gcc compilation warnings 
diplayed when compiling modules/regex.c & modules/order.c modules using 
your osx-darwin toolset (not touched by the original patch).

http://svn.boost.org/trac/boost/changeset/80260
   Fixed an 'dropping qualifiers' intel warning displayed when compiling 
the fileunix.c module using your lucid-intel_linux toolset (not touched 
by the original patch).

   Related to these warnings - here are some I have no idea how to avoid:

     * lucid-intel_linux toolset - function.c(2154): warning #279:
       controlling expression is constant assert( !"invalid result
       location" );

     * Rather terse warnings given by the lucid-pgi toolset. I'll see
       if I can do anything about those at the end as I guess that will
       take several change/retest round-trips to figure our what exactly
       it's complaining about.

   Anyone else have any suggestions on how to avoid these?

> Don't forget to make build.sh executable, unless that's magically
> handled by the version control.

   That is not a new file and has already been marked as an executable 
in the Subversion repository.

   I've updated the pathunix.c patched module with a missing #include 
and am attaching all the patched files in two separate archives this 
time - once with Windows and once with Unix-style line endings.

   Could you rerun the newly attached tests when you get the time, 
please? And if rerunning the sol10-sun toolset, use the Unix-style 
line-endings version.

   Thanks for your help!

   Best regards,
     Jurko Gospodnetić