From owner-freebsd-gecko@FreeBSD.ORG Sun Mar 31 06:30:01 2013 Return-Path: Delivered-To: gecko@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BD6856A9 for ; Sun, 31 Mar 2013 06:30:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B0530CEC for ; Sun, 31 Mar 2013 06:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2V6U1tr031488 for ; Sun, 31 Mar 2013 06:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2V6U10A031487; Sun, 31 Mar 2013 06:30:01 GMT (envelope-from gnats) Date: Sun, 31 Mar 2013 06:30:01 GMT Message-Id: <201303310630.r2V6U10A031487@freefall.freebsd.org> To: gecko@FreeBSD.org From: Jan Beich Subject: Re: ports/177224: building www/firefox fails X-BeenThere: freebsd-gecko@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Jan Beich List-Id: Gecko Rendering Engine issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 06:30:01 -0000 The following reply was made to PR ports/177224; it has been noted by GNATS. From: Jan Beich To: Tsurutani Naoki Cc: bug-followup@FreeBSD.org, toolchain@freebsd.org Subject: Re: ports/177224: building www/firefox fails Date: Sun, 31 Mar 2013 08:20:46 +0200 (toolchain@ may know more about clang-devel behavior) Tsurutani Naoki 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.