https://sourceware.org/bugzilla/show_bug.cgi?id=29042
--- Comment #4 from Toolybird <toolybird at tuta dot io> --- This bug is a little more serious than I first thought. Even when /usr/lib/libiberty.a does not exist, the following combination of switches results in the wrong libiberty.a getting linked in: --prefix=/usr --enable-shared --enable-install-libiberty $ make -j2 prefix=/build/binutils/tmp/usr install In the verbose log I see this: attempt to open /build/binutils/tmp/usr/lib/libiberty.a succeeded This means libopcodes is (re)linking against a non-pic libiberty. This is definitely wrong. Problem goes away with `make -j1 ...install'. I noticed this while investigating issues of reproducibility. A lot of build systems put "-j (n>1)" globally into MAKEFLAGS. What is the common wisdom here? Always `make install' binutils with -j1 ? Thanks -- You are receiving this mail because: You are on the CC list for the bug.
