From: Colin Walters <walters@verbum.org>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: RFC: magic libtool .la removal
Date: Tue, 18 Jun 2013 12:05:38 -0400 [thread overview]
Message-ID: <1371571538.3466.27.camel@localhost> (raw)
In-Reply-To: <1371570476.20823.121.camel@ted>
On Tue, 2013-06-18 at 16:47 +0100, Richard Purdie wrote:
> The thing which really worries me about this is that we'll start to
> deviate quite massively with how upstream expect us to use autotools.
I just consider upstream wrong, and so do others:
http://wiki.debian.org/ReleaseGoals/LAFileRemoval
http://fedoraproject.org/wiki/Packaging:Guidelines (search for .la)
http://blog.flameeyes.eu/2008/04/what-about-those-la-files (the one mostly sane Gentoo guy)
> As things stand, we have a number of sysroot fixes for the sysroot
> support in libtool which is basically broken out the box. I have tried
> discussing them with upstream and was ignored, mainly as we patch
> libtool and we're supposed to use it unpatched.
Yeah, I dunno...maybe someone needs to fork libtool.
> I worry that if we go this route, the builds will stop working without
> the .la file removal and that we'll lose any chance of being able to
> resolve our patchset with libtool upstream. We might as well throw away
> libtool at that point
Or that...
> and save the overhead. It also means we will have
> bigger problems working on something like darwin (which I've had work in
> the past).
I don't have any experience with Darwin myself.
> So I don't see the pressing need to set us off down a path on our own.
> Yes the .la files are annoying but they're not that much of a problem,
> are they?
Depends; I don't have a lot of first-hand experience with problems they
cause in the OE context. But .la files completely break jhbuild.
Certainly, one could call jhbuild a hack, and it is. But it's a tool
with absolutely essential properties for people contributing to GNOME.
Basically jhbuild allows one to e.g.:
$ jhbuild buildone gtk+
$ jhbuild run gedit
Now you have your system version of /usr/bin/gedit linked against the
latest gtk+ from git in /opt/gnome/lib/libgtk.so. This "two layer"
model is essential for allowing developers to test new code without
risking their /.
The root "feature" of .la files where it can say "if you link against
me, also link against these other libraries" that causes this is much
better implemented by pkg-config.
next prev parent reply other threads:[~2013-06-18 16:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-18 14:31 RFC: magic libtool .la removal Burton, Ross
2013-06-18 14:42 ` Phil Blundell
2013-06-18 14:56 ` Burton, Ross
2013-06-18 15:00 ` Colin Walters
2013-06-18 15:05 ` Burton, Ross
2013-06-18 15:47 ` Richard Purdie
2013-06-18 15:52 ` Burton, Ross
2013-06-18 15:54 ` Phil Blundell
2013-06-18 15:59 ` Burton, Ross
2013-06-18 16:05 ` Colin Walters [this message]
2013-06-18 16:39 ` Colin Walters
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1371571538.3466.27.camel@localhost \
--to=walters@verbum.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.