> > The base OSX packages/libs are Universal builds whereas MacPorts will > (correctly in my opinion) builds for your architecture only. If it then > tried to link the (eg.) Intel-only binaries against Universal libs then it > would fail miserably. >
I believe that this is not true as of SnowLeopard. That's also how they saved a lot of HD space. Basically, MacPorts will reinstall a lot of stuff you already have and most packages have a ton of dependencies that are usually already available on your system. Read more about http://github.com/mxcl/homebrew they explain things very well. - Matt On Sat, Dec 5, 2009 at 7:57 PM, Jason King <[email protected]> wrote: > > On Dec 5, 2009, at 7:10 PM, Greg Willits wrote: > > > With Snow Leopard, most of that Universal bulk goes away doesn't it? I > > suppose there could be 32/64 bit bulk, but the PPC baggage is gone. > > I hadn't thought about that. Checking some packages that I know how to > check easily, like Perl and vim, suggests that some are Intel only now and > some still have the PPC flags (no idea why). > > /usr/bin/perl -V flags show "-arch ppc" whereas /usr/bin/vim -V is Intel > only. > > This still sounds like it will be a bit hit-and-miss - especially > considering that linking against OSX Perl has definitely been one area where > I've seen problems - which is unfortunate. Let me add that all my > experience with linking problems has been on Leopard, by the time Snow > Leopard came around I was well and truly invested in MacPorts. > > > I mostly hear of the purpose being so that it's very easy to get rid > > of the whole thing -- find /opt and delete. That does make it a handy > > way to try things without dirtying the default OS locations, and I > > have done that. If I want to play with a package and don't want to > > pepper my base OS with it, I'll do a macports install, and then if it > > is worth keeping, I'll nuke /opt and install by building. > > Yeah, it's certainly safer for the, sometimes inexperienced, Mac user base. > > >> I'd like to add that if people are building binaries by hand then > >> they are either (a) building arch-specific binaries and therefore > >> running the risk of linking with Universal libs or (b) building > >> Universal binaries and suffering the performance and size penalties > >> involved there. > > > > I think every time I've done this, I've noticed arch-specific options, > > but haven't seen any fallout from that (though I can't say I've built > > dozens of things, or done it with non-very-main-stream stuff, so my > > experience may be that thin layer of simple cases). > > Right, so it will often not cause a problem - and I'm not sure why it works > or fails when it does, but I've seen these issues when building things like > new versions of mysql (against the OSX ruby or Perl), linking vim against > OSX Perl or Ruby would trip over too, and big packages like ImageMagick. > Basically lots of the good stuff that I'm always playing with :) > > FWIW, I've also seen it work reliably against certain packages. I built > Passenger without a problem against the OSX Apache. But then recently I > tried to build PHP and it failed to build against OSX Apache (again, on > Leopard), so I've switched over recently to using the MacPorts Apache. > > Anyway, thanks for your response. I'm keen now to re-test a bunch of > things on Snow Leopard. > > Cheers, > Jason > > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby > -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
