I'm getting compile errors for the newly stabilized nss. I'm fearful that they could be an obscure toolchain problem, as the problem comes up when I try to build the version of nss I currently have installed. Logs attached. Relevant error message: x86_64-pc-linux-gnu-gcc -o Linux2.6_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/ addbuiltin -O2 -fno-strict-aliasing -ansi -D_POSIX_SOURCE -D_BSD_SOURCE -D_XOPEN_SOURCE -fPIC -DLINUX2_1 -Wall -Werror-implicit-function-declaration -Wno-switch -pipe -DLINUX -Dlinux -DHAVE_STRERROR -DXP_UNIX -UDEBUG -DNDEBUG -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_U TIL_DIRECTLY -I/usr/include/nspr -I../../../dist/Linux2.6_x86_64_x86_64-pc-linux-gnu-gcc _glibc_PTH_64_OPT.OBJ/include -I../../../dist/public/nss -I../../../dist/private/nss - I/usr/include/nspr -I../../../dist/Linux2.6_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_ OPT.OBJ/include/dbm -I../../../dist/public/seccmd -march=amdfam10 -O2 -pipe Linux2.6_x8 6_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/addbuiltin.o -Wl,-O1 -Wl,--as-needed -Wl,--as-needed ../../../dist/Linux2.6_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/lib/libsectool.a -Wl,-rpath,'$ORIGIN/../lib64:$ORIGIN/../lib' -L../../../dist/Linux2.6_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/lib -lssl3 -lsmime3 -lnss3 -L../../../dist/Linux2.6_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/lib -lnssutil3 -L/usr/lib64 -lplc4 -lplds4 -lnspr4 -lpthread -ldl -lc /usr/lib64/libnspr4.so: undefined reference to `GOMP_parallel_end' /usr/lib64/libnspr4.so: undefined reference to `omp_get_num_threads' /usr/lib64/libnspr4.so: undefined reference to `GOMP_parallel_start' /usr/lib64/libnspr4.so: undefined reference to `omp_get_thread_num' collect2: ld returned 1 exit status If I go into the build directory and execute the last command with -fopenmp it executes fine. Could the bug be related to whether USE=openmp is set on gcc? I'm not sure why the package is trying to use those functions without -fopenmp. Reproducible: Always
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.
