This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug other/39888] TLS emutls not linked to automatically on Darwin
- From: "developer at sandoe-acoustics dot co dot uk" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 22 Sep 2009 19:20:39 -0000
- Subject: [Bug other/39888] TLS emutls not linked to automatically on Darwin
- References: <bug-39888-4688@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #7 from developer at sandoe-acoustics dot co dot uk 2009-09-22 19:20 -------
(In reply to comment #6)
> I wonder if we could just trim out the symbols from libgcc that are in
> libSystem, and arrange for gcc's installed libgcc to be found first.
OK. If I understand this from the symbol PoV
- that's the same machinery as builds the _ext
(i.e. there are the same symbols left at each revision as would be in the _ext
)...
in a change-control sense, at least.
> Advantage, simplicity, less target specific work, easy to understand.
Simplicity & less work sound good... I'm working on the understanding bit ;)
> Downside, OS upgrades require recompiling the world, to the extent there are
> new symbols in libgcc that are then added to libSystem in later OS releases.
meaning that a binary from on OSX release would not work on a later one or vice
versa.
I guess there's an amount of this anyway ..
> ld has magic in it that can appear and disappear symbols from a dylib depending
> upon which OS is targeted. Target old OSes, all the usual symbols are there,
> target newer OSes, large swaths disappear (but are found anyway in libSystem).
>
> Also, all this fun stuff it relevant to darwin10 and later only (not darwin9).
why not relevant to D9 and D8?
(D8 is still the end of the road for a whole bunch of perfectly good PPC
hardware)
if we override the /usr/lib/libgcc_s we mess up the unwinding
(the whole reason I made the _ext in the first place was that we can't 'lose'
that version because it's linked with system frameworks.)
To add symbols to D9/D8 we still have to link two libgcc variants (whether one
is named _ext or not is not important) ..
> I'm not a fan of yet more compile flags in general. I'd rather have a nice
> design that covers the bases, that doesn't really need yet more flags.
>
> The hiding trick goes something like:
>
> #define NOT_HERE_BEFORE_10_6(sym) \
> extern const char sym##_tmp3 __asm("$ld$hide$os10.3$_" #sym ); \
> __attribute__((visibility("default"))) const char sym##_tmp3 = 0; \
where do we have to apply this macro ?
to every function in libgcc? (with appropriate 'NOT_HERE_BEFOREs' )
or is it something that could be scripted?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888