Found with checksec readelf -d /usr/lib64/libserf-1.so.1.3.0 Dynamic section at offset 0x18540 contains 34 entries: Tag Tipo Nome/Valore 0x0000000000000001 (NEEDED) Libreria condivisa: [libssl.so.1.1] 0x0000000000000001 (NEEDED) Libreria condivisa: [libcrypto.so.1.1] 0x0000000000000001 (NEEDED) Libreria condivisa: [libz.so.1] 0x0000000000000001 (NEEDED) Libreria condivisa: [libapr-1.so.0] 0x0000000000000001 (NEEDED) Libreria condivisa: [libpthread.so.0] 0x0000000000000001 (NEEDED) Libreria condivisa: [libaprutil-1.so.0] 0x0000000000000001 (NEEDED) Libreria condivisa: [libc.so.6] 0x000000000000000e (SONAME) soname della libreria: [libserf-1.so.1] 0x000000000000001d (RUNPATH) runpath della libreria: [/usr/lib64:/var/tmp/portage/dev-libs/apr-util-1.6.1-r6/temp] 0x000000000000000c (INIT) 0x8000 0x000000000000000d (FINI) 0x12ac0 0x0000000000000019 (INIT_ARRAY) 0x18fb0 0x000000000000001b (INIT_ARRAYSZ) 8 (byte) 0x000000000000001a (FINI_ARRAY) 0x18fb8 0x000000000000001c (FINI_ARRAYSZ) 8 (byte) 0x000000006ffffef5 (GNU_HASH) 0x200 0x0000000000000005 (STRTAB) 0x2988 0x0000000000000006 (SYMTAB) 0x9f0 0x000000000000000a (STRSZ) 7412 (byte) 0x000000000000000b (SYMENT) 24 (byte) 0x0000000000000003 (PLTGOT) 0x197a0 0x0000000000000002 (PLTRELSZ) 5640 (byte) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x5ba0 0x0000000000000007 (RELA) 0x49d0 0x0000000000000008 (RELASZ) 4560 (byte) 0x0000000000000009 (RELAENT) 24 (byte) 0x000000000000001e (FLAGS) BIND_NOW 0x000000006ffffffb (FLAGS_1) Flag: NOW 0x000000006ffffffe (VERNEED) 0x4920 0x000000006fffffff (VERNEEDNUM) 4 0x000000006ffffff0 (VERSYM) 0x467c 0x000000006ffffff9 (RELACOUNT) 101 0x0000000000000000 (NULL) 0x0
I don't think /var/tmp/portage is problematic per se, although it's kind of interesting because it isn't going to be owned by root?
I find it curious that this path is there at all, it's for a different package. I did try to reproduce but RUNPATH only has /usr/lib64 for me.
I suspect something strange in output of one of: apu-1-config --includes apu-1-config --ldflags apu-1-config --link-ld apu-1-config --link-libtool apu-1-config --libs Please show them.
Do you maybe use sys-devel/slibtool? If yes, then check if problem disappears after rebuilding dev-libs/apr and dev-libs/apr-util with sys-devel/libtool.
apu-1-config --includes -I/usr/include/apr-1 -I/usr/include/db6.0 apu-1-config --ldflags -L/var/tmp/portage/dev-libs/apr-util-1.6.1-r6/temp apu-1-config --link-ld -laprutil-1 apu-1-config --link-libtool -laprutil-1 apu-1-config --libs -ldb-6.0 -lgdbm -lexpat
I've reemerged apr apr-util and serf without slibtool but I get the same runpath
(In reply to Alessandro Barbieri from comment #5) > apu-1-config --ldflags > -L/var/tmp/portage/dev-libs/apr-util-1.6.1-r6/temp It's not slibtool, looks like this happen when apr-util is built with USE=berkdb (wasn't when I tested before), and sure enough if I build serf after doing this I too get: Library runpath: [/usr/lib64:/tmp/portage/dev-libs/apr-util-1.6.1-r6/temp]