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

From: Raoul Gough (raoulgough_at_[hidden])
Date: 2003-01-21 17:56:37

"William E. Kempf" <wekempf_at_[hidden]> wrote in message
news:1438.167.16.75.51.1043220164.squirrel_at_frodo.kempf-ville.com...
> Raoul Gough said:
[snip]
> > There seem to be some problems with building the Boost test
libraries,
> > both with gcc-nocygwin and native mingw. See the attached traces
for
> > details. I guess these problems are caused by differences between
Unix
> > 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
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.

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:

..\..\..\libs\thread\build\bin\boost_thread.dll\gcc-nocygwin\debug\opt
imization-off\runtime-link-static\threading-multi\boost_thread.lib(d00
0379.o)(.text+0x0): multiple definition of `atexit'
/usr/local/lib/gcc-lib/i686-pc-mingw32/3.2/crt2.o(.text+0xfc)://c/cygm
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
flag.

>
> > If there are no objections, I'll check the new nocygwin support
into CVS
> > 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
new
> toolset!

And my new found concerns about DLLs :-)

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