After upgrading, Portage preserves: >>> package: app-antivirus/clamav-0.99 * - /usr/lib64/libclamunrar.so.6 * - /usr/lib64/libclamunrar.so.6.1.26 * used by /usr/lib64/libclamunrar_iface.so.7.1.1 (app-antivirus/clamav-0.99) which kinda means the new build linked to the old installed library rather than newly-built libclamunrar.so.7.
Created attachment 418688 [details] app-antivirus:clamav-0.99:20151204-162511.log
hmm that seems pretty annoying .. do you have any idea yet why it would do it / how to fix it?
I am tempted to put a dep on it like !<app-antivirus/clamav-0.99 but I'm not sure that is a good idea .. It does work as expected though if one uninstalls clamav first and then re-installs..
That should be !! actually. I'll try to look into the code later if I find time.
I don't see anything obviously wrong with that code. It has: libclamunrar_iface_la_LIBADD = libclamunrar.la so it should be able to use the newly built library... @toolchain, any idea what could be happening here?
the relink install phase favored / over $D: libtool: relink: x86_64-pc-linux-gnu-gcc-5.2.0 -shared -fPIC -DPIC .libs/unrar_iface.o -L/usr/lib64 -L/tmp/portage/app-antivirus/clamav-0.99/image//usr/lib64 -lclamunrar -lpcre -ldl -march=k8-sse3 -mcx16 -msahf -O2 -Wl,--version-script -Wl,../libclamunrar_iface/libclamunrar_iface.map -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-soname -Wl,libclamunrar_iface.so.7 -o .libs/libclamunrar_iface.so.7.1.1 solution: use `elibtoolize --reverse-deps` in src_prepare
Thanks. I shall give this a quick test-run later and commit it -- although it'll probably be tomorrow earliest as I am going to be out most of the rest of the day. If someone wants to do this and revbump feel free.
for some reason this is not really fixing the issue for me. even when running elibtoolize i still get this: /usr/lib64/libclamunrar.so /usr/lib64/libclamunrar.so.6 /usr/lib64/libclamunrar.so.6.1.26 /usr/lib64/libclamunrar.so.7 /usr/lib64/libclamunrar.so.7.1.1 /usr/lib64/libclamunrar_iface.so /usr/lib64/libclamunrar_iface.so.7 /usr/lib64/libclamunrar_iface.so.7.1.1 and this: # ldd /usr/lib64/libclamunrar_iface.so.7.1.1 linux-vdso.so.1 (0x000003db68b69000) libclamunrar.so.6 => /usr/lib64/libclamunrar.so.6 (0x000003db68538000) libpcre.so.1 => /lib64/libpcre.so.1 (0x000003db682f4000) libdl.so.2 => /lib64/libdl.so.2 (0x000003db680f0000) libc.so.6 => /lib64/libc.so.6 (0x000003db67d43000) /lib64/ld-linux-x86-64.so.2 (0x000003db68949000) any ideas on how to really sort this one (except uninstalling earlier clamav first?)
added !!<app-antivirus/clamav-0.99 dep for now to avoid problems of people upgrading.
*** Bug 571542 has been marked as a duplicate of this bug. ***
closing this as the block circumvents the problem and I don't have the time to look into this further. if anyone had a patch feel free to re-open it.
I traced where it's coming from: clamav-0.98.7: LDFLAGS = -Wl,--hash-style=gnu -Wl,-O1 -Wl,--as-needed clamav-0.99: LDFLAGS = -Wl,--hash-style=gnu -Wl,-O1 -Wl,--as-needed -L/usr/lib64 -lpcre # /usr/bin/pcre-config --libs -L/usr/lib64 -lpcre This is still with elibtoolize --reverse: >>> Preparing source in /dev/shm/portage/app-antivirus/clamav-0.99/work/clamav-0.99 ... * Running elibtoolize in: clamav-0.99/ * Applying target-nm/2.4.2 patch ... * Running elibtoolize in: clamav-0.99/config/ * Applying portage/1.2.0 patch ... * Applying sed/1.5.6 patch ... * Applying as-needed/2.4.2 patch ... * Running elibtoolize in: clamav-0.99/libclamav/c++/ * Applying target-nm/2.4.2 patch ... * Running elibtoolize in: clamav-0.99/libclamav/c++/config/ * Applying portage/1.2.0 patch ... * Applying sed/1.5.6 patch ... * Applying as-needed/2.4.2 patch ... * Running elibtoolize in: clamav-0.99/libclamav/c++/llvm/ * Applying target-nm/2.4.2 patch ... * Running elibtoolize in: clamav-0.99/libclamav/c++/llvm/autoconf/ * Applying install-sh/1.5.4 patch ... * Applying portage/1.5.10 patch ... * Applying max_cmd_len/1.5.20 patch ... * Applying sed/1.5.6 patch ... * Applying as-needed/1.5 patch ... * Applying fix-relink/1.5.0 patch ... * Running elibtoolize in: clamav-0.99/win32/3rdparty/zlib/ >>> Source prepared. Notice that fix-relink did not get applied to config/ltmain.sh. I'm looking at why
I do see an automagic dependency on pcre as well, in 0.98.7-r1 it didn't turn on, it 0.99 it did; and isn't specified in the ebuilds at all.
@vapier: should PCRE be including -L/usr/lib64 in the pcre-config --libs output? (dev-libs/libpcre-8.37-r2) # pcre-config --libs -L/usr/lib64 -lpcre As a comparison xml2-config --libs does NOT add it: # xml2-config --libs -lxml2 -lz -lm -ldl
@vapier, reping for comment 14
(In reply to Robin Johnson from comment #14) > @vapier: > should PCRE be including -L/usr/lib64 in the pcre-config --libs output? > (dev-libs/libpcre-8.37-r2) > # pcre-config --libs > -L/usr/lib64 -lpcre > > As a comparison xml2-config --libs does NOT add it: > # xml2-config --libs > -lxml2 -lz -lm -ldl For pkgconfig at least, --libs is suppose to give all the link flags. An example of this is QtXml where pkg-config --libs QtXml gives '-L/usr/lib64/qt4 -lQtXml -lQtCore'. Still -L/usr/lib64 looks wrong.
As a side note, pkg-config strips default libdir from output (i.e. if -L/usr/lib64 is in .pc file, you won't see it).
I shall look into the pcre dep as well thanks for pointing that out. But I still havenT' found a good way around the hard block of <clamav-0.99 yet ..
(In reply to Robin Johnson from comment #14) ideally all xxx-config scripts would omit system -L paths. however, this is already fixed by using libpcre's pkg-config file instead. so if you converted the build to querying pkg-config for pcre deps, that path would go away. (as Michał said)
@vapier I'm not entirely sure what you mean. do you mean patch autoconf/make?
(In reply to Thomas Raschbacher from comment #20) yes. look at m4/reorganization/libs/pcre.m4. you'll want to gut most of that module and replace it with a call to PKG_CHECK_MODULES. you'll want to check with upstream to see if they care ... if they do, you can start with a call to PKG_CHECK_MODULES before falling back to all the hacky tool/config script parsing.
Thanks @vapier . I just commited the pcre dep + a note about the hardblock in the ebuild for now
forgot to close this bug it seems...
I just found this bug after seeing the hard block in the ebuild. Reported upstream at: https://bugzilla.clamav.net/show_bug.cgi?id=12484 (I think we can remove the hard block now, the 0.99 versions are all gone.)
