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.
Created attachment 17769 [details] patch for 4.4-branch (and 4.4.0 release) don't forget to add the version files.
Created attachment 17770 [details] added files for the libgcc_ext patch
Created attachment 17771 [details] patch against 4.5 trunk also needs the added files
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...
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
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; \
(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?
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.
(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?
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.
(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.
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.
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.
(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.
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).
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?
(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?
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.
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.
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?
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?
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.
(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,
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?
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.
(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.
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.
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?
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 ;)
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....
(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
Created attachment 18645 [details] build failure on x86_64-apple-darwin10
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.
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.
Created attachment 18647 [details] i686-apple-darwin10 build log with patch
(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.
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.
(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)
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.
(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.
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.
Created attachment 18652 [details] patch modified to use unexport on libgcc-ext files
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.
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.
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.
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.
(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.
(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.
(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
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).
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?
(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.
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.
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
(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.
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?
(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.
Seems reasonable.
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)
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
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
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
this is fixed AFAIK.
Can someone please close this as fixed?
Fixed.