Bug 681656 – dev-lang/spidermonkey built with sys-devel/clang is missing some symbols

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description Oleh 2019-03-24 12:50:22 UTC]

As in summary.

Reproducible: Always

Steps to Reproduce:
1. Setup the system with clang as default compiler
2. emerge -1 sys-auth/polkit
3. Notice build failure.
4. Switch dev-lang/spidermonkey to compile with sys-devel/gcc
5. sys-auth/polkit compiled and installed.
Actual Results:  
/bin/sh ../../libtool  --tag=CXX   --mode=link clang++ -D_POLKIT_COMPILATION -D_POLKIT_BACKEND_COMPILATION -pthread -I/usr/include/gio-unix-2.0/ -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/uuid -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include  -include /usr/include/mozjs-52/js/RequiredDefines.h -I/usr/include/mozjs-52 -I/usr/include/nspr  -march=native -O2 -pipe  -Wl,--as-needed -Wl,-O2 -Wl,--as-needed -o libpolkit-backend-1.la   libpolkit_backend_1_la-polkitbackendauthority.lo libpolkit_backend_1_la-polkitbackendinteractiveauthority.lo libpolkit_backend_1_la-polkitbackendjsauthority.lo libpolkit_backend_1_la-polkitbackendactionpool.lo libpolkit_backend_1_la-polkitbackendactionlookup.lo  libpolkit_backend_1_la-polkitbackendsessionmonitor-systemd.lo  -Wl,--export-dynamic -lgmodule-2.0 -pthread -lgio-2.0 -lgobject-2.0 -lglib-2.0 -L/lib64 -lsystemd ../../src/polkit/libpolkit-gobject-1.la -lexpat -lmozjs-52  
libtool: link: llvm-ar cru .libs/libpolkit-backend-1.a .libs/libpolkit_backend_1_la-polkitbackendauthority.o .libs/libpolkit_backend_1_la-polkitbackendinteractiveauthority.o .libs/libpolkit_backend_1_la-polkitbackendjsauthority.o .libs/libpolkit_backend_1_la-polkitbackendactionpool.o .libs/libpolkit_backend_1_la-polkitbackendactionlookup.o .libs/libpolkit_backend_1_la-polkitbackendsessionmonitor-systemd.o 
libtool: link: llvm-ranlib .libs/libpolkit-backend-1.a
libtool: link: ( cd ".libs" && rm -f "libpolkit-backend-1.la" && ln -s "../libpolkit-backend-1.la" "libpolkit-backend-1.la" )
/bin/sh ../../libtool  --tag=CXX   --mode=link clang++  -march=native -O2 -pipe  -Wl,--as-needed -Wl,-O2 -Wl,--as-needed -o polkitd polkitd-polkitd.o  -Wl,--export-dynamic -lgmodule-2.0 -pthread -lgio-2.0 -lgobject-2.0 -lglib-2.0 ../../src/polkit/libpolkit-gobject-1.la libpolkit-backend-1.la  
libtool: link: clang++ -march=native -O2 -pipe -Wl,-O2 -o .libs/polkitd polkitd-polkitd.o -Wl,--export-dynamic -pthread  -Wl,--as-needed ../../src/polkit/.libs/libpolkit-gobject-1.so -L/lib64 ./.libs/libpolkit-backend-1.a -lpthread /var/src/build/portage/sys-auth/polkit-0.115-r3/work/polkit-0.115/src/polkit/.libs/libpolkit-gobject-1.so -lgmodule-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lsystemd -lexpat -lmozjs-52 -pthread
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: ./.libs/libpolkit-backend-1.a(libpolkit_backend_1_la-polkitbackendjsauthority.o): in function `JS::StructGCPolicy<JS::GCVector<JS::Value, 8ul, js::TempAllocPolicy> >::trace(JSTracer*, JS::GCVector<JS::Value, 8ul, js::TempAllocPolicy>*, char const*)':
polkitbackendjsauthority.cpp:(.text._ZN2JS14StructGCPolicyINS_8GCVectorINS_5ValueELm8EN2js15TempAllocPolicyEEEE5traceEP8JSTracerPS5_PKc[_ZN2JS14StructGCPolicyINS_8GCVectorINS_5ValueELm8EN2js15TempAllocPolicyEEEE5traceEP8JSTracerPS5_PKc]+0x3a): undefined reference to `void js::UnsafeTraceManuallyBarrieredEdge<JS::Value>(JSTracer*, JS::Value*, char const*)'
clang-8: [0;1;31merror: [0mlinker command failed with exit code 1 (use -v to see invocation)[0m

[Comment 1 Oleh 2019-03-24 12:51:24 UTC]

Created attachment 570602 [details]
build log

[Comment 2 Oleh 2019-03-24 12:51:53 UTC]

Created attachment 570604 [details]
emerge --info

[Comment 3 Ian Stakenvicius (RETIRED) 2019-03-27 15:24:12 UTC]

I've confirmed this too with 52.x.

It seems upstream is still working on a fix, as the one(s) proposed don't suffice.  I don't know the best interim solution at this point but I'll look into how we can either force gcc or warn/error-out if clang is being used.  Both polkit and gjs apparently have these issues so likely the package can be considered 'broken' in all cases.

[Comment 4 Arfrever Frehtes Taifersar Arahesis 2019-03-28 01:27:10 UTC]

(In reply to Ian Stakenvicius from comment #3)
> how we can either force gcc

Until more automatic solution is provided by toolchain-funcs.eclass:

inherit flag-o-matic toolchain-funcs
...
src_configure() {
  if tc-is-clang; then
    export CC="${CHOST}-gcc"
    export CXX="${CHOST}-g++"
    strip-unsupported-flags
  fi
  ...

[Comment 5 Ian Stakenvicius (RETIRED) 2019-04-23 15:34:49 UTC]

I have just reproduced this same issue with gcc, so avoiding clang isn't necessarily going to fix it.

[Comment 6 Jory A. Pratt 2019-04-23 16:21:06 UTC]

(In reply to Ian Stakenvicius from comment #5)
> I have just reproduced this same issue with gcc, so avoiding clang isn't
> necessarily going to fix it.

Well give some detail on how to reproduce.

[Comment 7 Ian Stakenvicius (RETIRED) 2019-04-24 13:45:25 UTC]

(In reply to Jory A. Pratt from comment #6)
> (In reply to Ian Stakenvicius from comment #5)
> > I have just reproduced this same issue with gcc, so avoiding clang isn't
> > necessarily going to fix it.
> 
> Well give some detail on how to reproduce.

I haven't been able to yet, rebuilds of spidermonkey with gcc7 and gcc8 have been fine.  This may have been an odd distcc messup the first time around (as I was using distcc at the time).  I'll report what I find if I can actually reproduce it with gcc again.

[Comment 8 Markus Peloquin 2019-10-30 07:15:39 UTC]

Looks like it will be fixed in version 72:
https://bugzilla.mozilla.org/show_bug.cgi?id=1426865#c45

Maybe the patches could apply cleanly to 60, but I have still been able to work around not having polkit.

[Comment 9 tt_1 2019-11-03 19:03:55 UTC]

There's a backport available for esr-68.0, I dropped the patchset into the patches folder and will take a testdrive with them now.

[Comment 10 Jory A. Pratt 2020-06-27 19:56:23 UTC]

*** Bug 729904 has been marked as a duplicate of this bug. ***

[Comment 11 Sam James 2022-11-24 11:30:41 UTC]

spidermonkey <78 is no longer in tree. The codebase has changed substantially since then, so closing.