slibtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -I/include -mmmx -msse -msse2 -msse3 -fopenmp -Os -pipe -march=native -Os -pipe -march=native -Wimplicit-function-declaration -Wno-error=implicit-function-declaration -release 0.0.20200115 -no-undefined -L/lib -Wl,-O1 -Wl,--as-needed -o libm4rie.la -rpath /usr/lib64 m4rie/gf2e.lo m4rie/mzed.lo m4rie/newton_john.lo m4rie/echelonform.lo m4rie/strassen.lo m4rie/mzd_slice.lo m4rie/mzd_poly.lo m4rie/mzd_ptr.lo m4rie/karatsuba.lo m4rie/blm.lo m4rie/trsm.lo m4rie/ple.lo m4rie/conversion.lo m4rie/conversion_slice8.lo m4rie/conversion_slice16.lo m4rie/conversion_cling8.lo m4rie/conversion_cling16.lo -lm4ri slibtool: link: ar crs .libs/libm4rie.a m4rie/.libs/gf2e.o m4rie/.libs/mzed.o m4rie/.libs/newton_john.o m4rie/.libs/echelonform.o m4rie/.libs/strassen.o m4rie/.libs/mzd_slice.o m4rie/.libs/mzd_poly.o m4rie/.libs/mzd_ptr.o m4rie/.libs/karatsuba.o m4rie/.libs/blm.o m4rie/.libs/trsm.o m4rie/.libs/ple.o m4rie/.libs/conversion.o m4rie/.libs/conversion_slice8.o m4rie/.libs/conversion_slice16.o m4rie/.libs/conversion_cling8.o m4rie/.libs/conversion_cling16.o slibtool: link: x86_64-pc-linux-gnu-gcc m4rie/.libs/gf2e.o m4rie/.libs/mzed.o m4rie/.libs/newton_john.o m4rie/.libs/echelonform.o m4rie/.libs/strassen.o m4rie/.libs/mzd_slice.o m4rie/.libs/mzd_poly.o m4rie/.libs/mzd_ptr.o m4rie/.libs/karatsuba.o m4rie/.libs/blm.o m4rie/.libs/trsm.o m4rie/.libs/ple.o m4rie/.libs/conversion.o m4rie/.libs/conversion_slice8.o m4rie/.libs/conversion_slice16.o m4rie/.libs/conversion_cling8.o m4rie/.libs/conversion_cling16.o -I/include -mmmx -msse -msse2 -msse3 -fopenmp -Os -pipe -march=native -Os -pipe -march=native -Wimplicit-function-declaration -Wno-error=implicit-function-declaration -L/lib -Wl,-O1 -Wl,--as-needed -lm4ri -shared -fPIC -Wl,--no-undefined -Wl,-soname -Wl,libm4rie-0.0.20200115.so -o .libs/libm4rie-0.0.20200115.so /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: m4rie/.libs/strassen.o: in function `_mzed_strassen_cutoff': strassen.c:(.text+0xe6b): undefined reference to `sqrt' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: strassen.c:(.text+0xea0): undefined reference to `sqrt' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: m4rie/.libs/mzd_poly.o: in function `_mzd_poly_addmul_ext1': mzd_poly.c:(.text+0x19c): undefined reference to `log2' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: mzd_poly.c:(.text+0x1a1): undefined reference to `ceil' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: m4rie/.libs/blm.o: in function `crt_init': blm.c:(.text+0x679): undefined reference to `ceil' collect2: error: ld returned 1 exit status slibtool: exec error upon slbt_exec_link_create_library(), line 1446: (see child process error messages). slibtool: < returned to > slbt_exec_link(), line 1836. make[1]: *** [Makefile:599: libm4rie.la] Error 2 make[1]: Leaving directory '/var/tmp/portage/sci-libs/m4rie-20200115/work/m4rie-20200115' make: *** [Makefile:716: all-recursive] Error 1 * ERROR: sci-libs/m4rie-20200115::gentoo failed (compile phase): * emake failed
Created attachment 690597 [details] m4rie-20200115:20210310-210910.log buildlog
How quaint, using slibtool, `-lm` doesn't seem to be provided. Need to investigate further.
Did m4ri pass?
(In reply to François Bissey from comment #2) > How quaint, using slibtool, `-lm` doesn't seem to be provided. Need to > investigate further. Using slibtool fixes another problem, namely that the system-installed "libtool" on Gentoo has the compiler/linker hard-coded into it. So if you build sys-devel/libtool with GCC and then switch to clang for a project that doesn't use autotools (but does use libtool), all hell breaks loose.
(In reply to Michael Orlitzky from comment #4) > (In reply to François Bissey from comment #2) > > How quaint, using slibtool, `-lm` doesn't seem to be provided. Need to > > investigate further. > > Using slibtool fixes another problem, namely that the system-installed > "libtool" on Gentoo has the compiler/linker hard-coded into it. So if you > build sys-devel/libtool with GCC and then switch to clang for a project that > doesn't use autotools (but does use libtool), all hell breaks loose. I would consider that a bug. libtool is not supposed to hard code a compiler until you run configure when a compiler is set. And even that is an annoying behavior because nvcc is considered a C compiler and that means it is fairly hard to mix cuda code and regular C code with libtool. Or more generally if you were wanting for whatever reasons to mix C compilers (I don't suggest you try that with other languages which don't have an ABI as strongly defined).
For the original matter, m4rie should probably detect libm in configure. This is an upstream issue. I'll have to check if they already fixed that or need to open an issue.
Actually `-lm` is provided in the m4rie.pc file. So it may be a case where upstream underlinks the library because it is legal, and you always compile it with `-lm` if you use the .pc file as intended. A quick fix is to use append-libs from flag-o-matic.
https://bitbucket.org/malb/m4rie/issues/22/distro-qa-about-underlinking-with-libm
(In reply to François Bissey from comment #5) > > I would consider that a bug. libtool is not supposed to hard code a compiler > until you run configure when a compiler is set. Oh, absolutely. But when the bug (bug #88596) is from 2005, sometimes you have to take matters into your own hands. There was a mailing list thread not too long ago about it: https://archives.gentoo.org/gentoo-dev/message/abf2e3c467542c9958107fbc4a716ef9
Seems this was fixed upstream already. https://bitbucket.org/malb/m4rie/commits/afab50ea468b
Created attachment 691875 [details, diff] https://bitbucket.org/malb/m4rie/commits/afab50ea468b
Yes, upstream was very responsive to my bug report.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=84f79a6a4096a5e5135bd0965e8f696e18a699b7 commit 84f79a6a4096a5e5135bd0965e8f696e18a699b7 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2021-03-17 02:41:56 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2021-03-17 02:42:11 +0000 sci-libs/m4rie: new revision with patch for libm linking. Thanks to Alessandro Barbieri, François Bissey, and Martin Albrecht (upstream) for getting this fixed quickly. This commit adds an -r1 with the backported patch and a call to eautoreconf. Closes: https://bugs.gentoo.org/775311 Package-Manager: Portage-3.0.13, Repoman-3.0.2 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> .../m4rie/files/m4rie-20200115-link-libm.patch | 27 ++++++++++++++++++++++ ...ie-20200115.ebuild => m4rie-20200115-r1.ebuild} | 12 +++++++++- 2 files changed, 38 insertions(+), 1 deletion(-)
