[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug binutils/29042] opcodes libtool regression
From: |
toolybird at tuta dot io |
Subject: |
[Bug binutils/29042] opcodes libtool regression |
Date: |
Sun, 17 Apr 2022 02:11:28 +0000 |
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.