Created attachment 918754 [details] dev-libs/protobuf-c-1.5.1 build log Hello there! It is impossible to install dev-libs/protobuf-c-1.5.1 after successful compilation. I see message: install: cannot stat 'protobuf-c/.libs/libprotobuf-c.so.1.0.0': No such file or directory install-xattr: failed to stat /var/tmp/portage/dev-libs/protobuf-c-1.5.1/image/usr/lib64/libprotobuf-c.so.1.0.0: No such file or directory Full log added.
Created attachment 918755 [details] emegre.info env.
I suspect it's a parallel build issue. Does MAKEOPTS="-j1" work?
Hello! I've fixed MAKEOPTS="-j1" and got the same result: install: cannot stat 'protobuf-c/.libs/libprotobuf-c.so.1.0.0': No such file or directory
I bet it works if you try with GCC. I think this might be an old libtool thing.
Hello, Sam! Thank You for information. Yes, it was correct - I've switched to GCC ans J=1 and issue was solved. Ticket can be closed as well
We may want/need to add a patch to elt-patches to help this for old libtool.
I observed the same problem (libtool just skipping the link step from .la to .so) in the various xf86-input/video drivers when they were rebuilt due to the xorg-server update. When diffing the configure logs I noticed that it decided that "/usr/lib/llvm/19/bin/x86_64-pc-linux-gnu-ld" is "not the GNU linker" and then generously skipped the link step. Passing LD=ld made it work.
(In reply to Holger Hoffstätte from comment #7) > I observed the same problem (libtool just skipping the link step from .la to > .so) in the various xf86-input/video drivers when they were rebuilt due to > the xorg-server update. When diffing the configure logs I noticed that it > decided that "/usr/lib/llvm/19/bin/x86_64-pc-linux-gnu-ld" is "not the GNU > linker" and then generously skipped the link step. Passing LD=ld made it > work. That's because my installation of lld was broken (completely unrelated problem), and the check said "no". It answered "yes" on another system, where everything worked. Sorry for the noise. However it does mean that this: > checking if the linker (lld) is GNU ld... no is the reason for libtool skipping the link step.
$CC=clang CXX=clang++ LD=lld ebuild protobuf-c-1.5.1.ebuild clean configure ... checking for ld used by clang... lld checking if the linker (lld) is GNU ld... no ... vs. $CC=CC=clang CXX=clang++ LD=ld.lld ebuild protobuf-c-1.5.1.ebuild clean configure ... checking for ld used by clang... ld.lld checking if the linker (ld.lld) is GNU ld... yes ... libtool checks ld output with -v: $lld -v lld is a generic driver. Invoke ld.lld (Unix), ld64.lld (macOS), lld-link (Windows), wasm-ld (WebAssembly) instead vs. $ld.lld -v LLD 19.1.7 (compatible with GNU linkers)
