On Mon, Sep 14, 2009 at 10:18, Jack Howarth <[email protected]> wrote: > On Mon, Sep 14, 2009 at 09:25:38AM -0700, Toby Peterson wrote: >> On Mon, Sep 14, 2009 at 07:22, Jack Howarth <[email protected]> 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 >> >> [email protected] >> >> 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 _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
