This package fails to compile on an unstable system. Attached relevant logs and emerge --info
Created attachment 708774 [details] emerge_info emerge --info
Created attachment 708777 [details] eclib-20190909:20210515-115133.log build log
I mean, it’s more than an “unstable system”, it’s slibtool at least.
I confirm that is rlibtool the issue
I can't reproduce even with rlibtool and same USE, I assume there's something more to this again.
I added eclib-20210503 a few days ago. Does it share the same problem? (If not, it may not be worth investigating the old version.)
I'm not sure who's to blame here. Part of the problem is that ax_boost_base.m4 autodetects -L/usr/lib64 as the flag that corresponds to boost's location. It then winds up in LDFLAGS, and gets passed to the build system... x86_64-pc-linux-gnu-g++ solve_conic.o -Os -pipe -march=native -fdiagnostics-color=always -fexceptions -Wformat -fstack-clash-protection -L/usr/lib64 -pthread -Wl,-O1 -Wl,--as-needed -Wl,--sort-common -L../libsrc/.libs -lec -lflint -lntl -lpari -lboost_system-mt -lboost_thread -lflint -lpari -lntl -lboost_system-mt -o .libs/solve_conic pre-empting the "-L../libsrc/.libs -lec" which is supposed to link against the just-built libec, and not the previous version that is installed in /usr/lib64. When it tries to link against /usr/lib64/libec.so instead, a conflict in the underlying libflint causes this error. This could of course be fixed by omitting -L/usr/lib64 from LDFLAGS -- arguably, ax_boost_base() should try the empty path first and do nothing if it works -- but is that truly a mistake? Or is there some other obscure defect in eclib's build system that slibtool refuses to work around? I cannot find where "-lec" comes from in the first place, which probably means that it's coming from (s)libtool. Perhaps it would be happier if LIBS = $(top_builddir)/libsrc/libec.la ... was moved to LIBADD?
(In reply to Michael Orlitzky from comment #7) > > Perhaps it would be happier if > > LIBS = $(top_builddir)/libsrc/libec.la ... > > was moved to LIBADD? I'm seeing the exact same link command after this change, so probably not.
(In reply to Michael Orlitzky from comment #7) > arguably, ax_boost_base() should try the empty path first and do nothing if > it works Incredible. The way ac_boost_base.m4 checks for boost is that it runs ls <dir>/libboost_* in a bunch of random places, and adds -L<dir> the first time it works. And then ax_boost_asio.m4, ax_boost_system.m4, and ax_boost_thread.m4 all do something similar. I'm leaning towards either disabling USE=boost or marking this CANTFIX unless someone else has an idea.
(In reply to Michael Orlitzky from comment #9) > (In reply to Michael Orlitzky from comment #7) > > arguably, ax_boost_base() should try the empty path first and do nothing if > > it works > > Incredible. The way ac_boost_base.m4 checks for boost is that it runs > > ls <dir>/libboost_* > > in a bunch of random places, and adds -L<dir> the first time it works. And > then ax_boost_asio.m4, ax_boost_system.m4, and ax_boost_thread.m4 all do > something similar. I was going to explain that to you but you figured out yourself :) I'll have a bit of a think about whether to disable boost.
It's trying to link both libflint 13 and libflint 14
(In reply to Michael Orlitzky from comment #9) > (In reply to Michael Orlitzky from comment #7) > > arguably, ax_boost_base() should try the empty path first and do nothing if > > it works > > Incredible. The way ac_boost_base.m4 checks for boost is that it runs > > ls <dir>/libboost_* > > in a bunch of random places, and adds -L<dir> the first time it works. And > then ax_boost_asio.m4, ax_boost_system.m4, and ax_boost_thread.m4 all do > something similar. > > I'm leaning towards either disabling USE=boost or marking this CANTFIX > unless someone else has an idea. I had issues with this recently and ended up passing --with-boost-libdir to avoid hell: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-libs/libtorrent-rasterbar/libtorrent-rasterbar-1.2.14-r1.ebuild#n74.
(In reply to Sam James from comment #12) > > I had issues with this recently and ended up passing --with-boost-libdir to > avoid hell: > https://gitweb.gentoo.org/repo/gentoo.git/tree/net-libs/libtorrent-rasterbar/ > libtorrent-rasterbar-1.2.14-r1.ebuild#n74. I think this is a different problem, where it finds the wrong directory before it tries the right one. In our case it finds the right directory, but then it adds -L/usr/lib64 to LDFLAGS, accidentally changing its order in the search path from last to first.
The main consumer of eclib (sage) doesn't require boost to be enabled. So I am in favor of just dropping it.
I've re enabled rlibtool for the latest eclib version (20210625) and it builds fine
(In reply to Alessandro Barbieri from comment #15) > I've re enabled rlibtool for the latest eclib version (20210625) and it > builds fine It will only fail during specific upgrades. Flint isn't really the problem, but an old version of eclib linked to an old version of flint is involved. In your case, the existing installation of eclib was linked to libflint.so.13. During an upgrade of eclib, the lines like x86_64-pc-linux-gnu-g++ ... -L/usr/lib64 ... -L../libsrc/.libs -lec ... \ -o .libs/solve_conic are intended to link against the newly-built libec in libsrc/.libs; however, the fact that -L/usr/lib64 is added BEFORE -L../libsrc/.libs means that it's actually linking against /usr/lib64/libec. All of the new stuff is linked against libflint.so.14, but the /usr/lib64/libec being pulled in is linked against libflint.so.13. And those libraries are incompatible in a way that the linker notices. So there is a real problem here. I'll think about it for a day or two. I spent way too much time investigating it today and now have to catch up on my real work.
BTW the same line with GNU libtool is, /bin/sh ../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ ... \ -L/usr/lib64 -o solve_conic solve_conic.o ../libsrc/libec.la -lflint so it's leaving the name of the la file intact, rather than trying to rewrite it to, -L../libsrc/.libs -lec like rlibtool does. Certainly the boost macro could be better, but I'll have to dig into rlibtool's code to decide if it should share some of the blame, or if GNU libtool is being too generous.
This is pretty much completely debugged: https://dev.midipix.org/cross/slibtool/issue/47 It only happens in this case because the boost macro is doing something stupid, but the slibtool link command is subtly different from what was intended (and what GNU libtool does). I'm going to mark this as resolved UPSTREAM, whatever that means, because it's a larger problem that will have to be addressed upstream. It would also be nice if someone rewrote AX_BOOST* to use AC_SEARCH_LIBS, but that's a separate issue -- slibtool will pick up the wrong library whenever you have other -L<path> flags taking priority over the just-built library, not just when the boost macro puts them there.
