This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [Darwin] Patch, take 2: enable linkonce support for Darwin
- From: Kevin B. Hendricks <kevin dot hendricks at sympatico dot ca>
- To: Matt Austern <austern at apple dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 30 Jan 2004 14:16:47 -0500
- Subject: Re: [Darwin] Patch, take 2: enable linkonce support for Darwin
Hi Matt,
A quick general question about this patch, the OpenOffice.org porters
to MacOSX ran into serious problems with "coalesced" symbols that were
not fixed until the most recent Apple version of GCC 3.3. The problem
was most easily seen when linking in libstlport (STL) and finding that
depending on the mix of the compiler optimization levels used we
generated strange linker failures related to coalesced symbols not
being present in each linker section (or only in the wrong section?)
For example, rebuilding one library with -O0 -g for debugging purposes
seemed to create problems when trying to link with other libraries that
typically did not exist if everything was compiled at -O2 or higher.
Typically the error message looked like the following:
> ./STLport-4.5/lib/libstlport_gcc.dylib)
> ld: huh.o illegal reference for -dynamic code (section difference
> reference from section (__TEXT,__eh_frame) relocation entry (82) to
> symbol: _STL::__node_alloc<(bool)1, (int)0>::allocate(unsigned long)
> defined in dylib: ./STLport-4.5/lib/libstlport_gcc.dylib)
The GNU Darwin compiler gcc 3.3 *never* seemed to have the same
problems at that time that the Apple compiler had until the August gcc
3.3 update (but it did have problems with static objects in templates
and other issues).
Has this problem of mixing optimization levels and potentially missing
related coalesced been tested in the new Darwin build with your patch
in place to make sure the same problem that existed until recently in
Apple's gcc 3.3 is not being introduced mistakenly into Darwin?
I guess I am just being paranoid but that problem held up progress for
us almost 2 years. :-)
Now if we could just get the C++ static initialization to work reliably
(I have a test case in case anyone is interested which shows static
initialization of an object being re-entered in a single threaded app
unless -bind_at_load or -single-module is used which horribly slows
down the startup time of OpenOffice.org). Please see the following url
if interested.
http://porting.openoffice.org/servlets/ReadMsg?list=dev&msgId=916562
Thanks,
Kevin