On Fri, 2 Sep 2005, Grobian wrote:
> Finn Thain wrote:
> > On Fri, 2 Sep 2005, Grobian wrote:
> > > > I would like to point out that we have the potential for all the
> > > > same kinds of issues as a merged x86/amd46 team would have,
> > > > regarding binary incompatibility and keywording. Not the the
> > > > extent of that team, but difficulties none the less.
> > > I agree, but this problem should to a certain extend be solved by
> > > using portage provided versions of programs yet supplied by the OS.
> > > I personally think that for now we can get away with primarily
> > > looking at OSX Tiger.
> > I'm curious, is this really a binary compatibility issue, or just a
> > portability problem in libsigsegv?
> I hadn't read it like that. I understood it more like a general point
> being made. libsigsegv seems to be known with Darwin7, not with 8.
> The model in Darwin8 is different, and supports POSIX sigsegv stuff
> where Darwin7 needs some Darwin7 specific code, apparently like Darwin5
> To me, this package just works on both Panther and Tiger, but it could
> have been that it wouldn't on one of them.
If "wouldn't work" means "wouldn't build", isn't it a package.mask
problem, as Hasan said? So, I guess the general point being made is about
what happens when a package built in darwin 8 doesn't run in 9 (which is
similar to what happens in a 64-bit system without 32-bit libraries, as
Nick alluded to).
Generally speaking I wouldn't be suprised to need emerge --emptytree world
if I wanted to take my gentoo installation to a darwin 9 system. I don't
think that using more portage provided builds is going to change that.
Indeed, if portage provides the entire userland, it can't be expected to
work at all under a new kernel.
Which makes me think that the ppc-macos/10.3 profile should actually
inherit from a ppc-darwin/8 profile (in my fantasy ;-)
email@example.com mailing list