From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 31 06:29:15 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2AA2867C; Sun, 31 Mar 2013 06:29:15 +0000 (UTC) (envelope-from jbeich@tormail.org) Received: from outgoing.tormail.org (outgoing.tormail.org [82.221.96.22]) by mx1.freebsd.org (Postfix) with ESMTP id E0817CE5; Sun, 31 Mar 2013 06:29:14 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=internal.tormail.org) by outgoing.tormail.org with esmtp (Exim 4.72) (envelope-from ) id 1UMBlO-0002RF-K7; Sun, 31 Mar 2013 10:29:12 +0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.org; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:References:Date:Subject:Cc:To:From; bh=g4ZMC67m5hkqQPybqHBy7/pJYmhLaH9nUoj0WhUSXqY=; b=OGCGoavL1ddXlFCGU25eK0wBq84ILiY1kyFjQ4HSoSbVyq7uiRlTc4dkOOle37ZJYWzN9IK5+LXZ3X/VJrARfM+hKu5VVukhZSGhR3+O5ePEQoAjebQO9VHiZ5dcw6m+vUALuck78dj3+jtZ+O5i006zjbw/OsEQarAYGlIpPxc=; Received: from jbeich by internal.tormail.org with local (Exim 4.63) (envelope-from ) id 1UMBjC-000FoL-0Y; Sun, 31 Mar 2013 06:26:55 +0000 From: Jan Beich To: Tsurutani Naoki Subject: Re: ports/177224: building www/firefox fails Date: Sun, 31 Mar 2013 08:20:46 +0200 References: <201303290901.AA00161@h115.65.228.10.32118.vlan.kuins.net> MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1UMBjC-000FoL-0Y@internal.tormail.org> Cc: toolchain@freebsd.org, bug-followup@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 06:29:15 -0000 (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.