Summary: | dev-libs/nss-3.12.9-r1 - /usr/lib64/libnspr4.so: undefined reference to `GOMP_parallel_end' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Richard Freeman <rich0> |
Component: | [OLD] Library | Assignee: | Mozilla Gentoo Team <mozilla> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | toolchain |
Priority: | Normal | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info
full build log build environment make build system use cflags nspr-4.8.9-link-flags.patch |
Description
Richard Freeman
2011-05-04 15:49:49 UTC
1) Please post your `emerge --info' output. 2) Please attach the entire build log. Doh - figures. I forgot to actually attach both despite having them ready-to-upload. Re-created and attached. Created attachment 272765 [details]
emerge --info
Created attachment 272767 [details]
full build log
Created attachment 272769 [details]
build environment
Ok, I found one or two other packages with this problem. One was libxslt and I was able to fix that by rebuilding libgcrypt (a dependency) with simplified CFLAGS. My theory is that this error is triggered due to some kind of GCC/autotools bug, when a dependency is built with -ftree-parallelize-loops in some cases. Rebuilding nspr with simplified CFLAGS (-march=amdfam10 -Os -pipe -frename-registers -fweb) fixed the problem. I found this problem with other packages (including some of the qt updates), but I suspect I'll find a similar solution. If any GCC/autotools experts have an idea what the root cause is this might be something worth pointing out to upstream. I don't think this bug is relevant to nss at this point. FYI - root cause worked out by doing some emerge -e nss runs. @toolchain, do you all have any recommendations. A list of packages so far that have had issues with parallelize-loops (I can't guarantee that all of them are the same issue but most have the same error): app-crypt/ophcrack dev-lang/perl dev-lang/python dev-libs/boost dev-libs/gnutls dev-libs/libgcrypt dev-libs/libxslt dev-libs/nspr dev-libs/openssl dev-util/boost-build media-libs/jasper media-libs/libvpx media-video/ffmpeg media-video/handbrake net-misc/netkit-telnetd net-misc/whois sys-block/btrace sys-cluster/hpl sys-cluster/openmpi Sometimes the packages themselves build fine but packages that link to them do not. what is this parallalize-loops you speak of? what were your CFLAGS before you simplified them? Sorry, missed your mention of -ftree-parallelize-loops in comment 6. When you build libraries with -ftree-parallelize-loops it will implicitly enable -fopenmp when building and linking (which also adds -lgomp). The problem you're having occurs when a package that strips flags links to a library containing openmp symbols. Because -ftree-parallelize-loops was stripped out, -lgomp doesn't get passed to the linker and you get unresolved symbols. (In reply to comment #10) > Because -ftree-parallelize-loops was > stripped out, -lgomp doesn't get passed to the linker and you get unresolved > symbols. Ok, that makes sense. Is there anything that really can be improved from a portage tree standpoint here? If not we should probably just close this. Knowing what is going on I can deal with this now, and short of telling ebuild authors not to filter flags unless absolutely necessary I can't really see much that can be done about this from a portage standpoint. I tried whitelisting the flag so it wouldn't be stripped, but nss still fails because the CFLAGS aren't used when linking (I imagine this would also prevent -flto from working properly). Not sure if that would be considered a bug. Does adding -ftree-parallelize-loops to ALLOWED_FLAGS in flag-o-matic help the other packages at all? Will do, but might not get around to it until next week... (In reply to comment #12) this is a bug in nss imo. it should use CFLAGS and LDFLAGS when linking. Created attachment 298411 [details, diff]
make build system use cflags
Guve it a spin and let me know.
../coreconf/command.mk:48: *** Recursive variable `CFLAGS' references itself (eventually). Stop. Looks like it's nspr not being linked using CFLAGS that's actually the problem. Created attachment 298449 [details, diff]
nspr-4.8.9-link-flags.patch
I was wrong about strip-flags being involved. The problem is libgomp never gets linked into libnspr.
before:
tundra ~ # ldd /usr/lib64/libnspr4.so
linux-vdso.so.1 => (0x00007fff0c7ff000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f603b0b8000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f603aeb4000)
libc.so.6 => /lib64/libc.so.6 (0x00007f603ab13000)
/lib64/ld-linux-x86-64.so.2 (0x0000003a89c00000)
after:
tundra ~ # ldd /usr/lib64/libnspr4.so
linux-vdso.so.1 => (0x00007fffb6bff000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2564508000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f2564304000)
libgomp.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/libgomp.so.1 (0x00007f25640f5000)
libc.so.6 => /lib64/libc.so.6 (0x00007f2563d55000)
/lib64/ld-linux-x86-64.so.2 (0x0000003a89c00000)
librt.so.1 => /lib64/librt.so.1 (0x00007f2563b4c000)
nss-3.13.1-r1 then links without error.
(In reply to comment #18) > Created attachment 298449 [details, diff] [details, diff] > nspr-4.8.9-link-flags.patch > > I was wrong about strip-flags being involved. The problem is libgomp never > gets linked into libnspr. > > before: > tundra ~ # ldd /usr/lib64/libnspr4.so > linux-vdso.so.1 => (0x00007fff0c7ff000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f603b0b8000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f603aeb4000) > libc.so.6 => /lib64/libc.so.6 (0x00007f603ab13000) > /lib64/ld-linux-x86-64.so.2 (0x0000003a89c00000) > > after: > tundra ~ # ldd /usr/lib64/libnspr4.so > linux-vdso.so.1 => (0x00007fffb6bff000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2564508000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f2564304000) > libgomp.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/libgomp.so.1 > (0x00007f25640f5000) > libc.so.6 => /lib64/libc.so.6 (0x00007f2563d55000) > /lib64/ld-linux-x86-64.so.2 (0x0000003a89c00000) > librt.so.1 => /lib64/librt.so.1 (0x00007f2563b4c000) > > > nss-3.13.1-r1 then links without error. You are 100% correct. I will commit it after a bit, I have no clue what I was thinking about earlier thanks for getting this sorted. Added to tree. |