Interesting survey on Snow Leopard package managers
Toby Peterson
toby at macports.org
Mon Sep 14 12:55:28 PDT 2009
On Mon, Sep 14, 2009 at 11:58, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
> On Mon, Sep 14, 2009 at 11:30:41AM -0700, Toby Peterson wrote:
>> On Mon, Sep 14, 2009 at 11:19, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
>> > On Mon, Sep 14, 2009 at 09:25:38AM -0700, Toby Peterson wrote:
>> >>
>> >> Our current approach (passing -arch) seems to be working fine - I
>> >> think both of your suggestions are bit heavy-handed considering *most*
>> >> ports work just fine with -arch flags.
>> >>
>> >> - Toby
>> >
>> > Granted gcc is an extreme case but it is VERY unwise to
>> > assume that configure will never set anything that architecture
>> > dependent when the wrong triplet are passed. For example, if
>> > there is any hard coded assembly language routines in the code,
>> > the wrong assembly code will be selected by configure. Not passing the
>> > correct triplet to configure or correcting config.guess is
>> > simply bad technique.
>>
>> Indeed, and for the (very few) ports that require tweaking, we can
>> make the necessary changes. I've already committed dozens of fixes to
>> correct these types of issues.
>>
>> - Toby
>
> True perhaps, but simple logic dictates that it is bad form for
> configure to think it is compiling code for a 32-bit architecture
> and then gcc to start generating 64-bit code behind its back. Remember
> that Apple has done something no one has ever done before...create
> an operating system that runs a 32-bit kernel but 64-bit executables.
> I tried unsuccessfully during Snow Leopard's development to get a
> more accurate reporting of the default executables from either
> uname or arch. I have several radar bugs open on that issue. If you
> consider that the arch manpage says...
>
> The arch command with no arguments, displays the machine's architecture type.
>
> The other use of the arch command it to run a selected architecture of a universal binary. A universal binary
> contains code that can run on different architectures. By default, the operating system will select the archi-
> tecture that most closely matches the processor type. This means that an intel architecture is selected on
> intel processors and a powerpc architecture is selected on powerpc processors. A 64-bit architecuture is pre-
> ferred over a 32-bit architecture on a 64-bit processor, while only 32-bit architectures can run on a 32-bit
> processor.
>
> ...even on Leopard, it is obvious that arch without arguments should report
> the preferred architecture (which is the one run) that is x86_64 on EMT64
> compatible hardware. No one has ever decoupled the triplet detected from
> 'uname -p' or 'arch' from the actual architecture of binary being run. It
> is no wonder this causes build issues. Only if you are running the 64-bit
> kernel in Snow Leopard does the correct triplet get passed by the current
> config.guess. This is the purpose of the config.guess patch...to adapt to
> the fact that Apple refuses to properly report the actual default architecture
> through uname or arch.
It may be bad form, but I'd bet most ports would build just fine for
lol-apple-darwin, because they simply don't care. I'd rather patch the
few ports that do matter rather than making sweeping changes that are
sure to break ports that currently build correctly.
K64 makes no difference - config.guess uses uname -p, which is i386 on
K32 and K64. The fact is that arch/uname aren't the correct tools for
determing the answer to this particular question.
- Toby
More information about the macports-dev
mailing list