Interesting survey on Snow Leopard package managers

[Jack Howarth]

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

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