Mailing List Archive

Maybe you can use the MACOSX_DEPLOYMENT_TARGET variable, which is set in
profile.bashrc for both 10.3 and 10.4 to their respective values.

Care to let us into the problem somehow?


Nick Dimiduk wrote:
> Do we have a standard way of determining the system version (10.{3,4})?
> Something like a USE variable or the like? I am in need of a way to
> handle the two versions differently in an ebuild.
>
> Thanks,
> -Nick Dimiduk

--
Fabian Groffen
Gentoo for Mac OS X
--
gentoo-osx@gentoo.org mailing list

Grobian wrote:
> Care to let us into the problem somehow?

Specifically, dev-libs/libsigsegv-2.2 builds on 10.3 and does not on
10.4. A look at the PORTING file included with the source shows it has
not been tested on anything newer than Darwin 8.0.

This is an ebuild marked unstable, but keyworded and works on Panther
installs but not Tiger. It should not be keyworded for Tiger until the
problem is resolved.
--
gentoo-osx@gentoo.org mailing list

On Sep 1, 2005, at 18:09, Nick Dimiduk wrote:

> Grobian wrote:
>
>> Care to let us into the problem somehow?
>>
>
> Specifically, dev-libs/libsigsegv-2.2 builds on 10.3 and does not
> on 10.4. A look at the PORTING file included with the source shows
> it has not been tested on anything newer than Darwin 8.0.
>
> This is an ebuild marked unstable, but keyworded and works on
> Panther installs but not Tiger. It should not be keyworded for
> Tiger until the problem is resolved.

${PORTDIR}/profiles/default-darwin/macos/10.3/package.mask is your
friend (it sucks, but currently that's all we have).

--

Hasan Khalil
eBuild and Porting Co-Lead
Gentoo for Mac OS X

That ebuild is wrong. For ppc-macos is calls ./configure instead of
econf, and I know why, because configure appears to hang in a loop if
you use econf. After I 'fixed' this problem make ran without problems
on Tiger for me.

I checked in my simplification/correction of the ebuild plus the patch
that simply removes Darwin5 support from configure, because it hangs on
Darwin8. I think it hangs on Darwin7 too, but since there is a separate
check for Darwin7 this is never tested. Darwin8 has POSIX compliance at
this point.

Let me know if it yields in any problems for you, Nick.



Hasan Khalil wrote:
>
> On Sep 1, 2005, at 18:09, Nick Dimiduk wrote:
>
>> Grobian wrote:
>>
>>> Care to let us into the problem somehow?
>>>
>>
>> Specifically, dev-libs/libsigsegv-2.2 builds on 10.3 and does not on
>> 10.4. A look at the PORTING file included with the source shows it
>> has not been tested on anything newer than Darwin 8.0.
>>
>> This is an ebuild marked unstable, but keyworded and works on Panther
>> installs but not Tiger. It should not be keyworded for Tiger until
>> the problem is resolved.
>
> ${PORTDIR}/profiles/default-darwin/macos/10.3/package.mask is your
> friend (it sucks, but currently that's all we have).
>
> --
>
> Hasan Khalil
> eBuild and Porting Co-Lead
> Gentoo for Mac OS X
>

--
Fabian Groffen
Gentoo for Mac OS X
--
gentoo-osx@gentoo.org mailing list

Grobian wrote:
> That ebuild is wrong. For ppc-macos is calls ./configure instead of
> econf, and I know why, because configure appears to hang in a loop if
> you use econf. After I 'fixed' this problem make ran without problems
> on Tiger for me.

Funny. I circumvented econf because it wouldn't build on Panther.
./configure worked just fine.

I don't have a Panther machine to test this on, though I will give it
some time this afternoon.

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.

Food for thought.

Thanks, Grobian, btw.

-Nick
--
gentoo-osx@gentoo.org mailing list

Nick Dimiduk wrote:
> Funny. I circumvented econf because it wouldn't build on Panther.
> ./configure worked just fine.

yeah, but using ./configure you don't set all the paths and
environmental stuff portage does. Especially the --prefix option is
vital amongst others.

> I don't have a Panther machine to test this on, though I will give it
> some time this afternoon.

I did a preliminary test on Panther to see if the configure would work,
and that worked fine.

> 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.

--
Fabian Groffen
Gentoo for Mac OS X
--
gentoo-osx@gentoo.org mailing list

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?

-f
--
gentoo-osx@gentoo.org mailing list

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 did.
To me, this package just works on both Panther and Tiger, but it could
have been that it wouldn't on one of them.

--
Fabian Groffen
Gentoo for Mac OS X
--
gentoo-osx@gentoo.org mailing list

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
> did.

OK. Thanks.

> 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 ;-)

-f
--
gentoo-osx@gentoo.org mailing list

Finn Thain wrote:
>> 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?

Yes, Hasan's solution is what I would have chosen if it wouldn't build.

> 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.

Yeah, and I think we shouldn't even try to support that. Though I hope
that if the major version of the kernel is equal that the userland keeps
on spinning.

> Which makes me think that the ppc-macos/10.3 profile should actually
> inherit from a ppc-darwin/8 profile (in my fantasy ;-)

Why ppc-darwin/8 and not ppc-darwin/7?

--
Fabian Groffen
Gentoo for Mac OS X
--
gentoo-osx@gentoo.org mailing list

On Fri, 2 Sep 2005, Grobian wrote:

>
> > Which makes me think that the ppc-macos/10.3 profile should actually inherit
> > from a ppc-darwin/8 profile (in my fantasy ;-)
>
> Why ppc-darwin/8 and not ppc-darwin/7?
>

Because it is 1:51 am... :-)

-f
--
gentoo-osx@gentoo.org mailing list

Finn Thain wrote:
> I'm curious, is this really a binary compatibility issue, or just a
> portability problem in libsigsegv?

At risk of sounding rather alarmist, I assert the *potential* for binary
compatibility issues. Panther's developer tools are not compatible with
Tiger (and vice versa) because Apple changes things with each release.
API changes, different gcc version, etc.

This example is a portability issue for libsigsegv. I'm no expert in
imake, but as I understand it, the configure script isn't picky enough
about darwin version and in this case there is an incompatibility
between versions (as we saw between darwin5 and darwin7 in the 2.1 release).

Just because we know something builds on Tiger does not mean it builds
on Panther. We know that. Which is why I think we need a better way to
further clarify compatibility of ebuilds (better than package.mask). I
don't want to keyword something on my Tiger system and have it break
someone's Panther system. We claim support for Panther. Have we ever
officially supported Tiger? Did we ever decide to focus on one release
over the other? Do we test both systems before a keyword?

I'd also like to point out that just because a package builds doesn't
mean it works. Was it tested? Did it come with testing facilities? Do
the tests pass on both Tiger and Panther?

Do we have a QA person? I've been away for a while, but I thought we
had solutions to many of these problems before I went AWOL.
--
gentoo-osx@gentoo.org mailing list

Nick Dimiduk wrote:
> Just because we know something builds on Tiger does not mean it builds
> on Panther. We know that. Which is why I think we need a better way to
> further clarify compatibility of ebuilds (better than package.mask). I
> don't want to keyword something on my Tiger system and have it break
> someone's Panther system.

Good point. I have a Panther machine, but I must admit that I do not
test everything on that machine. In that sense it would be nice if
there were ppc-macos-10.3 and ppc-macos-10.4 keywords, as well as
ppc-macos-progressive.

> We claim support for Panther. Have we ever
> officially supported Tiger? Did we ever decide to focus on one release
> over the other? Do we test both systems before a keyword?

All valid points to me! (to which I don't have concrete answers)

My opinion would be that we cannot claim to have something if there is
noone that maintains it. I think this would effectively mean that 10.3
would be unsupported, or I would have to let my Panther box working very
hard, but then I need my auto-testing idea to work, because I don't want
to do it manual.

> I'd also like to point out that just because a package builds doesn't
> mean it works. Was it tested? Did it come with testing facilities? Do
> the tests pass on both Tiger and Panther?

Normally, something first need to be tested. In this case I haven't.
Maybe I'd better just give you the patches and let you deal with the bug
instead of committing it. My bad, I was in doubt here, and reasoned
that I didn't change anything to the code effectively.

> Do we have a QA person? I've been away for a while, but I thought we
> had solutions to many of these problems before I went AWOL.

As you might have noticed, I'm some sort of new. I just reacted to your
mail to the best of my knowledge, which isn't that much in the end.
I'm interested in the answers to your questions also.

At the moment I don't feel very comfortable and safe in doing what I do.
This is mainly because of the many risks there are as you descibed
here, I think.


--
Fabian Groffen
Gentoo for Mac OS X
--
gentoo-osx@gentoo.org mailing list

Grobian wrote:
> Good point. I have a Panther machine, but I must admit that I do not
> test everything on that machine. In that sense it would be nice if
> there were ppc-macos-10.3 and ppc-macos-10.4 keywords, as well as
> ppc-macos-progressive.

I think the cascaded profiles work well for standard vs. progressive
installs. It would be quite the fight to get a new keyword for this
sort of thing... I'd like to think there's a better solution than a
keyword.

> My opinion would be that we cannot claim to have something if there is
> noone that maintains it. I think this would effectively mean that 10.3
> would be unsupported, or I would have to let my Panther box working very
> hard, but then I need my auto-testing idea to work, because I don't want
> to do it manual.

Maybe we need to start the process of acquiring a suite of test
machines? Dual-booting may also be an option for some of us.

> Normally, something first need to be tested. In this case I haven't.
> Maybe I'd better just give you the patches and let you deal with the bug
> instead of committing it. My bad, I was in doubt here, and reasoned
> that I didn't change anything to the code effectively.

No worries. I'm very much still learning as well. As far as I know,
the only package which uses this particular library is dev-lisp/clisp
and I'm the only user who cares about the package. If you broke
something, you'll have me to answer to! :p

> As you might have noticed, I'm some sort of new.
...
> At the moment I don't feel very comfortable and safe in doing what I do.
> This is mainly because of the many risks there are as you descibed
> here, I think.

This is a community supported project kept afloat by the spare time of
people like yourself, j4rgon, and kito. The bottom line is no one has
taken the time to work out a solution to these kinds of problems (and
maybe there is no good solution) so new people rightly feel lost. I
still feel quite lost myself. I like to ask (good) questions in the
hopes that they will encourage fruitful discussion. I don't have any
answers but I'd be honored to work with other devs and the community to
come up with good solutions.
--
gentoo-osx@gentoo.org mailing list

On Fri, 2 Sep 2005, Nick Dimiduk wrote:

> Grobian wrote:
> > Good point. I have a Panther machine, but I must admit that I do not
> > test everything on that machine. In that sense it would be nice if
> > there were ppc-macos-10.3 and ppc-macos-10.4 keywords, as well as
> > ppc-macos-progressive.
>
> I think the cascaded profiles work well for standard vs. progressive
> installs. It would be quite the fight to get a new keyword for this sort
> of thing... I'd like to think there's a better solution than a keyword.

I agree, and I'll reiterate my proposal, so that someone can finally shoot
it down and I can shut up.

I think the progressive profile should be replaced with an upstream darwin
profile. A macos profile should inherit that and add a prefix.

I don't think a macos keyword is actually needed. If you have a
ppc-darwin8 keyword, the ppc-macos-10.4 profile could just inherit that
and add a macos USE flag (for those ebuilds that work differently under
macos than darwin).

For that to work, you just need more dependency information in the ebuild
(i.e. if you depend on CoreAudio, or some other part of macos not in
darwin, it should be listed as a dep). As for how CoreAudio gets into the
tree, you can keep using package.provided (one version in the profile for
ppc-macos-10.4 and another in the profile for ppc-macos-10.3) until there
is a way to detect vendor packages automatically.

Most of this requires the portage rewrite. No idea what you should do
until then.

-f
--
gentoo-osx@gentoo.org mailing list