Interesting survey on Snow Leopard package managers

[Toby Peterson]

On Mon, Sep 14, 2009 at 10:18, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
> On Mon, Sep 14, 2009 at 09:25:38AM -0700, Toby Peterson wrote:
>> On Mon, Sep 14, 2009 at 07:22, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
>> > On Mon, Sep 14, 2009 at 10:11:39AM -0400, Eric Tiffany wrote:
>> >> This Ars Techica thread has a survey about package managers on Snow Leopard,
>> >> and an accompanying thread regarding some of these 64bit issues.
>> >>
>> >> http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/494000521041/showpollresults/Y
>> >
>> >> _______________________________________________
>> >> macports-dev mailing list
>> >> macports-dev at lists.macosforge.org
>> >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>> >
>> >   As I said in a couple threads this weekend, the smartest thing for
>> > MacPorts to do is adopt the usage of the config.guess patch (that is being
>> > evaluated by the config.guess maintainers) which I used to fix the gcc44
>> > package here (tickets 20838 and 21341). Assuming you don't want to bother
>> > supporting i386 builds on Snow Leopard machines that are defaulting to
>> > x86_64 code, this is the most transparent solution. The only alternative
>> > is to resort to what fink does in their packaging, test the default
>> > architecture with sysctl and then manually pass the --build/--host/--target
>> > triplets to configure.
>> >   I told there are a number of other packages broken on Snow Leopard
>> > in MacPorts because of the same issue. Does anyone have a list? I'll try
>> > them locally with the config.guess patch and add or open tickets for that
>> > fix.
>>
>> 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
>
>   That is a pretty extreme statement. I would argue the exact opposite.
> It is very heavy handed to let configure deduce an entirely different
> architecture and then change that behind its back by passing -arch to
> CFLAGS. If you think I'm wrong, go ahead and try to fix gcc44 with
> your approach. Good luck. Unless you are absolutely certain of the
> results, you don't want to be decoupling the triplet used by
> configure from the code generation used. Sure you might get away
> for awhile in general, but it could be misbuilding packages in
> subtle ways that are difficult to detect. If you insist on passing
> -m64, you absolutely should be passing...
>
> --host=x86_64-apple-darwin10 --build=x86_64-apple-darwin10 --target=x86_64-apple-darwin10
>
> to configure. I would also consider passing -m64 on CC instead of CFLAGS
> in that case as well. Also I don't even understand this fixation on
> passing -march. Unless you have added compiler wrappers to change the
> default behavior of gcc-4.2 or are using the depreciated gcc-4.0
> compiler, the default code generation should always be x86_64 on
> EMT64-capable hardware. Passing -march does nothing for helping
> configure understand the correct architecture is it building on.
> Only explicitly passing the triplets or fixing config.guess does
> that.

Do what you want with gcc, I'm just not in favor of making a global
change to the way we run configure. Also note that passing identical
--host and --target values has no effect. Passing --build at least
makes some sense, but since we're not cross-compiling there's really
no reason to use the other flags.

- Toby