Message ID | C474C115-7023-4ADC-BAFA-AC4FD978FD7F@sandoe-acoustics.co.uk |
---|---|
State | New |
Headers | show |
On 11/21/2011 07:17 AM, Iain Sandoe wrote: > config: > > * weakref.m4: New file. > > libitm: > > * configure.ac: Use GCC_CHECK_ELF_STYLE_WEAKREF. > * alloc_cpp.cc: Generate dummy functions if we don't > HAVE_ELF_STYLE_WEAKREF. > * eh_cpp.cc: Likewise. > * configure: Regenerate. > * aclocal.m4: Likewise. > * config.h.in: Likewise. Ok. r~
Hello Iain, On 11/21/2011 10:17 AM, Iain Sandoe wrote: > This checked to DTRT on i686-darwin9 (weak ref doesn't behave like > ELF's) and x86-64-darwin10/XCode 3.2.5 (weak ref behaves as per ELF). > > It is my understanding from some off-list discussion reported with the > ld64 engineer - > - that Darwin >= 10 should, in principle, support ELF-style weak refs > (as well as the two-level and flat_namespace versions). I think something is wrong in the configure. Indeed, on apple-darwin10.8.0, weak ref works but it is configure as "no". I guess it should not try to run it but only compile it (or the symbol should exists). Patrick. Part of my config.log configure:17219: checking whether weak refs work like ELF configure:17251: /Users/patrick/gcc/trunk-build/./gcc/xgcc -B/Users/patrick/gcc/trunk-build/./gcc/ -B/Users/patrick/gcc/trunk-install/x86_64-apple-darwin10.8.0/bin/ -B/Users/patrick/gcc/trunk-install/x86_64-apple-darwin10.8.0/lib/ -isystem /Users/patrick/gcc/trunk-install/x86_64-apple-darwin10.8.0/include -isystem /Users/patrick/gcc/trunk-install/x86_64-apple-darwin10.8.0/sys-include -o conftest -g -O2 -pthread -Wl,-undefined,dynamic_lookup conftest.c >&5 configure:17251: $? = 0 configure:17251: ./conftest dyld: Symbol not found: _fNotToBeFound Referenced from: /Users/patrick/gcc/trunk-build/x86_64-apple-darwin10.8.0/libitm/./conftest Expected in: flat namespace in /Users/patrick/gcc/trunk-build/x86_64-apple-darwin10.8.0/libitm/./conftest /Users/patrick/gcc/trunk/libitm/configure: line 1742: 47745 Trace/BPT trap ./conftest$ac_exeext configure:17251: $? = 133 configure: program exited with status 133 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "GNU TM Runtime Library" | #define PACKAGE_TARNAME "libitm" | #define PACKAGE_VERSION "1.0" | #define PACKAGE_STRING "GNU TM Runtime Library 1.0" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "http://www.gnu.org/software/libitm/" | #define PACKAGE "libitm" | #define VERSION "1.0" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define LT_OBJDIR ".libs/" | #define STDC_HEADERS 1 | #define TIME_WITH_SYS_TIME 1 | #define STRING_WITH_STRINGS 1 | #define HAVE_UNISTD_H 1 | #define HAVE_SEMAPHORE_H 1 | #define HAVE_SYS_TIME_H 1 | #define HAVE_MMAP_FILE 1 | #define HAVE_MMAP_ANON 1 | #define HAVE_STRTOULL 1 | #define HAVE_POSIX_MEMALIGN 1 | #define HAVE_BROKEN_POSIX_SEMAPHORES 1 | #define HAVE_TLS 1 | #define HAVE_ATTRIBUTE_VISIBILITY 1 | #define MANGLE_SIZE_T m | #define HAVE_SYNC_BUILTINS 1 | #define HAVE_64BIT_SYNC_BUILTINS 1 | /* end confdefs.h. */ | | extern void fNotToBeFound(void) __attribute__((weak)); | int main () | { | if (fNotToBeFound) | return 1; | else | return 0; | } | configure:17261: result: no
On 6 Jan 2012, at 01:44, Patrick Marlier wrote: > Hello Iain, > > On 11/21/2011 10:17 AM, Iain Sandoe wrote: >> This checked to DTRT on i686-darwin9 (weak ref doesn't behave like >> ELF's) and x86-64-darwin10/XCode 3.2.5 (weak ref behaves as per ELF). >> >> It is my understanding from some off-list discussion reported with >> the >> ld64 engineer - >> - that Darwin >= 10 should, in principle, support ELF-style weak refs >> (as well as the two-level and flat_namespace versions). > > I think something is wrong in the configure. Indeed, on apple- > darwin10.8.0, weak ref works but it is configure as "no". > I guess it should not try to run it but only compile it (or the > symbol should exists). Which tool-chain are you using ? (XCode version) - the problem is tool- chain related. thanks Iain. > > Patrick. > > Part of my config.log > > configure:17219: checking whether weak refs work like ELF > configure:17251: /Users/patrick/gcc/trunk-build/./gcc/xgcc -B/Users/ > patrick/gcc/trunk-build/./gcc/ -B/Users/patrick/gcc/trunk-install/ > x86_64-apple-darwin10.8.0/bin/ -B/Users/patrick/gcc/trunk-install/ > x86_64-apple-darwin10.8.0/lib/ -isystem /Users/patrick/gcc/trunk- > install/x86_64-apple-darwin10.8.0/include -isystem /Users/patrick/ > gcc/trunk-install/x86_64-apple-darwin10.8.0/sys-include -o > conftest -g -O2 -pthread -Wl,-undefined,dynamic_lookup conftest.c > >&5 > configure:17251: $? = 0 > configure:17251: ./conftest > dyld: Symbol not found: _fNotToBeFound > Referenced from: /Users/patrick/gcc/trunk-build/x86_64-apple- > darwin10.8.0/libitm/./conftest > Expected in: flat namespace > in /Users/patrick/gcc/trunk-build/x86_64-apple-darwin10.8.0/libitm/./ > conftest > /Users/patrick/gcc/trunk/libitm/configure: line 1742: 47745 Trace/ > BPT trap ./conftest$ac_exeext > configure:17251: $? = 133 > configure: program exited with status 133 > configure: failed program was: > | /* confdefs.h */ > | #define PACKAGE_NAME "GNU TM Runtime Library" > | #define PACKAGE_TARNAME "libitm" > | #define PACKAGE_VERSION "1.0" > | #define PACKAGE_STRING "GNU TM Runtime Library 1.0" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE_URL "http://www.gnu.org/software/libitm/" > | #define PACKAGE "libitm" > | #define VERSION "1.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #define LT_OBJDIR ".libs/" > > | #define STDC_HEADERS 1 > | #define TIME_WITH_SYS_TIME 1 > | #define STRING_WITH_STRINGS 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_SEMAPHORE_H 1 > | #define HAVE_SYS_TIME_H 1 > | #define HAVE_MMAP_FILE 1 > | #define HAVE_MMAP_ANON 1 > | #define HAVE_STRTOULL 1 > | #define HAVE_POSIX_MEMALIGN 1 > | #define HAVE_BROKEN_POSIX_SEMAPHORES 1 > | #define HAVE_TLS 1 > | #define HAVE_ATTRIBUTE_VISIBILITY 1 > | #define MANGLE_SIZE_T m > | #define HAVE_SYNC_BUILTINS 1 > | #define HAVE_64BIT_SYNC_BUILTINS 1 > | /* end confdefs.h. */ > | > | extern void fNotToBeFound(void) __attribute__((weak)); > | int main () > | { > | if (fNotToBeFound) > | return 1; > | else > | return 0; > | } > | > configure:17261: result: no
On Jan 6, 2012, at 12:29 AM, Iain Sandoe wrote: >> I think something is wrong in the configure. Indeed, on apple-darwin10.8.0, weak ref works but it is configure as "no". >> I guess it should not try to run it but only compile it (or the symbol should exists). > > Which tool-chain are you using ? (XCode version) - the problem is tool-chain related. > thanks 3.2.6 on x86_64-apple-darwin10.8.0 works for me with either -m32 or -m64. If you have an older Xcode 3.2.x, try updating.
On 01/06/2012 10:38 AM, Mike Stump wrote: > On Jan 6, 2012, at 12:29 AM, Iain Sandoe wrote: >>> I think something is wrong in the configure. Indeed, on apple-darwin10.8.0, weak ref works but it is configure as "no". >>> I guess it should not try to run it but only compile it (or the symbol should exists). >> >> Which tool-chain are you using ? (XCode version) - the problem is tool-chain related. >> thanks > > 3.2.6 on x86_64-apple-darwin10.8.0 works for me with either -m32 or -m64. If you have an older Xcode 3.2.x, try updating. 4.0 (build 4A304a) on x86_64-apple-darwin10.8.0. I will try to update it. Thanks.
On Fri, Jan 06, 2012 at 10:58:51AM -0500, Patrick Marlier wrote: > On 01/06/2012 10:38 AM, Mike Stump wrote: >> On Jan 6, 2012, at 12:29 AM, Iain Sandoe wrote: >>>> I think something is wrong in the configure. Indeed, on apple-darwin10.8.0, weak ref works but it is configure as "no". >>>> I guess it should not try to run it but only compile it (or the symbol should exists). >>> >>> Which tool-chain are you using ? (XCode version) - the problem is tool-chain related. >>> thanks >> >> 3.2.6 on x86_64-apple-darwin10.8.0 works for me with either -m32 or -m64. If you have an older Xcode 3.2.x, try updating. > > 4.0 (build 4A304a) on x86_64-apple-darwin10.8.0. I will try to update it. > > Thanks. Using Xcode 4.2 on Snow Leopard, I see the same runtime failure for the configure test of "checking whether weak refs work like ELF"... configure:17251: ./conftest dyld: Symbol not found: _fNotToBeFound Referenced from: /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin10.8.0/libitm/./conftest Expected in: flat namespace in /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin10.8.0/libitm/./conftest /sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20111216/libitm/configure: line 1742: 24547 Trace/BPT trap ./conftest$ac_exeext configure:17251: $? = 133 configure: program exited with status 133 However if I execute the compile line with -v --save-temps and repeat the linkage with... /Developer-3.2.6/usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.6.8 -weak_reference_mismatches non-weak -o conftest -lcrt1.10.6.o -L/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/./gcc -undefined dynamic_lookup conftest.o -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v the resulting binary for conftest runs fine. So we appear to have broken weakref support in the linker for Xcode 4 and later. Jack
On 6 Jan 2012, at 16:42, Jack Howarth wrote: > On Fri, Jan 06, 2012 at 10:58:51AM -0500, Patrick Marlier wrote: >> On 01/06/2012 10:38 AM, Mike Stump wrote: >>> On Jan 6, 2012, at 12:29 AM, Iain Sandoe wrote: >>>>> I think something is wrong in the configure. Indeed, on apple- >>>>> darwin10.8.0, weak ref works but it is configure as "no". >>>>> I guess it should not try to run it but only compile it (or the >>>>> symbol should exists). >>>> >>>> Which tool-chain are you using ? (XCode version) - the problem is >>>> tool-chain related. >>>> thanks >>> >>> 3.2.6 on x86_64-apple-darwin10.8.0 works for me with either -m32 >>> or -m64. If you have an older Xcode 3.2.x, try updating. >> >> 4.0 (build 4A304a) on x86_64-apple-darwin10.8.0. I will try to >> update it. >> >> Thanks. > > Using Xcode 4.2 on Snow Leopard, I see the same runtime failure for > the configure test of > "checking whether weak refs work like ELF"... Note the "like ELF" .. the purpose of the test is to find out if we need to have the dummy routines. (weak refs actually work at runtime for all current versions of Darwin - - the tricky bit is getting the link phase right) Is the resulting libitm working? cheers Iain
On 01/06/2012 12:30 PM, Iain Sandoe wrote: > > On 6 Jan 2012, at 16:42, Jack Howarth wrote: > >> On Fri, Jan 06, 2012 at 10:58:51AM -0500, Patrick Marlier wrote: >>> On 01/06/2012 10:38 AM, Mike Stump wrote: >>>> On Jan 6, 2012, at 12:29 AM, Iain Sandoe wrote: >>>>>> I think something is wrong in the configure. Indeed, on >>>>>> apple-darwin10.8.0, weak ref works but it is configure as "no". >>>>>> I guess it should not try to run it but only compile it (or the >>>>>> symbol should exists). >>>>> >>>>> Which tool-chain are you using ? (XCode version) - the problem is >>>>> tool-chain related. >>>>> thanks >>>> >>>> 3.2.6 on x86_64-apple-darwin10.8.0 works for me with either -m32 or >>>> -m64. If you have an older Xcode 3.2.x, try updating. >>> >>> 4.0 (build 4A304a) on x86_64-apple-darwin10.8.0. I will try to update >>> it. >>> >>> Thanks. >> >> Using Xcode 4.2 on Snow Leopard, I see the same runtime failure for >> the configure test of >> "checking whether weak refs work like ELF"... > > Note the "like ELF" > .. the purpose of the test is to find out if we need to have the dummy > routines. > > (weak refs actually work at runtime for all current versions of Darwin - > - the tricky bit is getting the link phase right) > > Is the resulting libitm working? libitm compiles but the dummy function are used at runtime (eh-1.C testcase fails)... Removing the dummy definitions in eh_cpp.cc makes it compile and work. Patrick.
On 6 Jan 2012, at 18:04, Patrick Marlier wrote: > On 01/06/2012 12:30 PM, Iain Sandoe wrote: >> >> On 6 Jan 2012, at 16:42, Jack Howarth wrote: >> >>> On Fri, Jan 06, 2012 at 10:58:51AM -0500, Patrick Marlier wrote: >>>> On 01/06/2012 10:38 AM, Mike Stump wrote: >>>>> On Jan 6, 2012, at 12:29 AM, Iain Sandoe wrote: >>>>>>> I think something is wrong in the configure. Indeed, on >>>>>>> apple-darwin10.8.0, weak ref works but it is configure as "no". >>>>>>> I guess it should not try to run it but only compile it (or the >>>>>>> symbol should exists). >>>>>> >>>>>> Which tool-chain are you using ? (XCode version) - the problem is >>>>>> tool-chain related. >>>>>> thanks >>>>> >>>>> 3.2.6 on x86_64-apple-darwin10.8.0 works for me with either -m32 >>>>> or >>>>> -m64. If you have an older Xcode 3.2.x, try updating. >>>> >>>> 4.0 (build 4A304a) on x86_64-apple-darwin10.8.0. I will try to >>>> update >>>> it. >>>> >>>> Thanks. >>> >>> Using Xcode 4.2 on Snow Leopard, I see the same runtime failure for >>> the configure test of >>> "checking whether weak refs work like ELF"... >> >> Note the "like ELF" >> .. the purpose of the test is to find out if we need to have the >> dummy >> routines. >> >> (weak refs actually work at runtime for all current versions of >> Darwin - >> - the tricky bit is getting the link phase right) >> >> Is the resulting libitm working? > > libitm compiles but the dummy function are used at runtime (eh-1.C > testcase fails)... > Removing the dummy definitions in eh_cpp.cc makes it compile and work. OK. could you file a PR please? thanks Iain
On Fri, Jan 06, 2012 at 06:07:37PM +0000, Iain Sandoe wrote: > > On 6 Jan 2012, at 18:04, Patrick Marlier wrote: > >> On 01/06/2012 12:30 PM, Iain Sandoe wrote: >>> >>> On 6 Jan 2012, at 16:42, Jack Howarth wrote: >>> >>>> On Fri, Jan 06, 2012 at 10:58:51AM -0500, Patrick Marlier wrote: >>>>> On 01/06/2012 10:38 AM, Mike Stump wrote: >>>>>> On Jan 6, 2012, at 12:29 AM, Iain Sandoe wrote: >>>>>>>> I think something is wrong in the configure. Indeed, on >>>>>>>> apple-darwin10.8.0, weak ref works but it is configure as "no". >>>>>>>> I guess it should not try to run it but only compile it (or the >>>>>>>> symbol should exists). >>>>>>> >>>>>>> Which tool-chain are you using ? (XCode version) - the problem is >>>>>>> tool-chain related. >>>>>>> thanks >>>>>> >>>>>> 3.2.6 on x86_64-apple-darwin10.8.0 works for me with either >>>>>> -m32 or >>>>>> -m64. If you have an older Xcode 3.2.x, try updating. >>>>> >>>>> 4.0 (build 4A304a) on x86_64-apple-darwin10.8.0. I will try to >>>>> update >>>>> it. >>>>> >>>>> Thanks. >>>> >>>> Using Xcode 4.2 on Snow Leopard, I see the same runtime failure for >>>> the configure test of >>>> "checking whether weak refs work like ELF"... >>> >>> Note the "like ELF" >>> .. the purpose of the test is to find out if we need to have the >>> dummy >>> routines. >>> >>> (weak refs actually work at runtime for all current versions of >>> Darwin - >>> - the tricky bit is getting the link phase right) >>> >>> Is the resulting libitm working? >> >> libitm compiles but the dummy function are used at runtime (eh-1.C >> testcase fails)... >> Removing the dummy definitions in eh_cpp.cc makes it compile and work. > > OK. could you file a PR please? > thanks Iain, We have radar Problem ID: 10466868, "-undefined dynamic_lookup linker bug" open with your testcase (which I appended below). Do you recall if Nick ever indicated that this was recognized a real regression in Xcode 4's linker or if it was unsupported behavior on darwin that happened to work with the linker on prior Xcode releases? Also, perhaps we can find someone with access to the Xcode 4.3 pre-release so they can check if this is fixed yet. Jack 17-Nov-2011 08:22 PM Jack Howarth: Summary: The following weak.c test case reveals a linker bug in -undefined dynamic_lookup in Xcode 4.2/4.2.1 under both darwin10 and darwin11. --------------- weak.c --------------------- #include <stdio.h> char *myweakfunc(void) __attribute__((weak)) ; int main(int argc, char **argv) { if (myweakfunc) printf ("found myweakfunc %s\n", myweakfunc()); else printf("Weak func not found\n"); return 0; } ------------------------------------------- Steps to Reproduce: 1) Install Xcode 4.2 on darwin10 or darwin11. 2) Compile the weak.c test case with... /usr/bin/llvm-gcc weak.c -o wk -undefined dynamic_lookup 3) Execute the resulting "wk" executable Expected Results: I expected the same results as is seen when the weak.c test case is compiled with llvm-gcc from Xcode 3.2.6... howarth% /Developer-3.2.6/usr/bin/llvm-gcc weak.c -o wk -undefined dynamic_lookup howarth% ./wk Weak func not found Actual Results: The resulting binary fails to execute with the runtime error... dyld: Symbol not found: _myweakfunc Referenced from: /Users/howarth/./wk Expected in: flat namespace in /Users/howarth/./wk Trace/BPT trap Regression: This can be shown to be a regression in Xcode 4.2's ld since... howarth% /usr/bin/llvm-gcc weak.c -o wk -undefined dynamic_lookup --save-temps howarth% /Developer-3.2.6//usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.6.8 -undefined dynamic_lookup -weak_reference_mismatches non-weak -undefined dynamic_lookup -o wk -lcrt1.10.6.o -L/Developer-3.2.6/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin10/4.2.1/x86_64 -L/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin10/4.2.1/x86_64 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64 -L/usr/lib/i686-apple-darwin10/4.2.1 -L/Developer-3.2.6/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin10/4.2.1 -L/Developer-3.2.6/usr/llvm-gcc-4.2/bin/../lib/gcc -L/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1 -L/Developer-3.2.6/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin10/4.2.1/../../.. -L/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin10/4.2.1/../../.. weak.o -lSystem -lgcc -lSystem howarth% ./wk Weak func not found works when the Xcode 3.2.6 linker is used instead of the Xcode 4.2 linker. Notes: > Iain
Index: config/weakref.m4 =================================================================== --- config/weakref.m4 (revision 0) +++ config/weakref.m4 (revision 0) @@ -0,0 +1,48 @@ + +dnl Check if the target supports weak. +AC_DEFUN([GCC_CHECK_ATTRIBUTE_WEAK], [ + AC_CACHE_CHECK([whether the target supports weak], + ac_cv_have_attribute_weak, [ + weakref_m4_saved_CFLAGS="$CFLAGS" + CFLAGS="$CFLAGS -Werror" + AC_TRY_COMPILE([void __attribute__((weak)) foo(void) { }], + [], ac_cv_have_attribute_weak=yes, + ac_cv_have_attribute_weak=no) + CFLAGS="$weakref_m4_saved_CFLAGS"]) + if test $ac_cv_have_attribute_weak = yes; then + AC_DEFINE(HAVE_ATTRIBUTE_WEAK, 1, + [Define to 1 if the target supports __attribute__((weak)).]) + fi]) + +dnl Check whether weak refs work like the ELF ones. +dnl This means that the weak reference works without having to satify +dnl linkage for the item. +dnl There are targets (at least Darwin) where we have fully functional +dnl weakrefs at runtime, but must supply the referenced item at link time. +AC_DEFUN([GCC_CHECK_ELF_STYLE_WEAKREF], [ + AC_CACHE_CHECK([whether weak refs work like ELF], + ac_cv_have_elf_style_weakref, [ + weakref_m4_saved_CFLAGS="$CFLAGS" + case "${host}" in + *-apple-darwin*) CFLAGS="$CFLAGS -Wl,-undefined,dynamic_lookup" ;; + *) ;; + esac + AC_RUN_IFELSE([AC_LANG_SOURCE([[ +extern void fNotToBeFound(void) __attribute__((weak)); +int main () +{ + if (fNotToBeFound) + return 1; + else + return 0; +} +]])], ac_cv_have_elf_style_weakref=yes, ac_cv_have_elf_style_weakref=no, [ +case "${host}" in + alpha*-dec-osf*) ac_cv_have_elf_style_weakref=no ;; + *-apple-darwin[[89]]*) ac_cv_have_elf_style_weakref=no ;; + *) ac_cv_have_elf_style_weakref=yes;; +esac])CFLAGS="$weakref_m4_saved_CFLAGS"]) +if test x"$ac_cv_have_elf_style_weakref" = xyes; then + AC_DEFINE(HAVE_ELF_STYLE_WEAKREF, 1, [Define to 1 if target has a weakref that works like the ELF one.]) +fi]) + Index: libitm/configure.ac =================================================================== --- libitm/configure.ac (revision 181573) +++ libitm/configure.ac (working copy) @@ -239,6 +239,8 @@ LIBITM_CHECK_SYNC_BUILTINS LIBITM_CHECK_64BIT_SYNC_BUILTINS LIBITM_CHECK_AS_AVX +GCC_CHECK_ELF_STYLE_WEAKREF + # Cleanup and exit. CFLAGS="$save_CFLAGS" AC_CACHE_SAVE Index: libitm/alloc_cpp.cc =================================================================== --- libitm/alloc_cpp.cc (revision 181573) +++ libitm/alloc_cpp.cc (working copy) @@ -60,7 +60,7 @@ extern void _ZdlPvRKSt9nothrow_t (void *, c_nothro extern void *_ZnaXRKSt9nothrow_t (size_t, c_nothrow_p) __attribute__((weak)); extern void _ZdaPvRKSt9nothrow_t (void *, c_nothrow_p) __attribute__((weak)); -#ifdef __osf__ /* Really: !HAVE_WEAKDEF */ +#if !defined (HAVE_ELF_STYLE_WEAKREF) void *_ZnwX (size_t) { return NULL; } void _ZdlPv (void *) { return; } void *_ZnaX (size_t) { return NULL; } @@ -70,7 +70,7 @@ void *_ZnwXRKSt9nothrow_t (size_t, c_nothrow_p) { void _ZdlPvRKSt9nothrow_t (void *, c_nothrow_p) { return; } void *_ZnaXRKSt9nothrow_t (size_t, c_nothrow_p) { return NULL; } void _ZdaPvRKSt9nothrow_t (void *, c_nothrow_p) { return; } -#endif /* __osf__ */ +#endif /* HAVE_ELF_STYLE_WEAKREF */ /* Wrap the delete nothrow symbols for usage with a single argument. Perhaps should have a configure type check for this, because the Index: libitm/eh_cpp.cc =================================================================== --- libitm/eh_cpp.cc (revision 181573) +++ libitm/eh_cpp.cc (working copy) @@ -39,13 +39,13 @@ extern void *__cxa_begin_catch (void *) WEAK; extern void *__cxa_end_catch (void) WEAK; extern void __cxa_tm_cleanup (void *, void *, unsigned int) WEAK; -#ifdef __osf__ /* Really: !HAVE_WEAKDEF */ +#if !defined (HAVE_ELF_STYLE_WEAKREF) void *__cxa_allocate_exception (size_t) { return NULL; } void __cxa_throw (void *, void *, void *) { return; } void *__cxa_begin_catch (void *) { return NULL; } void *__cxa_end_catch (void) { return NULL; } void __cxa_tm_cleanup (void *, void *, unsigned int) { return; } -#endif +#endif /* HAVE_ELF_STYLE_WEAKREF */ }