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: 23 Sep 2009 16:36:24 -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 #14 from developer at sandoe-acoustics dot co dot uk 2009-09-23 16:36 -------
(In reply to comment #12)
> However your current
> approach isn't scalable (which was Mike's complaint).
anything that requires an action per added function is "non-scalable" in that
way.
the only action needed for the _ext is to list the function in
gcc/config/darwin-libgcc-ext-32B-10.X.ver and friends.
(OK there's an addition for each darwin release where the content of libgcc_s
changes - but there would be a change to add a new macro for the other
mechanism)
the effort required of wrapping the function exports in a #define
NOT_HERE_BEFORE_10_X macro is probably typographically similar .. but more
intrusive in the source code.
However, I don't claim to understand the full range of options available from
ld; So (after putting out the current fire) I'd like to take a look at that
(anyone else welcome to do it first ;))
Apropos "extra compile flags" this was only to hide the new feature behind
something for test purposes -- clearly if the process were adopted the flag
would not be needed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888