[Openembedded-architecture] Host tools available from PATH

[Richard Purdie]

On Thu, 2017-03-09 at 15:40 +0000, Phil Blundell wrote:
> On Thu, 2017-03-09 at 11:39 +0000, Richard Purdie wrote:
> > 
> > I'm sending this to ask whether people feel this is worth getting
> > right
> > for 2.3 and whether we should hold M3 and the feature freeze to get
> > something implemented? This would assume we then are prepared to
> > take
> > the pain of actually populating these lists (I've made a start for
> > OE-
> > Core at least).
> I think this is a fine idea in general.  I have only the very
> faintest
> idea of what "2.3" and "M3" are so I have no opinion about those. :-)
> 
> It does seem as though this will make ASSUME_PROVIDED rather less
> useful for host tools, or at least that any native thing added to
> ASSUME_PROVIDED would need to be added to the whitelist as well.

Right, you'd now have to tweak both. We can't have it all I guess...

> I'm not sure it's really safe to whitelist things that might be
> present on some hosts and not others, otherwise you haven't really
> eliminated the problem.  So it seems as though to have a truly robust
> solution, what we would need to do is distil the list down to a bare
> minimum of tools that the host environment must always provide (plus,
> as mentioned above, maybe anything in ASSUME_PROVIDED) and then the
> code would need to verify that all those tools really are present on
> any host.  If not then you still run the risk of nondeterministic
> builds if one host happens to have a tool that another doesn't.

The intent was only to list things that really do need to be provided.
You do raise a couple of good points below though.


> There are certainly some things in your list above that don't
> obviously look like they belong there.  Flex can be provided by flex-
> native, and if you want deterministic builds then you need to know
> what version you're getting (which would imply that you really do
> need to build it from a recipe rather than picking up some random
> version from the host).

flex and unlzma were mistakes. I've now removed those from the version
of the patch I just sent to OE-Core. I think I got confused by
something looking for them and assumed it was breaking the build when
it was in fact something else. In general I do believe the list is
correct though.

>   I don't think anything in oe has any business calling ld.bfd on
> the host directly at all: none of our native recipes ought to care
> about what linker is in use since, in theory at least, the host
> system might not use the GNU linker at all.

Nothing in OE does call it. Depending on the options you pass to gcc,
*it* might call ld.bfd or ld.gold instead of ld. I did see failures
where something really wanted bfd yet since ld.bfd wasn't in PATH,
things got upset.

I've ended up adding a HOSTTOOLS_NONFATAL section to handle these
things which if present, we need to access. Its not ideal but I'm
struggling to see a better way to handle this right now.

Hopefully the patch posted to OE-Core looks a lot better...

Cheers,

Richard