[Bug other/39888] New: TLS emutls not linked to automatically on Darwin

[Bug other/39888] New: TLS emutls not linked to automatically on Darwin

[fago at earthlink dot net]

Using thread local storage (e.g. OpenMP ThreadPrivate variables) on Darwin
requires manually linking to TLS emutls, via either -lgcc_s.so.1 or -lgcc_eh

See the threads:
http://gcc.gnu.org/ml/gcc/2008-12/msg00145.html
http://gcc.gnu.org/ml/gcc/2008-12/msg00107.html

>From the above threads, this is evidently quite a mess. However, as I was just
bit by this I hoped it useful to have a bug tracking the issue.

I just ran across this with a fresh bootstrap of gcc 4.4.0 on MacOSX 10.5.6
x86_64, configured as: "--program-suffix=-4.4 --enable-languages=c,c++,fortran"

TLS works fine if I manually link to gcc_s.so.1 or gcc_eh as mentioned above.


-- 
           Summary: TLS emutls not linked to automatically on Darwin
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: fago at earthlink dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #1 from developer at sandoe-acoustics dot co dot uk  2009-04-27 19:03 -------
Created an attachment (id=17769)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17769&action=view)
patch for 4.4-branch (and 4.4.0 release)

don't forget to add the version files.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #2 from developer at sandoe-acoustics dot co dot uk  2009-04-27 19:04 -------
Created an attachment (id=17770)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17770&action=view)
added files for the libgcc_ext patch


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #3 from developer at sandoe-acoustics dot co dot uk  2009-04-27 19:05 -------
Created an attachment (id=17771)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17771&action=view)
patch against 4.5 trunk

also needs the added files


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #4 from developer at sandoe-acoustics dot co dot uk  2009-04-27 19:07 -------
Sorry I got the attachments and the comment in the wrong order...

The basic issue is that TLS emulation needs to be linked just once in an
executable - but so does exception handling.  Exception handling is already
linked (for system libraries) with /usr/lib/libgcc_s.1.dylib  - so we cannot
simply replace that with our new lingcc_s.1.dylib version (or you will lose the
ability to unwind through the system libs).

I was working on the following engineering solution last year, but I'm afraid
it's possibly rough around the edges and is "undiscussed" and therefore any
part of all of it might be unacceptable to the various maintainers.    I'm
posting it now because the day job is not allowing any time to work on it --
and it might be useful to someone as it stands.

====

The basic idea is to add a "libgcc_ext.dylib" that is versioned and contains
all the added symbols between a given release of Darwin and the current state
of libgcc_s.  This means that we will all resolve to the same versions of
symbols - but that new programs can access newly-added gcc features.

There are various changes needed to accommodate this logic:
 changes to build the difference library (done in the libgcc mechanism).
 additions of the symbol version files.
changes of the testsuite to make sure that the testsuite search paths include
the multilib versions of libgcc_ext.dylib.

As I say, the _ext dylib is versioned (so there's a 10.4 and 10.5 one built).

=== 

I'm attaching:
 a diff against 4.4-branch -- this applies against 4.4.0 release with one
offset and I've bootstrapped & checked that - I'll post the results.
 a diff against 4.5-trunk.
 a set of added files - which are common to both.

So you need to patch 4.x as appropriate and then add the new files.

I don't think this change makes much sense unless you build with
--enable-version-specific-runtime-libs and I haven't tested it any other way...


-- 

developer at sandoe-acoustics dot co dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |developer at sandoe-
                   |                            |acoustics dot co dot uk


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #5 from developer at sandoe-acoustics dot co dot uk  2009-04-27 19:15 -------
testresults:
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg02886.html
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg02887.html

and to engage the facility you need to build your program with
" -muse-shared-libgcc-ext "

best luck 
Iain


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[mrs at apple dot com]

------- Comment #6 from mrs at apple dot com  2009-09-22 18:56 -------
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. 
Advantage, simplicity, less target specific work, easy to understand. 
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. 
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). 
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; \


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- 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

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[mrs at apple dot com]

------- Comment #8 from mrs at apple dot com  2009-09-22 21:17 -------
I meant the idea that libSystem has new symbols in it is relevant only to
darwin10.  The system libgcc_s is present on older OSes, so those aspects are
still relevant.  Yeah, to solve that problem one would either have to have a
new name, or possibly an explicit path.  I've not tried the later, but it might
offer a way to construct the library with fewer mods.

from darwin10:
$ nm /usr/lib/libgcc_s.1.dylib | grep Unwind_Bac
0019f9c6 S $ld$hide$os10.4$__Unwind_Backtrace
0019f9c7 S $ld$hide$os10.5$__Unwind_Backtrace
00163b30 T __Unwind_Backtrace
$ nm /usr/lib/libSystem.dylib | grep Unwind_Bac
0019f9c6 S $ld$hide$os10.4$__Unwind_Backtrace
0019f9c7 S $ld$hide$os10.5$__Unwind_Backtrace
00163b30 T __Unwind_Backtrace

also note, there is add as well as hide;

$ nm /usr/lib/libgcc_s.10.5.dylib | grep Unwind_Back
00000f0a S $ld$add$os10.4$__Unwind_Backtrace
00000f0b S $ld$add$os10.5$__Unwind_Backtrace

As for what functions (symbols), well, the ones in common between
libSystem/libgcc_s on the system and libgcc from gcc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #9 from howarth at nitro dot med dot uc dot edu  2009-09-23 03:02 -------
(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. 

Mike,
     Remember on llvm-dev Nick said...

    On a SnowLeopard system you *can* link against /usr/lib/libgcc_s. 
    10.5.dylib, but the linker will not record any symbols coming from  
    it.  In fact, the link order does not matter.  That is because /usr/ 
    lib/libgcc_s.10.5.dylib has magic symbols in it that say if you are  
    targeting 10.6 then _Unwind_Resume  (and other other symbols) are not  
    in that dylib, so the linker looks elsewhere and finds them in  
    libSystem.B.dylib.  In other words, the compiler changes to  
    SnowLeopard to omit /re-order the linking with -lgcc_s when targeting  
    10.6 was just an optimization and not required.

Doesn't this imply that you can't make force libgcc to be found before
libSystem under SL?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #10 from howarth at nitro dot med dot uc dot edu  2009-09-23 15:50 -------
What about just leveraging PIC-code libgcc.a on darwin by creating a libgcc_ext
with only a dummy routine and a linkage to the FSF libgcc.a. When creating
libgcc_ext, the ld option -unexported_symbols_list would be used and a file
containing all of the symbols exported from libgcc_10.5 passed to it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #11 from developer at sandoe-acoustics dot co dot uk  2009-09-23 16:00 -------
(In reply to comment #10)
> What about just leveraging PIC-code libgcc.a on darwin by creating a libgcc_ext
> with only a dummy routine and a linkage to the FSF libgcc.a. When creating
> libgcc_ext, the ld option -unexported_symbols_list would be used and a file
> containing all of the symbols exported from libgcc_10.5 passed to it.

as far as an _ext is concerned - I don't think there's any issue with what I
proposed - it also should extend to fill any gaps in 10.6 (we just leave
libgcc_s out of the link line I guess).

The issue is whether there's a Better Way to do the job.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #12 from howarth at nitro dot med dot uc dot edu  2009-09-23 16:19 -------
Iain,
   Rereading Nick's reply here...

http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html

I guess using libgcc_s would work under Snow Leopard. However your current
approach isn't scalable (which was Mike's complaint). What we need is an
approach that links in libgcc.a or libgcc_s to a dummy libgcc_ext and exports
of the symbols except those listed in libgcc_10.4/10.5. This would require far
less effort to maintain since we don't have to constantly adjust the list
object files that constitute libgcc_ext.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #13 from howarth at nitro dot med dot uc dot edu  2009-09-23 16:28 -------
Actually, the files darwin-libgcc.10.4.ver and darwin-libgcc.10.5.ver in
gcc/config/rs6000 and gcc/config/i386 must be used in that manner (with
-exported_symbols_list instead of -unexported_symbols_list) to create
libgcc_s.10.4.dylib and libgcc_s.10.5.dylib. So just duplicate what Apple does
to create those shared libraries but invert the logic of how
darwin-libgcc.10.5.ver is used and name the new libgcc as libgcc_ext.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- 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

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #15 from howarth at nitro dot med dot uc dot edu  2009-09-23 16:50 -------
Look at gcc/libgcc/config/t-slibgcc-darwin, in particular...

SHLIB_LINK = $(CC) $(LIBGCC2_CFLAGS) -dynamiclib -nodefaultlibs \
        -install_name @shlib_slibdir@/$(SHLIB_INSTALL_NAME) \
        -single_module -o $(SHLIB_DIR)/$(SHLIB_SONAME).tmp \
        -Wl,-exported_symbols_list,$(SHLIB_MAP) \
        $(SHLIB_VERSTRING) \
        @multilib_flags@ $(SHLIB_OBJS) $(SHLIB_LC)

what would be perfect is finding a way to add libgcc_ext.dylib to...

INSTALL_FILES=libgcc_s.10.4.dylib libgcc_s.10.5.dylib libgcc_s.1.dylib

in that file and have the SHLIB_LINK command special case the instance of
libgcc_ext to execute as...

SHLIB_LINK = $(CC) $(LIBGCC2_CFLAGS) -dynamiclib -nodefaultlibs \
        -install_name @shlib_slibdir@/$(SHLIB_INSTALL_NAME) \
        -single_module -o $(SHLIB_DIR)/$(SHLIB_SONAME).tmp \
        -Wl,-unexported_symbols_list,$(SHLIB_MAP) \
        $(SHLIB_VERSTRING) \
        @multilib_flags@ $(SHLIB_OBJS) $(SHLIB_LC)

with $(SHLIB_MAP) set to gcc/config/i386/darwin-libgcc.10.5.ver or
gcc/config/rs6000/darwin-libgcc.10.5.ver in that case. Potentially this
can make the patch very small and completely scalable (if we can find a way to
code it).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #16 from howarth at nitro dot med dot uc dot edu  2009-09-23 17:53 -------
Would a construct like...

SHLIB_LINK = $(CC) $(LIBGCC2_CFLAGS) -dynamiclib -nodefaultlibs \
        -install_name @shlib_slibdir@/$(SHLIB_INSTALL_NAME) \
        -single_module -o $(SHLIB_DIR)/$(SHLIB_SONAME).tmp \
         `if test @install_files@ = libgcc_ext.dylib ; then echo
"-Wl,-unexported_symbols_list," ; else echo "-Wl,-exported_symbols_list" fi` \
         `if test @install_files@ = libgcc_ext.dylib ; then echo
darwin-libgcc.10.5.ver; else echo $(SHLIB_MAP) fi` \
        $(SHLIB_VERSTRING) \
        @multilib_flags@ $(SHLIB_OBJS) $(SHLIB_LC)

be workable?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #17 from howarth at nitro dot med dot uc dot edu  2009-09-23 18:40 -------
(In reply to comment #6)
>
> 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; \
> 

Maybe we're thinking differently about this. For FSF gcc 4.5, I would think
that we would change LIB_SPEC to always link in the -lgcc_ext shared library.
After all, these additional symbols really should in the operative libgcc that
is linked in and always available. I am not a big fan of adding configure flags
that the user has to invoke in order to access the symbols in libgcc_ext (which
I though was Iain's approach). Also I don't see why the macro above has any
advantages over just using -unexported_symbols_list and the libgcc-10.5.ver
file. Wouldn't this create binaries that are completely portable from
10.4->10.5->10.6 as long as the user provided the libgcc_ext.dylib that they
were linked against?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #18 from howarth at nitro dot med dot uc dot edu  2009-09-23 18:57 -------
Hmmm...

MULTIOSSUBDIR := $(shell if test $(MULTIOSDIR) != .; then echo /$(MULTIOSDIR);
fi)

in gcc-4.4.1/libgcc/Makefile.in survives into the generated Makefile intact. So
perhaps something like...


SHLIB_LINK = $(CC) $(LIBGCC2_CFLAGS) -dynamiclib -nodefaultlibs \
        -install_name @shlib_slibdir@/$(SHLIB_INSTALL_NAME) \
        -single_module -o $(SHLIB_DIR)/$(SHLIB_SONAME).tmp \
         $(shell if test @install_files@ = libgcc_ext.dylib ; then echo
"-Wl,-unexported_symbols_list," ; else echo "-Wl,-exported_symbols_list," fi) \
         $(shell if test @install_files@ = libgcc_ext.dylib ; then echo
darwin-libgcc.10.5.ver; else echo $(SHLIB_MAP) fi) \
        $(SHLIB_VERSTRING) \
        @multilib_flags@ $(SHLIB_OBJS) $(SHLIB_LC)

would work. FYI, I am just trying to reuse as much of the existing build
machinery as possible here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[mrs at apple dot com]

------- Comment #19 from mrs at apple dot com  2009-09-23 20:43 -------
Subject: Re:  TLS emutls not linked to automatically on Darwin

On Sep 22, 2009, at 8:02 PM, howarth at nitro dot med dot uc dot edu  
wrote:
> Doesn't this imply that you can't make force libgcc to be found before
> libSystem under SL?

No.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[mrs at apple dot com]

------- Comment #20 from mrs at apple dot com  2009-09-23 20:48 -------
Subject: Re:  TLS emutls not linked to automatically on Darwin

On Sep 23, 2009, at 8:50 AM, howarth at nitro dot med dot uc dot edu  
wrote:
> What about just leveraging PIC-code libgcc.a on darwin by creating a  
> libgcc_ext

Around we go...  The question is why do that?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[mrs at apple dot com]

------- Comment #21 from mrs at apple dot com  2009-09-23 20:49 -------
Subject: Re:  TLS emutls not linked to automatically on Darwin

On Sep 23, 2009, at 9:19 AM, howarth at nitro dot med dot uc dot edu  
wrote:
> What we need is an approach that links in libgcc.a or libgcc_s to a  
> dummy libgcc_ext

Why?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[mrs at apple dot com]

------- Comment #22 from mrs at apple dot com  2009-09-23 20:52 -------
Subject: Re:  TLS emutls not linked to automatically on Darwin

On Sep 23, 2009, at 11:40 AM, howarth at nitro dot med dot uc dot edu  
wrote:
> Also I don't see why the macro above has any advantages over just  
> using -unexported_symbols_list

-mmacosx-version-min= won't work.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #23 from howarth at nitro dot med dot uc dot edu  2009-09-23 21:06 -------
(In reply to comment #20)
> Subject: Re:  TLS emutls not linked to automatically on Darwin
> 
> On Sep 23, 2009, at 8:50 AM, howarth at nitro dot med dot uc dot edu  
> wrote:
> > What about just leveraging PIC-code libgcc.a on darwin by creating a  
> > libgcc_ext
> 
> Around we go...  The question is why do that?
> 
I was under the impression that if we linked libgcc.a into a libgcc_ext created
with -unexported_symbols_list using darwin-libgcc-10.5.ver that we would end up
with a libgcc_ext shared library would export everything that libgcc_s does
except those symbols listed in darwin-libgcc-10.5.ver,


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #24 from howarth at nitro dot med dot uc dot edu  2009-09-23 21:18 -------
I am confused why libgcc_ext needs to be built as 10.4/10.5 versions. Aren't
all of the symbols to be exported by libgcc_ext from post libgcc-10.5? If so,
wouldn't a shared library exporting all of the symbols from libgcc_s except
those listed in darwin-libgcc-10.5 represent a universal libgcc_ext that would
work on 10.4/10.5/10.6, etc?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #25 from howarth at nitro dot med dot uc dot edu  2009-09-23 23:45 -------
Okay. I see my confusion now on the usage of -unexported_symbols_list. We still
need to carefully consider the implications of...

http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00892.html

going into gcc trunk. If it does, tls will always be on and the default
behavior of the compiler will have to be linking in libgcc_ext.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #26 from developer at sandoe-acoustics dot co dot uk  2009-09-24 07:46 -------
(In reply to comment #24)
> I am confused why libgcc_ext needs to be built as 10.4/10.5 versions. Aren't

the _ext is versioned - precisely because the symbols included in the OS
version changes between OS revisions.  No only that, but there are different
symbol sets between 32 and 64 bit libs.

As far as darwin8 and darwin9 are concerned - I have no better offer than the
_ext as formulated above (I will try and update the patches in the next couple
of weeks).

As far as darwin10 is concerned Mike's solution needs implementation and
evaluation, if we are to adopt it.  I'll try and find a free machine to put
darwin10 on.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #27 from howarth at nitro dot med dot uc dot edu  2009-09-24 13:06 -------
I don't see why your current patch should present a problem for darwin10. My
understanding is that all of the symbols in libgcc-10.5 were moved into
libSystem
and they are ignored if present in libgcc regardless of linkage order. So if we
move all post libgcc-10.5 symbols into libgcc-ext-10.5 that should be fine.
I'll test your current patch on darwin10 tonight.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #28 from howarth at nitro dot med dot uc dot edu  2009-09-24 13:15 -------
Iain,
   You patch is showing some bit rot against current gcc trunk. Can you upload
an updated version that applies cleanly against the current sources?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #29 from developer at sandoe-acoustics dot co dot uk  2009-09-24 20:55 -------
Created an attachment (id=18644)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18644&action=view)
updated patch for 4-5 trunk

(i) the added .ver files are (as yet) unchanged - so some newer (last few
months) symbols would be missing.
(ii) I seem to do >= 1.5 so the thing should also work "out of the box" on 10.6
***providing*** none of the newer symbols have been already added to 10.6
libSystem.dylib.  From comments here: libSystem only subsumes the symbols from
10.5's libgcc_s so we should be good to go.
(iii) it's hidden behind the -muse-shared-libgcc-ext for test purposes.
(iv) you will need to add DYLD_LIBRARY_PATH entries pointing to gcc and
gcc/<64bit> if you want to play with it uninstalled.
(v) I'm about to regtest with 152135 with this patch applied and -muse-xxxx but
that's tomorrow for a result.
(vi) good luck ;)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #30 from howarth at nitro dot med dot uc dot edu  2009-09-24 22:33 -------
Iain,
   I am getting the build failure on x86_64-apple-darwin10 of...

# Early copyback; see "all" above for the rationale.  The
# early copy is necessary so that the gcc -B options find
# the right startup files when linking shared libgcc.
/bin/sh ../../../gcc-4.5-20090924/libgcc/../mkinstalldirs ../.././gcc
parts="crt3.o crtfastmath.o crtprec32.o crtprec64.o crtprec80.o";              
                \
        for file in $parts; do                                  \
          rm -f ../.././gcc/$file;              \
          /usr/bin/install -c -m 644 $file ../.././gcc/;        \
        done
# Recursively invoke make in the GCC directory to build any
make[5]: *** No rule to make target
`../../../../gcc-4.5-20090924/libgcc/../gcc/config/i386/darwin-libgcc-ext-32B-10.4.ver',
needed by `libgcc_ext.10.4.dylib'.  Stop.
make[5]: *** Waiting for unfinished jobs....


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #31 from developer at sandoe-acoustics dot co dot uk  2009-09-24 22:42 -------
(In reply to comment #30)
>    I am getting the build failure on x86_64-apple-darwin10 of...
*** No rule to make target
> `../../../../gcc-4.5-20090924/libgcc/../gcc/config/i386/darwin-libgcc-ext-32B-10.4.ver',
> needed by `libgcc_ext.10.4.dylib'.  Stop.

you need to add the files in the .zip (second attachment).

should give you:
gcc/config/{i386,rs6000}/darwin-libgcc-ext-{23,64}B-10.{4,5}.ver


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #32 from howarth at nitro dot med dot uc dot edu  2009-09-24 23:47 -------
Created an attachment (id=18645)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18645&action=view)
build failure on x86_64-apple-darwin10


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #33 from howarth at nitro dot med dot uc dot edu  2009-09-24 23:48 -------
Iain,
    With those missing files added, the build still fails for
x86_64-apple-darwin10. I've uploaded the failed build log in case you recognize
where the build is going astray.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #34 from howarth at nitro dot med dot uc dot edu  2009-09-25 01:20 -------
Iain,
    The build on i686-apple-darwin10 is going better but has a glitch. A no
time during the different stages of the bootstrap are libgcc_s.10.4.dylib and
libgcc_s.10.5.dylib created. For example, in stage1-gcc I have...

libgcc_ext.10.4.dylib   libgcc_ext.10.5.dylib   libgcc_s.1.dylib       
libgcc_s_ppc64.1.dylib  libgcc_s_x86_64.1.dylib

whereas a build without the libgcc-ext patch shows....

libgcc_s.1.dylib        libgcc_s.10.4.dylib     libgcc_s.10.5.dylib    
libgcc_s_ppc64.1.dylib  libgcc_s_x86_64.1.dylib

I'll attach a compressed build log once the bootstrap is complete.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #35 from howarth at nitro dot med dot uc dot edu  2009-09-25 02:19 -------
Created an attachment (id=18647)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18647&action=view)
i686-apple-darwin10 build log with patch


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #36 from developer at sandoe-acoustics dot co dot uk  2009-09-25 10:07 -------
(In reply to comment #34)
>     The build on i686-apple-darwin10 is going better but has a glitch. A no
> time during the different stages of the bootstrap are libgcc_s.10.4.dylib and
> libgcc_s.10.5.dylib created. For example, in stage1-gcc I have...

1/ OK. IIRC I *do not* build the 10.X.dylibs unless you make
--with-slibdir=/usr/lib.  The reason for this is that no-one other than an
entity releasing a Darwin version ever needs to make those because they, and
the /usr/lib/libgcc_s* are already installed on the system (or would be used
from /Developer/SDKs for a cross-build).

2/ 4.4 updated smoothly from the branch and built/regtested:
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02253.html

3/ 4.5 new patch above built and regtested:
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02254.html

4/ I've nearly finished installing SL/Darwin10 on another box -- so I'll take a
shufftie at that this evening.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #37 from howarth at nitro dot med dot uc dot edu  2009-09-25 10:44 -------
I just noticed that I have been neglecting to pass
--enable-version-specific-runtime-libs to configure. What should be the impact
of that on the build (since I did get the expected libgcc-ext.10.4/5 files)? 
Could that be related to the build failure on x86_64-apple-darwin10?
Are you using...

make -k  check RUNTESTFLAGS="--target_board=unix/-muse-shared-libgcc-ext"

when you run the testsuite? Since you are already doing something fairly
radical here (dropping libgcc-10.4/10.5 from the build), we might as well
anticipate http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00892.html going into
gcc trunk by making -muse-shared-libgcc-ext the default behavior for linking.
The option behavior should be -muse-static-runtimes instead. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #38 from developer at sandoe-acoustics dot co dot uk  2009-09-25 10:54 -------
(In reply to comment #37)
> I just noticed that I have been neglecting to pass
> --enable-version-specific-runtime-libs to configure. What should be the impact
> of that on the build (since I did get the expected libgcc-ext.10.4/5 files)? 
> Could that be related to the build failure on x86_64-apple-darwin10?

I don't think any of this stuff makes much sense w/out
--enable-version-specific-runtime-libs; I always use this to enable multiple
versions of gcc installed on the same machine.

I don't know if that's the root of the D10 issue - somehow I doubt it (I try
not to make assumptions about future systems - and probably excluded D10
somewhere ... but hopefully I'll look at that later).

> Are you using...
> make -k  check RUNTESTFLAGS="--target_board=unix/-muse-shared-libgcc-ext"

yes. should be listed in the test results.
whether this is default or not can be determined trivially (Init(1)) as and
when the approach is agreed with the relevant maintainers.

> The option behavior should be -muse-static-runtimes instead. 

different objective not related to the _ext;  mea culpa if that is present in
the patch;
FWIW:   -muse-static-runtimes is designed to allow the building of statically
linked (save libSystem) objects on Darwin (this is to assist in deployment of
parallel jobs on clusters - or distibution of apps using more advanced features
than are standard on a given rev)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #39 from howarth at nitro dot med dot uc dot edu  2009-09-25 19:16 -------
Iain,
   I believe I see the problem with the x86_64-apple-darwin10 build. The
multilib subdirectory for the 32-bit binaries is named i386. So you need...

EXLIB_64FLAG = i386

instead of...

EXLIB_64FLAG = x86_64

for libgcc/config/i386/t-darwin64, otherwise it will be looking for a
non-existent multilib directory. I'll test this tonight.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #40 from developer at sandoe-acoustics dot co dot uk  2009-09-25 19:25 -------
(In reply to comment #39)
> EXLIB_64FLAG = i386

close ;) -- it should be EXLIB_64FLAG = . 
(I think)

build is nearly finished on x86_64-apple-darwin9

i686-apple-darwin10 build completed and is reg-testing now.

more later/tomorrow.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #41 from howarth at nitro dot med dot uc dot edu  2009-09-25 23:51 -------
Iain,
   I just puzzled out a solution for keeping the symbols constantly updated for
libgcc-ext*. We make the following changes to your patch...

1) The files gcc/config/rs6000/darwin-libgcc-ext-32B-10.4.ver and
gcc/config/rs6000/darwin-libgcc-ext-64B-10.4.ver are made to be exact copies of
gcc/config/rs6000/darwin-libgcc.10.4.ver
2) The files gcc/config/rs6000/darwin-libgcc-ext-32B-10.5.ver and
gcc/config/rs6000/darwin-libgcc-ext-64B-10.5.ver are made to be exact copies of
gcc/config/rs6000/darwin-libgcc.10.5.ver
3) The files gcc/config/i386/darwin-libgcc-ext-32B-10.4.ver and
gcc/config/i386/darwin-libgcc-ext-64B-10.4.ver are made to be exact copies of
gcc/config/i386/darwin-libgcc.10.4.ver
4) The files gcc/config/i386/darwin-libgcc-ext-32B-10.5.ver and
gcc/config/i386/darwin-libgcc-ext-64B-10.5.ver are made to be exact copies of
gcc/config/i386/darwin-libgcc.10.5.ver
5) The section of your patch...

+EXLIB_LINK = $(CC) $(LIBGCC2_CFLAGS) -dynamiclib -nodefaultlibs \
+       -install_name @exlibdir@/$(EXLIB_SONAME) \
+       -single_module -o @multilib_dir@/$(EXLIB_SONAME) \
+       -Wl,-exported_symbols_list,@exlib_map_file@ \
+       $(EXLIB_VERSTRING) \
+       @multilib_flags@ @exlib_objs@ @exlib_other_lib@ $(SHLIB_LC)
+

is change to...

+EXLIB_LINK = $(CC) $(LIBGCC2_CFLAGS) -dynamiclib -nodefaultlibs \
+       -install_name @exlibdir@/$(EXLIB_SONAME) \
+       -single_module -o @multilib_dir@/$(EXLIB_SONAME) \
+       -Wl,-unexported_symbols_list,@exlib_map_file@ \
+       $(EXLIB_VERSTRING) \
+       @multilib_flags@ @exlib_objs@ @exlib_other_lib@ $(SHLIB_LC)
+

This seems to work here on x86_64-apple-darwin10. All of the symbols left in
libgcc-ext not in the symbol list to unexport are left exported automatically.
No need to assemble or maintain any lists.
The remaining question is can your patch be refactored to eliminate the need
for so many *.ver files now that they shared common contents with
darwin-libgcc.10.4.ver and darwin-libgcc.10.5.ver. That is, can reduced the
list of new *.ver files to just darwin-libgcc-ext-10.4.ver and
darwin-libgcc-ext-10.5.ver.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #42 from howarth at nitro dot med dot uc dot edu  2009-09-26 00:54 -------
Created an attachment (id=18652)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18652&action=view)
patch modified to use unexport on libgcc-ext files


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #43 from howarth at nitro dot med dot uc dot edu  2009-09-26 00:59 -------
The r152192-4-5-trunk-patch.diff is your 152135-4-5-trunk-patch.diff.txt with
the correction of the...

+EXLIB_64FLAG = .

in libgcc/config/i386/t-darwin64 and the use of -unexported_symbols_list for
EXLIB_LINK. The new copies of the required *.ver files are in the patch as
well. This builds fine on x86_64-apple-darwin10. The question now is can the
patch be refactored so that these new ver files can be dropped completely and
the existing copies that were used to create them substituted in the build. I
am unclear if that is feasible.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #44 from howarth at nitro dot med dot uc dot edu  2009-09-26 02:55 -------
This isn't tested yet, but I think if we also change...

--- libgcc-ext.patchfink2       2009-09-25 20:17:05.000000000 -0400
+++ libgcc-ext.patchfink3       2009-09-25 22:53:12.000000000 -0400
@@ -387,7 +387,7 @@
 +              @exlib_objs@,$(EXLIB_OBJS4_64B),$(subst \
 +              @exlib_base_name@,libgcc_ext.10.4,$(subst \
 +              @shlib_slibdir_qual@,$(MULTIOSSUBDIR),$(subst \
-+              @exlib_map_file@,$(EXLIB_VERPFX)-64B-10.4.ver,$(subst \
++              @exlib_map_file@,$(SHLIB_VERPFX)-10.4.ver,$(subst \
 +              @exlibdir@,$(exlibdir),$(subst \
 +              @exlib_other_lib@,$(EXLIB4_LIB64),$(EXLIB_LINK))))))))) ; \
 +      else \
@@ -396,7 +396,7 @@
 +              @exlib_objs@,$(EXLIB_OBJS4_32B),$(subst \
 +              @exlib_base_name@,libgcc_ext.10.4,$(subst \
 +              @shlib_slibdir_qual@,$(MULTIOSSUBDIR),$(subst \
-+              @exlib_map_file@,$(EXLIB_VERPFX)-32B-10.4.ver,$(subst \
++              @exlib_map_file@,$(SHLIB_VERPFX)-10.4.ver,$(subst \
 +              @exlibdir@,$(exlibdir),$(subst \
 +              @exlib_other_lib@,$(EXLIB4_LIB32),$(EXLIB_LINK))))))))) ; \
 +      fi      
@@ -413,7 +413,7 @@
 +              @exlib_objs@,$(EXLIB_OBJS5_64B),$(subst \
 +              @exlib_base_name@,libgcc_ext.10.5,$(subst \
 +              @shlib_slibdir_qual@,$(MULTIOSSUBDIR),$(subst \
-+              @exlib_map_file@,$(EXLIB_VERPFX)-64B-10.5.ver,$(subst \
++              @exlib_map_file@,$(SHLIB_VERPFX)-10.5.ver,$(subst \
 +              @exlibdir@,$(exlibdir),$(subst \
 +              @exlib_other_lib@,$(EXLIB5_LIB64),$(EXLIB_LINK))))))))) ; \
 +      else \
@@ -422,7 +422,7 @@
 +              @exlib_objs@,$(EXLIB_OBJS5_32B),$(subst \
 +              @exlib_base_name@,libgcc_ext.10.5,$(subst \
 +              @shlib_slibdir_qual@,$(MULTIOSSUBDIR),$(subst \
-+              @exlib_map_file@,$(EXLIB_VERPFX)-32B-10.5.ver,$(subst \
++              @exlib_map_file@,$(SHLIB_VERPFX)-10.5.ver,$(subst \
 +              @exlibdir@,$(exlibdir),$(subst \
 +              @exlib_other_lib@,$(EXLIB5_LIB32),$(EXLIB_LINK))))))))) ; \
 +      fi      

we should be able to drop the new .ver files entirely from the build.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #45 from howarth at nitro dot med dot uc dot edu  2009-09-26 05:51 -------
It appears that the build structure required by the patch will prohibit
factoring out the additional ver files. The patch proposed in
r152192-4-5-trunk-patch.diff is as small as I can make it since the ver files
are required. However that patch is an improvement since the libgcc-ext build
is now completely scalable.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #46 from developer at sandoe-acoustics dot co dot uk  2009-09-26 17:28 -------
Created an attachment (id=18657)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18657&action=view)
much simplified version of the ext patch

OK. Jack made a Good Catch there... 

There is a much simpler way of doing this; using the -R option on strip one can
make an "ext" lib that refers to all the symbols not in the 10.X.dylib (using
the ver files that generate those stub libs).

So I now generate two new stub libs (_ext.10.X.dylib) that contain the set of
missing symbols.  The stub files refer to the newly built libgcc_s.1.dylib
installed along with gcc.

I don't know that "scalable" is exactly the right term - but this is '0
maintenance' unless a new version of 10.5 or 10.4 libgcc_s is made (unlikely at
this stage).

bootstrapped on i686-apple-darwin9, and x86_64-apple-darwin10 (reg-testing on
both).

more than 20 lines... but not too too much.

Log:
  *libgcc/configure.ac: Make sure the the rpath is correct in build tree
libraries when using --enable-version-specific-runtime-libs.
  *libgcc/configure: Regenerated.
  *libgcc/config/t-slibgcc-darwin: Don't make the _s.10X.dylib stubs unless
we're building for /usr/lib.  Build libgcc_ext.10.X.dylib containing newer
symbols
  *gcc/config/darwin.opt: Add muse-shared-libgcc-ext to hide behind for
testing.
  *gcc/config/darwin.h: use libgcc_ext.10.X to provide newer gcc functionality
to older systems

there are NO new files needed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #47 from howarth at nitro dot med dot uc dot edu  2009-09-26 20:36 -------
(In reply to comment #46)
> more than 20 lines... but not too too much.
> 

Iain,
    It bootstraps fine here on x86_64-apple-darwin10 as well. Why don't you
submit it
to gcc-patches after regtesting but as two separate patches. The first patch to
build libgcc-ext
on darwin...

 *libgcc/configure.ac: Make sure the the rpath is correct in build tree
libraries when using --enable-version-specific-runtime-libs.
  *libgcc/configure: Regenerated.
  *libgcc/config/t-slibgcc-darwin: Don't make the _s.10X.dylib stubs unless
we're building for /usr/lib.  Build libgcc_ext.10.X.dylib containing newer
symbols

and the second to enable its usage...

  *gcc/config/darwin.opt: Add muse-shared-libgcc-ext to hide behind for
testing.
  *gcc/config/darwin.h: use libgcc_ext.10.X to provide newer gcc functionality
to older systems

This will reduce the total line count for each submitted patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #48 from developer at sandoe-acoustics dot co dot uk  2009-09-28 07:47 -------
(In reply to comment #47)
> (In reply to comment #46)

>     It bootstraps fine here on x86_64-apple-darwin10 as well. 

It does ; but there's an error message about -R not being supported any more
strip.  
The man page doesn't make any comment about this being deprecated/removed so it
needs a little more investigation.
If the strip approach doesn't work universally, I can revert to linking
separate stub libs (using -unexported_sybols and then strip those -c).

> This will reduce the total line count for each submitted patch.

Well, there are two bits to this patch, the first is generic see:
http://gcc.gnu.org/ml/gcc/2009-09/msg00554.html

As for the rest, hopefully it won't be long before the paperwork arrives.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #49 from developer at sandoe-acoustics dot co dot uk  2009-09-28 09:02 -------
(In reply to comment #48)
> (In reply to comment #47)
> > (In reply to comment #46)
> >     It bootstraps fine here on x86_64-apple-darwin10 as well. 
> It does ; but there's an error message about -R not being supported any more
> strip.  

*sigh* .. I can't repeat this now; 

reg-test results:

powerpc-apple-darwin8 :
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02531.html
i686-apple-darwin9 :
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02532.html
x86_64-apple-darwin10 :
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02533.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #50 from developer at sandoe-acoustics dot co dot uk  2009-09-30 16:58 -------
Created an attachment (id=18677)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18677&action=view)
further simplified lib ext patch

after some discussion with Ian Lance Taylor, I took another look at
libgcc/config/t-slibgcc-darwin.
This had a bug [extra dependencies] causing the second link of libgcc_s* during
the install-leaf phase (where the libsubdir is "").  This was causing the wrong
rpaths in the libs.

So now we don't need to chance configure.ac and the changes are confined to
darwin-specific code.

However, there are two changes rolled together here (a) the fix for the buggy
rpaths and (b) the changes to provide the libgcc_ext* and use them.   I can
separate them once the overall process is finally approved (although Mike has
already said OK to a slightly larger version of this).


-- 

developer at sandoe-acoustics dot co dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #17770|0                           |1
        is obsolete|                            |
  Attachment #17771|0                           |1
        is obsolete|                            |
  Attachment #18644|0                           |1
        is obsolete|                            |
  Attachment #18657|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[mrs at apple dot com]

------- Comment #51 from mrs at apple dot com  2009-09-30 19:45 -------
Looks much better than past versions...  Seems like muse-shared-libgcc-ext
should be the default, and possibly that we don't even need the switch?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #52 from developer at sandoe-acoustics dot co dot uk  2009-09-30 19:54 -------
(In reply to comment #51)
> Looks much better than past versions...  Seems like muse-shared-libgcc-ext
> should be the default, and possibly that we don't even need the switch?

thanks Mike, I'll do a test run on each system with it on as default (this will
also cause gcc to be built with TLS internally, IIRC) - will comment when done; 

Agreed, would be better not to have the switch - it's only there to hide behind
for debug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #53 from howarth at nitro dot med dot uc dot edu  2009-09-30 23:36 -------
Iain,
    We seem to be producing an extra libgcc shared library with the new patch.
In darwin_objdir/stage1-x86_64-apple-darwin10.0.0/libgcc, I see...

libgcc_ext.10.4.dylib   libgcc_ext.10.5.dylib   libgcc_s.1.dylib       
libgcc_s.dylib

instead of just...

libgcc_ext.10.4.dylib   libgcc_ext.10.5.dylib   libgcc_s.1.dylib

with the previous patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #54 from howarth at nitro dot med dot uc dot edu  2009-09-30 23:38 -------
The new libgcc_s.dylib appears to be only of the native target architecture...

file libgcc_s.dylib
libgcc_s.dylib: Mach-O 64-bit dynamically linked shared library x86_64

file libgcc_s.1.dylib
libgcc_s.1.dylib: Mach-O universal binary with 2 architectures
libgcc_s.1.dylib (for architecture x86_64):     Mach-O 64-bit dynamically
linked shared library x86_64
libgcc_s.1.dylib (for architecture i386):       Mach-O dynamically linked
shared library i386


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #55 from developer at sandoe-acoustics dot co dot uk  2009-10-01 08:36 -------
(In reply to comment #54)
> The new libgcc_s.dylib appears to be only of the native target architecture...

it's best thought of not as "new" but "different" - it's the target for the
Makefile libgcc_s$(SHLIB_EXT).

In fact, we used to have intermediate targets (xxx.dylib.tmp) which you will
see are no longer present.

if you check the ***gcc directories, you will see that this intermediate file
is not installed in the staging - nor is it installed by make install.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #56 from howarth at nitro dot med dot uc dot edu  2009-10-01 13:59 -------
Okay. So no problem. What do you think is the best way to default on
libgcc-ext? Just using...

Index: gcc/config/darwin.h
===================================================================
--- gcc/config/darwin.h (revision 152370)
+++ gcc/config/darwin.h (working copy)
@@ -388,14 +388,14 @@
    If it is linked against, it has to be before -lgcc, because it may
    need symbols from -lgcc.  */
 #undef REAL_LIBGCC_SPEC
-#define REAL_LIBGCC_SPEC                                                  \
-   "%{static-libgcc|static: -lgcc_eh -lgcc;                               \
-      shared-libgcc|fexceptions|fgnu-runtime:                             \
-       %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s.10.4)       \
-       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5)       \
-       -lgcc;                                                             \
-      :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4) \
-       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5)       \
+#define REAL_LIBGCC_SPEC                                                      
          \
+   "%{static-libgcc|static: -lgcc_eh -lgcc;                                   
          \
+      shared-libgcc|fexceptions|fgnu-runtime:                                 
          \
+       %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s.10.4
-lgcc_ext.10.4)        \
+       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5
-lgcc_ext.10.5)        \
+       -lgcc;                                                                 
          \
+      :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4
-lgcc_ext.10.4) \
+       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5
-lgcc_ext.10.5)        \
        -lgcc}"

 /* We specify crt0.o as -lcrt0.o so that ld will search the library path.

...perhaps?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #57 from developer at sandoe-acoustics dot co dot uk  2009-10-01 17:22 -------
(In reply to comment #56)
> Okay. So no problem. What do you think is the best way to default on
> libgcc-ext? Just using...

I'm reg-testing on powerpc-apple-d8, i686-apple-d9 and x86_64-apple-d10
with this:

Index: gcc/config/darwin.h
===================================================================
--- gcc/config/darwin.h (revision 152363)
+++ gcc/config/darwin.h (working copy)
@@ -391,12 +391,16 @@
 #define REAL_LIBGCC_SPEC                                                  \
    "%{static-libgcc|static: -lgcc_eh -lgcc;                               \
       shared-libgcc|fexceptions|fgnu-runtime:                             \
-       %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s.10.4)       \
-       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5)       \
+       %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s.10.4 )      \
+       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5 )      \
+       %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)     \
+       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)     \
        -lgcc;                                                             \
-      :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4) \
-       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5)       \
-       -lgcc}"
+      :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4 )  \
+       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5 )      \
+       %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4)     \
+       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5)     \
+      -lgcc } "

 /* We specify crt0.o as -lcrt0.o so that ld will search the library path.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[mrs at apple dot com]

------- Comment #58 from mrs at apple dot com  2009-10-01 19:18 -------
Seems reasonable.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #59 from developer at sandoe-acoustics dot co dot uk  2009-10-02 08:17 -------
Created an attachment (id=18691)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18691&action=view)
libext patch with ext on as default, debug flag removed and white space changes
removed.

This should, hopefully, be final. 

Reg-tests have completed successfully on i686-apple-darwin9 and
x86_64-apple-darwin10 at m32 and m64. 

log:
    *libgcc/config/t-slibgcc-darwin: Fix embedded rpaths for
--enable-version-specific-runtime-libs, build extension stub libs exposing
newer features available from current libgcc_s.
    *gcc/config/darwin.h: Use the extension stub libraries to access newer
libgcc_s features.

Unfortunately, together that still makes changes amounting to 39 lines.   
However, I will post the reg test results and cross-reference them to here;  
I will post the patch and a changelog after that.

Given that this issue was raised before the 4.4 branch - I assume that it
should also be back-ported?
 (I'd imagine the patch would just apply, in fact)


-- 

developer at sandoe-acoustics dot co dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #17769|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #60 from developer at sandoe-acoustics dot co dot uk  2009-10-02 10:39 -------
Reg test results:

powerpc-apple darwin8 :
http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00141.html

i686-apple-darwin9: http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00142.html
compare without patch :
http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00144.html
[show no new fails and a considerable number of extra passes]

x86_64-apple-darwin10:
http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00143.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[andreast at gcc dot gnu dot org]

------- Comment #61 from andreast at gcc dot gnu dot org  2009-11-18 07:36 -------
Subject: Bug 39888

Author: andreast
Date: Wed Nov 18 07:36:12 2009
New Revision: 154282

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154282
Log:
2009-11-18  Iain Sandoe <iain.sandoe@sandoe-acoustics.co.uk>

        PR other/39888
        * config/t-slibgcc-darwin: Fix embedded rpaths for
        --enable-version-specific-runtime-libs, build extension stub
        libs exposing features available from current libgcc_s.

Modified:
    trunk/libgcc/ChangeLog
    trunk/libgcc/config/t-slibgcc-darwin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[andreast at gcc dot gnu dot org]

------- Comment #62 from andreast at gcc dot gnu dot org  2009-11-18 07:37 -------
Subject: Bug 39888

Author: andreast
Date: Wed Nov 18 07:37:04 2009
New Revision: 154283

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154283
Log:
2009-11-18  Iain Sandoe <iain.sandoe@sandoe-acoustics.co.uk>

        PR other/39888
        * config/darwin.h: Use the extension stub libraries to access
        current libgcc_s features.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/darwin.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

------- Comment #63 from developer at sandoe-acoustics dot co dot uk  2010-01-22 09:59 -------
this is fixed AFAIK.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

------- Comment #64 from howarth at nitro dot med dot uc dot edu  2010-03-11 03:30 -------
Can someone please close this as fixed? 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[ubizjak at gmail dot com]

------- Comment #65 from ubizjak at gmail dot com  2010-03-11 12:18 -------
Fixed.


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888