User account creation filtered due to spam.

Bug 39888 - TLS emutls not linked to automatically on Darwin
Summary: TLS emutls not linked to automatically on Darwin
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: 4.5.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-24 18:39 UTC by Matt Fago
Modified: 2010-03-11 12:18 UTC (History)
3 users (show)

See Also:
Host:
Target: i386-apple-darwin9
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
patch for 4.4-branch (and 4.4.0 release) (5.50 KB, patch)
2009-04-27 19:03 UTC, IainS
Details | Diff
added files for the libgcc_ext patch (1.01 KB, application/octet-stream)
2009-04-27 19:04 UTC, IainS
Details
patch against 4.5 trunk (5.89 KB, patch)
2009-04-27 19:05 UTC, IainS
Details | Diff
updated patch for 4-5 trunk (5.37 KB, patch)
2009-09-24 20:55 UTC, IainS
Details | Diff
build failure on x86_64-apple-darwin10 (51.76 KB, application/octet-stream)
2009-09-24 23:47 UTC, Jack Howarth
Details
i686-apple-darwin10 build log with patch (313.63 KB, application/octet-stream)
2009-09-25 02:19 UTC, Jack Howarth
Details
patch modified to use unexport on libgcc-ext files (6.52 KB, text/plain)
2009-09-26 00:54 UTC, Jack Howarth
Details
much simplified version of the ext patch (1.74 KB, patch)
2009-09-26 17:28 UTC, IainS
Details | Diff
further simplified lib ext patch (2.07 KB, patch)
2009-09-30 16:58 UTC, IainS
Details | Diff
libext patch with ext on as default, debug flag removed and white space changes removed. (1.77 KB, patch)
2009-10-02 08:17 UTC, IainS
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Fago 2009-04-24 18:39:19 UTC
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.
Comment 1 IainS 2009-04-27 19:03:54 UTC
Created attachment 17769 [details]
patch for 4.4-branch (and 4.4.0 release)

don't forget to add the version files.
Comment 2 IainS 2009-04-27 19:04:54 UTC
Created attachment 17770 [details]
added files for the libgcc_ext patch
Comment 3 IainS 2009-04-27 19:05:54 UTC
Created attachment 17771 [details]
patch against 4.5 trunk

also needs the added files
Comment 4 IainS 2009-04-27 19:07:12 UTC
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...

Comment 5 IainS 2009-04-27 19:15:11 UTC
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
Comment 6 Mike Stump 2009-09-22 18:56:34 UTC
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; \
Comment 7 IainS 2009-09-22 19:20:39 UTC
(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?
Comment 8 Mike Stump 2009-09-22 21:17:55 UTC
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.
Comment 9 Jack Howarth 2009-09-23 03:02:31 UTC
(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?
Comment 10 Jack Howarth 2009-09-23 15:50:09 UTC
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.
Comment 11 IainS 2009-09-23 16:00:41 UTC
(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.

Comment 12 Jack Howarth 2009-09-23 16:19:21 UTC
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.
Comment 13 Jack Howarth 2009-09-23 16:28:35 UTC
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.
Comment 14 IainS 2009-09-23 16:36:23 UTC
(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.
Comment 15 Jack Howarth 2009-09-23 16:50:46 UTC
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).
Comment 16 Jack Howarth 2009-09-23 17:53:39 UTC
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?
Comment 17 Jack Howarth 2009-09-23 18:40:52 UTC
(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?
Comment 18 Jack Howarth 2009-09-23 18:57:03 UTC
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.
Comment 19 Mike Stump 2009-09-23 20:43:58 UTC
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.
Comment 20 Mike Stump 2009-09-23 20:48:31 UTC
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?
Comment 21 Mike Stump 2009-09-23 20:49:21 UTC
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?
Comment 22 Mike Stump 2009-09-23 20:52:34 UTC
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.
Comment 23 Jack Howarth 2009-09-23 21:06:27 UTC
(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,
Comment 24 Jack Howarth 2009-09-23 21:18:18 UTC
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?
Comment 25 Jack Howarth 2009-09-23 23:45:09 UTC
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.
Comment 26 IainS 2009-09-24 07:46:46 UTC
(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.

Comment 27 Jack Howarth 2009-09-24 13:06:33 UTC
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.
Comment 28 Jack Howarth 2009-09-24 13:15:14 UTC
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?
Comment 29 IainS 2009-09-24 20:55:18 UTC
Created attachment 18644 [details]
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 ;)
Comment 30 Jack Howarth 2009-09-24 22:33:38 UTC
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....
Comment 31 IainS 2009-09-24 22:42:28 UTC
(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
Comment 32 Jack Howarth 2009-09-24 23:47:21 UTC
Created attachment 18645 [details]
build failure on x86_64-apple-darwin10
Comment 33 Jack Howarth 2009-09-24 23:48:26 UTC
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.
Comment 34 Jack Howarth 2009-09-25 01:20:29 UTC
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.
Comment 35 Jack Howarth 2009-09-25 02:19:39 UTC
Created attachment 18647 [details]
i686-apple-darwin10 build log with patch
Comment 36 IainS 2009-09-25 10:07:34 UTC
(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.
Comment 37 Jack Howarth 2009-09-25 10:44:52 UTC
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. 
Comment 38 IainS 2009-09-25 10:54:34 UTC
(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)
Comment 39 Jack Howarth 2009-09-25 19:16:53 UTC
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.
Comment 40 IainS 2009-09-25 19:25:12 UTC
(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.
Comment 41 Jack Howarth 2009-09-25 23:51:46 UTC
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.
Comment 42 Jack Howarth 2009-09-26 00:54:43 UTC
Created attachment 18652 [details]
patch modified to use unexport on libgcc-ext files
Comment 43 Jack Howarth 2009-09-26 00:59:50 UTC
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.

Comment 44 Jack Howarth 2009-09-26 02:55:27 UTC
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.
Comment 45 Jack Howarth 2009-09-26 05:51:25 UTC
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.
Comment 46 IainS 2009-09-26 17:28:43 UTC
Created attachment 18657 [details]
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.
Comment 47 Jack Howarth 2009-09-26 20:36:12 UTC
(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.


Comment 48 IainS 2009-09-28 07:47:58 UTC
(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.

Comment 49 IainS 2009-09-28 09:02:05 UTC
(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
Comment 50 IainS 2009-09-30 16:58:24 UTC
Created attachment 18677 [details]
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).
Comment 51 Mike Stump 2009-09-30 19:45:52 UTC
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?
Comment 52 IainS 2009-09-30 19:54:01 UTC
(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.
Comment 53 Jack Howarth 2009-09-30 23:36:27 UTC
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.
Comment 54 Jack Howarth 2009-09-30 23:38:34 UTC
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
Comment 55 IainS 2009-10-01 08:36:38 UTC
(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.
Comment 56 Jack Howarth 2009-10-01 13:59:47 UTC
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?
Comment 57 IainS 2009-10-01 17:22:22 UTC
(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.
 
Comment 58 Mike Stump 2009-10-01 19:18:34 UTC
Seems reasonable.
Comment 59 IainS 2009-10-02 08:17:05 UTC
Created attachment 18691 [details]
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)
Comment 60 IainS 2009-10-02 10:39:19 UTC
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
Comment 61 Andreas Tobler 2009-11-18 07:36:26 UTC
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

Comment 62 Andreas Tobler 2009-11-18 07:37:18 UTC
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

Comment 63 IainS 2010-01-22 09:59:22 UTC
this is fixed AFAIK.
Comment 64 Jack Howarth 2010-03-11 03:30:42 UTC
Can someone please close this as fixed? 
Comment 65 Uroš Bizjak 2010-03-11 12:18:08 UTC
Fixed.