search

evaleev / libint

Libint: high-performance library for computing Gaussian integrals in quantum mechanics
Other
226 stars 95 forks source link

libtool hardcodes paths into .la files #114

Closed matt-chan closed 5 years ago

matt-chan commented 5 years ago

Libtool was introduced into libint tests recently (2.3.0?) and it causes issues when packaging for package managers. I understand that it's useful for distributing the compiled versions of libint on github, but it's actually pretty hard to work around when packaging libraries in a distribution. (libtool is notorious for ignoring options passed to it by the user and doing whatever it feels like. See this poor Gentoo developer's saga https://flameeyes.blog/tag/lafiles/ )

When building for a distribution, it's quite common to compile in some prefix (on the host or build system) and later move it over to another prefix (on the target machine), but libtool hardcodes the library paths into it. This can be good on some old systems without modern dynamic lib linkers, but I think most people using libint should be on OSX or some Linux flavour?

So for example, when packaging for Conda, I get warnings like this:

libtool: warning: library '<host_prefix>/lib/libstdc++.la' was moved.

Libtool then subsequently grabs whatever copy of libstdc++.la it can find, which is usually the wrong one (ie the path on the host that built the compiler!).

I'm actually not sure why the regular non-test builds work even though they're also using libtool, but it doesn't seem like a sustainable practice in the long-run.

Is there a way to disable Libtool builds from ./configure and just build a standard .o/.so? It looks pretty baked into the autotool scripts...

matt-chan commented 5 years ago

Also, here's an example of the libtool policy from Fedora's packaging guidelines: https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries

Essentially, it says they must be removed before packing the rpm. This isn't really a problem for libint in Fedora (I delete the .la files in the cleanup section of the Fedora package), but other package managers do the relocation before testing which causes problems.

matt-chan commented 5 years ago

I should add that the workaround for this is to run make check before running make install. This has the downside that you won't be aware of whether it works on the target system or if there are some hidden libtool timebombs waiting for your users...

evaleev commented 5 years ago

thanks for reporting this, I'll have a look. This might be the final reason to switch to cmake.

evaleev commented 5 years ago

as of 2.6.0-beta.3 exported libs are buildable with cmake and the autotools builds of the exported lib will be deprecated. these changes should resolve this issue