Finding the broken .la file
In case you wonder which .la pulls in /usr/lib/libglib-2.0.so, instead of /opt/gnome/lib/libglib-2.0.so, you can try this code snippet. The first pipeline retreives all .la files libtool reads, the second one scans that file for the unwanted .la file.
strace -f make 2>&1 | grep 'open(".*\.la".*) = [0-9]\+$' | cut -d\" -f2 | sort -u | tee /tmp/labber
fgrep /usr/lib/libglib-2.0 $(/tmp/labber)
Still would be nice if someone would fix libtool, to always use /opt/gnome/lib/libglib-2.0.so, instead of /usr/lib/libglib-2.0.so, when both are in the library path.
Comments
Post a Comment
This site's webmaster failed misserably in upgrading the underlaying web framework.
The comment system is entirely broken right now. Sorry!
Ah ! thanks . Another lesson learnt :)
you can fix very many problems by deleting /usr/lib/*.la (and all of the .la files in other locations). they are not needed and only cause you pain.
Cleary a problem with build enviroment, not libtool
Not really. There is absolutely no point in rebuilding the entire software stack, just for making libtool happy. If I'd like to do that, I would just use some insane stuff like Gentoo.
Most of my system libraries are sufficient for the trunk stuff I try to build, so libtool should acknowledge that. It's really libtool that's broken in its assumptions.