On 28/10/2017 11:10, DJ Lucas wrote:
On 10/28/2017 03:24 AM, Pierre Labastie wrote:
Hi,
When building network-manager-applet, I got:
---------
[...]
CCLD src/libnm-gtk/libnm-gtk.la
/bin/grep: /usr/lib/libatk-1.0.la: No such file or directory
/bin/sed: can't read /usr/lib/libatk-1.0.la: No such file or directory
libtool: error: '/usr/lib/libatk-1.0.la' is not a valid libtool
archive
---------
The reason id that libatk-1.0.la has not been installed when building
the atk package, because the build system is meson, but
network-manager-applet still uses autotools!
No something else is going on. This is most likely a symptom of
removing the previous version of atk(?). What was the exact scenario?
You should only see this on update if a dependent package had
previously used the .la file (something that was not rebuilt that
links to atk that nm-applet also links to maybe?). This is the reason
that distributions remove .la files at installation.
I should have known that, but I didn't, sorry. I'll follow Armin's
advice to check .la files referencing atk. It seems it is time to
rebuild anyway...
Of course, I can copy an old .la file coming from previous builds with
autotools, but what this error shows is that mixing meson and autotools
will be troublesome. OTOH, a lot of packages are not meson-able yet, so
autotools has still to be used. Conclusion: refrain using meson for the
time being.
Assuming my guess above is correct, copying the old .la file is
probably easiest. You cannot remove the .la file after something else
autotools uses it (because its la files point to that one creating an
endless dependency chain), so it needs to be done at build time.
I've nudged this issue a few times in the past, but interest has been
limited, likely because I tend to be long winded when explaining
something complex. The correct (but unrealistic) solution is to leave
the .la file out and then to rebuild everything that links to atk
(which is a lot!). If you want a full explanation, see
Ultimately, the only libtool archive that should exist is libltdl.la,
and some plugins for gstreamer and ImageMagick, but those won't be in
/usr/lib. There may be a handful of others, but they also should not
be in /usr/lib. I'm not suggesting that you remove them
now...everything will break! This really does need to be done
immediately after installing a package.
I guess I'll add some jhalfs magic to do that (unless somebody wants to
include .la removing in the book...
[interoperability dream]
Maybe meson could generate .la files... Or libtool could use pkgconfig
files...
Dream: libtool bowed out gracefully in the 90s when it should have. :-)
Reality: 23(?) years later we still have to deal with libtool because
of autotools...hence the push for cmake, gn, meson, scons, waf, etc.
Thus far, I think meson is the most user friendly to those already
familiar with autotools, which makes it most viable, but this is only
my opinion.
When autotools first appeared (at the beginning of the nineties), it did
not work with the machine I was using at the time (HP and IBM
workstations). I had to edit the config.h files anyway... I've never
been convinced by this tool, but so many packages use it that I had to
use it too eventually. I did not go into deep knowledge as you may have
noticed ;-).
But it's a pity that so many replacement systems are coming up. I like
meson too.
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
