From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Colin Walters <walters@verbum.org>
Cc: poky@yoctoproject.org
Subject: Re: [patch] autotools: Remove .la files by default
Date: Tue, 29 Mar 2011 23:18:49 +0100 [thread overview]
Message-ID: <1301437129.24596.80.camel@rex> (raw)
In-Reply-To: <AANLkTi=GPAEXD4CRPrhwGtd82ZfEx=HmW7_zWRxe+ev6@mail.gmail.com>
On Tue, 2011-03-29 at 13:04 -0400, Colin Walters wrote:
> On Tue, Mar 29, 2011 at 12:29 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > I can do better than that, we have some limitations in the way .conf
> > files are parsed compared to .bbclass files. If you create a
> > "localchanges.bbclass" containing:
>
> Of course I can code it locally, but I think this mechanism would be
> of value to other people creating systems, and hence my proposal to do
> it upstream.
For the reasons I've outlined I really don't want to encourage people to
be doing this so I'm reluctant to accept such a patch. Note that
removing them from the install directory removes them from the sysroots
too and may have undesired side effects on dlopened libraries for
example.
> > Right, but with our build environment, this really becomes a non-issue
>
> I agree it's a non-issue for building the OS. But it will be an issue
> for people who *after* having the OS installed, want to temporarily
> override system libraries with other versions. And there's just no
> sane way to fix it without just nuking the files from the OS.
My questions are: How many people actually use the system that way
rather than generating a new image? Is deleting the .la files really
that hard if you're doing development on the system?
I appreciate for you it is an issue but I'm not yet convinced this is a
widespread problem.
> > (and I've been trying to get patches upstream which stop -L/usr/lib
> > being injected anyway as that is a libtool bug).
>
> I think a better fix would actually be an automake option to stop it
> from even installing them, and I looked into this (it's not trivial,
> and effectively requires disabling "make uninstall"), and even if the
> fix landed every project would have to be updated for it.
The nice thing about OE is that it reautoconf's the sources so if you do
change libtool, we can cascade it to pretty much every package bar some
of the toolchain pieces automagically!
Cheers,
Richard
next prev parent reply other threads:[~2011-03-29 22:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-29 14:43 [patch] autotools: Remove .la files by default Colin Walters
2011-03-29 16:03 ` Richard Purdie
2011-03-29 16:15 ` Colin Walters
2011-03-29 16:29 ` Richard Purdie
2011-03-29 17:04 ` Colin Walters
2011-03-29 22:18 ` Richard Purdie [this message]
2011-03-29 16:35 ` Koen Kooi
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=1301437129.24596.80.camel@rex \
--to=richard.purdie@linuxfoundation.org \
--cc=poky@yoctoproject.org \
--cc=walters@verbum.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.