This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Darwin assert.h / shared libgcc mess
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Geoffrey Keating <geoffk at geoffk dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 15 Nov 2004 15:39:47 -0800
- Subject: Re: Darwin assert.h / shared libgcc mess
- References: <87oehyq1km.fsf@codesourcery.com> <m2brdy21jg.fsf@greed.local>
Geoffrey Keating <geoffk@geoffk.org> writes:
>> 2) Put __eprintf back into the shared libgcc, as an exported symbol,
>> for all !inhibit_libc targets, so that fixincludes can rely on its
>> being there. (If we instead use __assert, then __eprintf will
>> remain a static-library-only backward compatibility symbol.)
>
> Is this really necessary? I'd rather have __eprintf linked into only
> those apps that need it.
Right now, any shared library that uses assert will fail to link.
_Something_ has to be done. I'm open to alternative suggestions.
>> 5) Determine for certain whether or not Darwin ld supports symbol
>> versioning. Correct t-slibgcc-darwin to use the appropriate mkmap
>> file and to actually apply the map to the generated libgcc.dylib.
>
> The Darwin ld does not support symbol versioning. You can safely delete
> any versioning files for Darwin (so long as it doesn't break the makefiles).
Okay, so t-slibgcc-darwin ought to be using mkmap-flat.awk and
-exported_symbols_list. Thanks for the clarification.
>> i) Nudzh the Darwin developers to put __assert in libSystem and
>> provide a correct /usr/include/assert.h (y'all can just copy it
>> from FreeBSD! Only with attribute noreturn, please).
>
> In Tiger, /usr/include/assert.h will be provided by Libc, not the
> compiler, and it will use __assert.
Good.
zw