From: Raoul Gough (raoulgough_at_[hidden])
Date: 2003-01-21 17:56:37
"William E. Kempf" <wekempf_at_[hidden]> wrote in message
> Raoul Gough said:
> > There seem to be some problems with building the Boost test
> > both with gcc-nocygwin and native mingw. See the attached traces
> > details. I guess these problems are caused by differences between
> > and Windows shared library linkage styles, but I haven't really
> > investigated (seems like it was already broken, since the mingw
> > toolset has exactly the same problems).
> Hmmm... I didn't have any troubles at all. I replaced the content
> gcc-nocygwin-tools.jam with what you have above, and ran "bjam
> -sTOOLS=gcc-nocygwin test" in the $BOOST/libs/thread/test directory,
> built all of the Boost.Threads and Boost.Test libraries, as well as
> test harness for Boost.Threads, and ran the resulting executables.
> Everything worked fine (minus a couple of runtime bugs found for
> "new" toolset in the Boost.Threads library). This was all done on a
> recently updated CVS repository.
Oh no! Could it be that no two installations are actually the same? I
just tried doing what you described, and get "multiple definition"
errors during executable linking. Like this:
0379.o)(.text+0x0): multiple definition of `atexit'
nt/samo/mingw/msys/crt1.c: first defined here
This can be traced back to the DLL building commands in gcc-tools.jam,
where it supplies the "-Wl,--export-all-symbols" flag to the linker.
This won't work for the nocygwin toolset, as I now realise. If you
want to know *why* it won't work, here's my analysis: building a DLL
with nocygwin or mingw requires some .o files (like crt2.o above) to
be linked into the DLL. With the export-all-symbols flag, the symbols
from those objects get exported, causing multiple definitions when it
comes to linking an executable. The problem doesn't occur with the
plain cygwin compiler, since the built DLLs get references to
cygwin1.dll instead of actual object code.
Effectively, we need gcc-nocygwin to use the link action from the
mingw toolset. However, I'm not so sure about using "extends-toolset"
from mingw, because of the confusion that could result if you've got
the MINGW_ROOT_DIRECTORY environment variable set. Is there any way to
get just the Link-action from a toolset (other than cut-and-paste)?
On another angle completely, is the "-Wl,--export-all-symbols" still
necessary for gcc-tools.jam? It seems to me that the source code must
now contain the right __attribute(__dllexport__) and __dllimport__
directives, otherwise mingw wouldn't work without it the export-all
> > If there are no objections, I'll check the new nocygwin support
> > at the end of the week.
> Well, other than addressing Dave's concerns about older Cygwin GCC
> installations, I have no objections and am anxiously awaiting the
And my new found concerns about DLLs :-)
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk