On 3/30/12 5:09 PM, Chris Larson wrote:
On Fri, Mar 30, 2012 at 3:04 PM, Mark Hatle<[email protected]>  wrote:

We've worked on a similar problem in the past.  In specific cases we've
added a checksum of the host's glibc to the mix.  The problem we were
solving was in glibc uprevs during the RHEL 4 world.. new APIs would arrive
and things would break -- or workaround would break.

Have you considered adding that to the mix in an attempt to help determine
compatible host distributions?

It's been discussed in the past, but the problem is, as far as I know,
glibc isn't the only build host dependency we have. It's the most
visible, since glibc versioned symbols are the first place one
generally sees this sort of failure, but I think the safe bet is to
operate based upon the distro name/version, to avoid any potential
other compatibility issues with other host libraries that get linked
against. It'd be nice to ensure that glibc is the only dependency, at
which point that sort of approach would be more reliable, but I don't
think we're there yet (please correct me if I'm wrong here).

It would be nice if the host libc was the only dependency.  ;)

Have you run any type of scan on the host dependencies to see where we actually sit? I know a while back I ran a scan and was surprised at how few host dependencies there was in a fairly standard oe-core build.

--Mark

I do like the idea of directory based sstate cache.  It can more easily
identify what the components belong to.  (I wouldn't mind some type of
hierarchy for the target stuff as well, but so far I'm not sure exactly it
would look like or trigger off of.)

However, shy of directory based.. adjusting the generated checksum in some
way should be enough -- the downside is how do you detect compatible hosts
or not..  You may have to generate multiple checksums and look for best
matches, which I suspect is also new code.

What we had before this was just injection of the lsb_release
identifier/release into the native/cross signatures via vardeps, but
as you say, dealing with compatible hosts is non-trivial. I'm
certainly open to that sort of approach, but as you say, I think
there's other value to this approach, and seems a bit less confusing
:) Thanks for the comments, it's certainly a non-trivial problem to
solve.


_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Reply via email to