On Wed, Dec 10, 2008 at 11:24:28PM +0000, IainS wrote: > Thanks Geoff, > that's v. useful doc. > > On 10 Dec 2008, at 22:36, Geoff Keating wrote: > >> >> On Dec 10, 2008, at 7:32 AM, Jack Howarth wrote: >> >>> On Wed, Dec 10, 2008 at 02:55:11PM +0000, IainS wrote: > > <snip> > >> To use the 'unversioned set' implies that you're compiling for a >> version of Mac OS that Apple has not yet created and most likely will >> never exist. This is not useful. >> >> One way to get extra runtime support is put routines in libgcc.a which >> can be statically linked into executables if they aren't present in the >> system. > > > if one did -lgcc_s.10.x -lgcc_s.1 would that break it? > ... should it not pick up only the unresolved symbols from s.1 > > ( you would also have to be prepared to install libgcc_s.1 in a > suitable place). > >> >> The routines in libgcc_eh.a are routines which should normally never be >> statically linked into executables, because they won't work if you do >> that; they must be in the system. If you need a routine that's in >> libgcc_eh.a, and it's not in the system, you're out of luck; you can't >> use it. You'd need to rewrite it so it can handle being linked into >> multiple executables, or you'd need to create a new shared library, put >> the routine in it, and ship that shared library with every executable >> you create. > > OK, we've got quite a bit of work to do then, all the runtime libs > (gfortran, stdc++v3, gomp, ffi, java) link on libgcc_s.1.dylib > > and, if we want to be able to use gomp, then I we need to find a way to > provide emutls. > > This, obviously, should not be by linking with gcc_eh (since people > would want the current system-provided exception mechanism to continue to > work, I imagine). > > thanks, for the explanations - it's been an educational day! > > Iain
Iain, I think the problem is that we are forcing --shared-libgcc on those testcases that are coming up as UNSUPPORTED. If I recall correctly the --shared-libgcc was added to resolve problems where the libgomp testsuite harness wasn't linking with the g++... http://gcc.gnu.org/ml/gcc/2007-03/msg00479.html http://gcc.gnu.org/ml/gcc/2007-03/msg00485.html http://gcc.gnu.org/ml/gcc/2007-03/msg00495.html http://gcc.gnu.org/ml/gcc/2007-03/msg00532.html The correct fix for gcc 4.5 would be to backout the use of -shared-libgcc from the libgomp testsuite on darwin and fix the test harness to use g++ when appropriate. Jack ps I would also note that you shouldn't need... --enable-version-specific-runtime-libs -- enable-__cxa_atexit --enable-threads -- disable-nls I only use... configure flags: --prefix=/sw --prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-arch=nocona --with-tune=generic --build=i686-apple-darwin9 --host=i686-apple-darwin9 --target=i686-apple-darwin9 and this links in the emutls symbols fine via -static-libgcc. Look at PR35677. The libgomp.fortran/crayptr2.f90 on darwin shows... nm crayptr2.exe | grep emut 00001cd0 t ___emutls_get_address 00001c90 t ___emutls_register_common 00002014 d ___emutls_v.ip.1499 00001f10 t _emutls_destroy 00001ed0 t _emutls_init 00002090 b _emutls_key 00002040 d _emutls_mutex 00002094 b _emutls_size but is linked with -static-libgcc.
