Created attachment 586530 [details] /var/log/portage/net-analyzer:nmap-7.80:20190811-065854.log make -j12 AR=x86_64-pc-linux-gnu-ar RANLIB=x86_64-pc-linux-gnu-ranlib make: *** No rule to make target 'liblinear/Makefile', needed by 'build-liblinear'. Stop. make: *** Waiting for unfinished jobs....
Created attachment 586532 [details] emerge-info.txt
checking for predict in -llinear... no This check should not fail; please attach your config.log.
Created attachment 586534 [details] config.log (In reply to Jeroen Roovers from comment #2) > checking for predict in -llinear... no > > This check should not fail; please attach your config.log. I suppose this is what you're looking for: configure:7227: checking for predict in -llinear configure:7252: x86_64-pc-linux-gnu-gcc-8.3.0 -o conftest -march=x86-64 -mtune=k8 -mcx16 -msahf -msse3 --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -O2 -pipe -frecord-gcc-switches -Wall -I$(top_srcdir)/liblua -I$(top_srcdir)/libdnet-stripped/include -Wl,-E -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 conftest.c -llinear -lm -ldl >&5 /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../lib64/liblinear.so: undefined reference to `dnrm2_' /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../lib64/liblinear.so: undefined reference to `dscal_' /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../lib64/liblinear.so: undefined reference to `daxpy_' /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../lib64/liblinear.so: undefined reference to `ddot_' collect2: error: ld returned 1 exit status
configure:7258: checking for predict in -llinear configure:7283: x86_64-pc-linux-gnu-gcc -o conftest -frecord-gcc-switches -g -pipe -O2 -Wall -march=amdfam10 -mtune=amdfam10 -Wno-comment -Wall -I/usr/include -I$(top_srcdir)/libdnet-stripped/include -L/usr/lib -Wl,-E -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed conftest.c -llinear -lm -llua5.3 -ldl >&5 /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/liblinear.so: undefined reference to `dnrm2_' /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/liblinear.so: undefined reference to `dscal_' /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/liblinear.so: undefined reference to `daxpy_' /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/liblinear.so: undefined reference to `ddot_' collect2: error: ld returned 1 exit status
FWICS liblinear passes -lblas to programs built but not to the shared library.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b07f8b0b5a03243325bcb38264c21319daac11e0 commit b07f8b0b5a03243325bcb38264c21319daac11e0 Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2019-08-11 09:53:41 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2019-08-11 10:06:09 +0000 dev-libs/liblinear: Revert "Add IUSE=blas." In commit 22acd3654a599abcfe5457c157b6e2937a0242ec ("Add IUSE=blas.") I tried to add support for linking against a BLAS implementation as suggested in liblinear's documentation. As so far liblinear does not support any helpers for linking against it as well as a BLAS library in an automated way, enabling USE=blas can result in linking failures in packages that are unaware of the BLAS linkage. Until a pkg-config file or other reliable source for library linkage is provided with liblinear, usage of an external BLAS library cannot be supported. Package-Manager: Portage-2.3.71, Repoman-2.3.17 Fixes: https://bugs.gentoo.org/691926 Signed-off-by: Jeroen Roovers <jer@gentoo.org> dev-libs/liblinear/liblinear-210-r1.ebuild | 15 +-------------- dev-libs/liblinear/liblinear-221.ebuild | 15 +-------------- dev-libs/liblinear/liblinear-230.ebuild | 13 ------------- 3 files changed, 2 insertions(+), 41 deletions(-)
This isn't correct. Since liblinear is a shared library, it is sufficient to pass -lblas when creating it. No pkg-config or other voodoo is necessary.
(In reply to Michał Górny from comment #7) > This isn't correct. Since liblinear is a shared library, it is sufficient > to pass -lblas when creating it. No pkg-config or other voodoo is necessary. In the interest of intelligent discourse, please refrain from underscoring your own unresearched claims as canonical. If you can do the counter-research to come up with a solution that does not involve making all liblinear consumers aware of its libblas linkage, then you are entirely free to make such suggestions without invoking QA magic. As for reopening the bug report: it's unclear how the matter isn't already resolved and fixed to me, so again, in the interest of discourse, I would like you to refrain from changing the status until such a discussion has resulted in consensus among the maintainers and users of both liblinear and nmap.
If instead of solving the problem, you are introducing (or reintroducing) QA violations (bundling libraries is one), then it is a QA matter. Of course, we could play the game of opening another QA bug for it but we could also stop wasting others' time and just solve it on the same bug whose 'solution' introduced the issue. I'm sorry for daring to question your solution without performing hours of research fix. I've done the research now, and surprisingly came with the same solution. I'm sure this is just a coincidence, and not the fact that the problem is trivial and the solution is obvious. In any case, here's the brilliant solution I came up with. Feel free to take the credit, I don't mind. diff --git a/Makefile b/Makefile index 0534f2b..52d3d04 100644 --- a/Makefile +++ b/Makefile @@ -14,7 +14,7 @@ lib: linear.o tron.o blas/blas.a else \ SHARED_LIB_FLAG="-shared -Wl,-soname,liblinear.so.$(SHVER)"; \ fi; \ - $(CXX) $${SHARED_LIB_FLAG} linear.o tron.o blas/blas.a -o liblinear.so.$(SHVER) + $(CXX) $${SHARED_LIB_FLAG} linear.o tron.o blas/blas.a -o liblinear.so.$(SHVER) $(LIBS) train: tron.o linear.o train.c blas/blas.a $(CXX) $(CFLAGS) -o train train.c tron.o linear.o $(LIBS)
(In reply to Michał Górny from comment #9) > If instead of solving the problem, you are introducing (or reintroducing) QA > violations (bundling libraries is one), then it is a QA matter. I guess you don't agree with bug #561874 then?
I'm pretty sure, regardless of whether externally linked blas is the right fix or not, that dropping the USE flag and changing the linkage without a revbump was the wrong thing to do. I have been unable to update nmap on one system and finally revisited the issue - it had a "broken" dev-libs/liblinear-210-r1[blas] leftover on it but nothing called for its rebuild.
(In reply to Daniel M. Weeks from comment #11) > I'm pretty sure, regardless of whether externally linked blas is the right > fix or not, that dropping the USE flag and changing the linkage without a > revbump was the wrong thing to do. I have been unable to update nmap on one > system and finally revisited the issue - it had a "broken" > dev-libs/liblinear-210-r1[blas] leftover on it but nothing called for its > rebuild. Also got bitten by this. Please make net-analyzer/nmap depend on dev-libs/liblinear versions that it can actually successfully build against (that is, the fixed ones).
There is no such useflag anymore, so let's assume this is fixed.
