Re: [PATCH] uninative: Add allow-shlib-undefined to BUILD_LDFLAGS and drop other workarounds

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2018-04-17 at 12:15 -0700, Andre McCurdy wrote:
> On Tue, Apr 17, 2018 at 9:44 AM, Richard Purdie
> > We've looked into various options, basically we cannot link against
> > our uninative libc/ld.so since we don't have the right headers or
> > compiler link libraries. The compiler doesn't allow you to switch
> > in a new set either, even if we did want to ship them. Shipping a
> > complete compiler, dev headers and libs also isn't an option.
>
> 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?

There are a few ways you could solve this problem in theory. The
trouble is you need to build these native tools somehow and to link
against musl, you'd need a cross build more similar to "nativesdk" than
"native" as you can no longer use the host gcc.

We've looked at shoe-horning nativesdk into native before but it gets
very very messy very quickly as they're really not equivalent. We could
of course create some new native-like variant but again, messy very
quickly, particularly trying to get the sstate checksums to match.

You can give up on the native checksums matching or coerce them somehow
but again, very messy very quickly.

uninative works surprisingly well for how "simple" it is, it does have
some rough edges.

I have found one further issue with this patch and the need to tweak it
a little further, I'll send another patch shortly related to that once
we test it a bit more. That said, if these two changes do work, they
fix one of the big flaws in uninative and should make it a lot more
workable/usable.

Cheers,

Richard