Re: Comments on new gcc-nocygwin-tools.jam?

From: Raoul Gough (raoulgough_at_[hidden])
Date: 2003-01-22 08:25:12

From: "William E. Kempf" <wekempf_at_[hidden]>
Sent: Wednesday, January 22, 2003 7:22 AM

> Hmmm... I didn't have any troubles at all. I replaced the content
of
> gcc-nocygwin-tools.jam with what you have above, and ran "bjam
> -sTOOLS=gcc-nocygwin test" in the $BOOST/libs/thread/test directory,
which
> built all of the Boost.Threads and Boost.Test libraries, as well as
the
> test harness for Boost.Threads, and ran the resulting executables.
> Everything worked fine (minus a couple of runtime bugs found for
this
> "new" toolset in the Boost.Threads library). This was all done on a
> recently updated CVS repository.

Hi William,

I'm a bit concerned about the build problems with the new gcc-nocygwin
toolset (the ones that don't arise on your system). I've fixed the
problems on my system, but I can't understand why it worked for you
without the fixes. If you can spare a couple of minutes for this, it
would be good to confirm the following points on your system:

1. Is the toolset really building cygwin-independant code?
2. Is it doing so with the cygwin compiler?

Number 1. is easy to confirm, since you can just run objdump -p on
boost_thread.dll, for instance, and grep for "DLL Name". On my system
(from the libs/thread/test directory) it looks like this:

$ objdump -p
../build/bin/boost_thread.dll/gcc-nocygwin/release/runtime-link-dynami
c/threading-multi/boost_thread.dll | grep 'DLL Name'
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: msvcrt.dll

Which is a cygwin-independant DLL. In constrast, if I build using the
plain gcc-tools, the resulting DLL has the following:

$ objdump -p
../build/bin/boost_thread.dll/gcc/release/runtime-link-dynamic/threadi
ng-multi/boost_thread.dll | grep 'DLL Name'
DLL Name: cygwin1.dll
DLL Name: KERNEL32.dll

Number 2. is a bit messier to confirm, but you can check it by adding
a "-v" to CLAGS in the new gcc-nocygwin-tools.jam (i.e. CFLAGS
+= -mno-cygwin -v ;) and examining the volumes of gcc output that
result. I've commented some of the major points below:

$ # Force recompilation of an object file
$ rm
../build/bin/boost_thread.dll/gcc-nocygwin/release/runtime-link-dynami
c/threading-multi/condition.obj
$ bjam -sTOOLS=gcc-nocygwin test
...patience...
...found 1021 targets...
...updating 21 targets...
gcc-C++-action
..\..\..\libs\thread\build\bin\boost_thread.dll\gcc-nocygwin\release\r
untime-link-dynamic\threading-multi\condition.obj

***** Specs should be somewhere in the Cygwin installation:

Reading specs from /usr/local/lib/gcc-lib/i686-pc-mingw32/3.2/specs
Configured with: ../../../CVS/gcc/configure
Thread model: single
gcc version 3.2 20021118 (prerelease)

***** cc1plus should also be within Cygwin:

/usr/local/lib/gcc-lib/i686-pc-mingw32/3.2/cc1plus.exe -v -I..\..\..\l
ibs\thread\build -I
d:\boost\CVS\boost -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL
__=0 -D__GXX_ABI_VERSION=102 -D_X86_=1 -D_X86_=1 -Asystem=winnt -D__OP
TIMIZE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386
-D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ -D__tune_pentium2__ 
-D__tune_pentium3__ -D__stdcall=__attribute__((__stdcall__)) -D__fastc
all=__attribute__((__fastcall__)) -D__cdecl=__attribute__((__cdecl__))
-D_stdcall=__attribute__((__stdcall__)) -D_fastcall=__attribute__((__
fastcall__)) -D_cdecl=__attribute__((__cdecl__))-D__declspec(x)=__attr
ibute__((x)) -D__i386__ -D__i386 -D__MSVCRT__ -D__MINGW32__ -D_MT -DWI
N32 -D_WIN32 -D__WIN32 -D__WIN32__ -DWINNT -isystem
/usr/lib/../include/w32api -isystem/usr/local/lib/gcc-lib/i686-pc-ming
w32/3.2/../../../../../include/w32api -DNDEBUG -DBOOST_THREAD_BUILD_DL
L=1
..\..\..\libs\thread\build\../src\condition.cpp -D__GNUG__=3 -D__DEPRE
CATED -D__EXCEPTIONS -quiet -dumpbase
condition.cpp -mthreads -mno-cygwin -O3 -Wall -Wno-inline -version -ft
emplate-depth-100 -finline-functions -o /cygdrive/f/Temp/ccA0xk92.s
GNU CPP version 3.2 20021118 (prerelease) (cpplib) (80386, BSD syntax)

***** Target is i686-pc-cygwin (even with the -mno-cygwin option):

GNU C++ version 3.2 20021118 (prerelease) (i686-pc-cygwin)
compiled by GNU C version 3.2 20021118 (prerelease).
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory
"/usr/local/i686-pc-mingw32/include/usr/include/mingw"
ignoring duplicate directory "/usr/include/w32api"
ignoring duplicate directory "/usr/include/mingw"
#include "..." search starts here:
#include <...> search starts here:
../../../libs/thread/build
d:/boost/CVS/boost
/usr/include/w32api
/usr/local/include/c++/3.2

***** Include path should include some i686-pc-mingw32 stuff

/usr/local/include/c++/3.2/i686-pc-mingw32
/usr/local/include/c++/3.2/backward
/usr/local/include/mingw
/usr/local/lib/gcc-lib/i686-pc-cygwin/3.2/include
End of search list.
[snip!]

The only other point is whether the link command is using
the -Wl,--export-all-symbols flag, which you could check with
bjam -d2. I hope we managed to get to the bottom of this, because
things working when they shouldn't is kind of worrying!

Regards,
Raoul Gough.

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com