On Fri, Mar 30, 2012 at 3:17 PM, Mark Hatle <[email protected]> wrote: > 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.
I haven't -- that's a very good idea though. In fact, I hate to admit it, but I've never even run swabber before :) It's on the 'when I find the time' list.. -- Christopher Larson _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
