Date: Sun, 31 Mar 2013 08:20:46 +0200 From: Jan Beich <jbeich@tormail.org> To: Tsurutani Naoki <turutani@scphys.kyoto-u.ac.jp> Cc: toolchain@freebsd.org, bug-followup@FreeBSD.org Subject: Re: ports/177224: building www/firefox fails Message-ID: <1UMBjC-000FoL-0Y@internal.tormail.org> References: <201303290901.AA00161@h115.65.228.10.32118.vlan.kuins.net>
next in thread | previous in thread | raw e-mail | index | archive | help
(toolchain@ may know more about clang-devel behavior) Tsurutani Naoki <turutani@scphys.kyoto-u.ac.jp> writes: > building with lang/clang successfully finishes, but firefox crashes > with segmentation fault just after running it. I've asked (privately) devel/llvm maintainer to incorporate r175057 but so far he hasn't responded. http://lists.freebsd.org/pipermail/freebsd-ports/2013-February/081635.html > building without clang successfully finishes, and no errors. > I want a knob to choice the compiler. By setting CC/CXX/CPP you've made the choice. There is no need for a superfluous option for what every port must allow to do. It's just the compiler chosen by default doesn't work. >> ../../dist/bin/libxul.so: undefined reference to `PrepareAndDispatch' >> ../../dist/bin/libxul.so: undefined reference to `invoke_copy_to_stack' >> clang: error: linker command failed with exit code 1 (use -v to see invocation) > > building with lang/clang-devel fails (*1). > (*1) __attribute__((used)) might be ignored with clang-devel (clang 3.3) ? Perhaps, a compiler bug? The following workaround seems to work for clang 3.3 but breaks the build for clang 3.2 / gcc 4.6. --- xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp~ +++ xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp @@ -82,7 +82,7 @@ __asm__ ( "pushl %edx\n\t" /* push this. esp % 16 == 0 */ "movl 0x14(%ebp), %edx\n\t" - "call " SYMBOL_UNDERSCORE "invoke_copy_to_stack\n\t" + "call " SYMBOL_UNDERSCORE "_Z20invoke_copy_to_stackjP13nsXPTCVariantPj\n\t" "movl 0x08(%ebp), %ecx\n\t" /* 'that' */ "movl (%ecx), %edx\n\t" "movl 0x0c(%ebp), %eax\n\t" /* function index */ --- xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp~ +++ xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp @@ -118,7 +118,7 @@ asm(".text\n\t" SYMBOL_UNDERSCORE "SharedStub:\n\t" "leal 0x08(%esp), %ecx\n\t" "movl 0x04(%esp), %edx\n\t" - "jmp " SYMBOL_UNDERSCORE "PrepareAndDispatch\n\t" + "jmp " SYMBOL_UNDERSCORE "_Z18PrepareAndDispatchjP14nsXPTCStubBasePj\n\t" #if !defined(XP_MACOSX) ".size " SYMBOL_UNDERSCORE "SharedStub,.-" SYMBOL_UNDERSCORE "SharedStub" #endif > using [[gnu::used]] instead of above failed: > % make > ... > /usr/local/work/usr/ports/www/firefox/work/mozilla- > release/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp:12:13: error: > '__used__' attribute cannot be applied to types > static void ATTRIBUTE_USED __attribute__ ((regparm(3))) > ^ > ../../../../../../../xpcom/reflect/xptcall/src/md/unix/xptc_gcc_x86_unix.h:19:26: note: > expanded from macro 'ATTRIBUTE_USED' > #define ATTRIBUTE_USED [[gnu::__used__]] > ^ > 1 error generated. > % It may be clang 3.3 is more strict with c++11 attributes. clang 3.2 and gcc 4.8 would still warn about incorrect placement. > In file included from xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp:9:0: > xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp: At global scope: > xpcom/reflect/xptcall/src/md/unix/xptc_gcc_x86_unix.h:19:24: warning: attribute ignored [-Wattributes] > #define ATTRIBUTE_USED [[gnu::used]] > ^ > xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp:12:13: note: in expansion of macro 'ATTRIBUTE_USED' > static void ATTRIBUTE_USED __attribute__ ((regparm(3))) > ^ > xpcom/reflect/xptcall/src/md/unix/xptc_gcc_x86_unix.h:19:24: note: an attribute that appertains to a type-specifier is ignored > #define ATTRIBUTE_USED [[gnu::used]] > ^ > xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp:12:13: note: in expansion of macro 'ATTRIBUTE_USED' > static void ATTRIBUTE_USED __attribute__ ((regparm(3))) > ^ And if you put [[gnu::used]] between invoke_copy_to_stack and () the mangling issue happens again.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1UMBjC-000FoL-0Y>