ports/177224: building www/firefox fails
Jan Beich
jbeich at tormail.org
Sun Mar 31 06:30:01 UTC 2013
The following reply was made to PR ports/177224; it has been noted by GNATS.
From: Jan Beich <jbeich at tormail.org>
To: Tsurutani Naoki <turutani at scphys.kyoto-u.ac.jp>
Cc: bug-followup at FreeBSD.org, toolchain at 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 <turutani at 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.
More information about the freebsd-gecko
mailing list