From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Khem Raj <raj.khem@gmail.com>, Andre McCurdy <armccurdy@gmail.com>
Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] uninative: Add allow-shlib-undefined to BUILD_LDFLAGS and drop other workarounds
Date: Wed, 18 Apr 2018 12:38:41 +0100 [thread overview]
Message-ID: <1524051521.18865.55.camel@linuxfoundation.org> (raw)
In-Reply-To: <37a8252f-acb0-d506-e1ea-821f119ecd8c@gmail.com>
On Wed, 2018-04-18 at 00:49 -0700, Khem Raj wrote:
>
> On 4/17/18 12:15 PM, Andre McCurdy wrote:
> >
> > On Tue, Apr 17, 2018 at 9:44 AM, Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > Maybe not an option now, but in theory wouldn't a set of native
> > tools
> > statically linked with musl and downloadable from a public sstate
> > server solve all these kinds of issues?
>
> I think this is an interesting idea, you should open a bugzilla entry
> for it so it can be followed up.
Its a nice idea and I can see the attraction but I can't see how you'd
make it work in practise.
> I am of the opinion that we should explore containers and abstract
> all this distro variability once for all.
I'd like to see this one explored. The trouble is the root privs
problem for containers, I don't know if that is still an issue?
The other thing I think we should explore urgently is an sstate
artefact equivalence mapping server.
That might get us huge amounts of sstate reuse, particularly given our
reproducibility improvements and mean that the bootstrap times become
less of a factor.
That along with a public central sstate mirror for the core of the
system might make a really interesting step forward for the project.
If I had to spend time on anything, I think this would be the next big
win for the project.
Cheers,
Richard
next prev parent reply other threads:[~2018-04-18 11:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-17 16:44 [PATCH] uninative: Add allow-shlib-undefined to BUILD_LDFLAGS and drop other workarounds Richard Purdie
2018-04-17 19:15 ` Andre McCurdy
2018-04-18 7:49 ` Khem Raj
2018-04-18 11:38 ` Richard Purdie [this message]
2018-04-18 11:34 ` Richard Purdie
2018-04-17 20:52 ` Burton, Ross
2018-04-17 20:57 ` Burton, Ross
2018-04-18 17:58 ` Richard Purdie
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=1524051521.18865.55.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=armccurdy@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/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.