crosscompiling macports, how hard is it?

Jordan K. Hubbard jkh at brierdr.com
Tue Jan 2 14:41:13 PST 2007


On Jan 2, 2007, at 2:08 PM, Kevin Ballard wrote:

> If you're going to distribute software, you don't want to build it  
> with macports (because all the linker paths will be absolute and  
> pointing at /opt/local, which is not how you want to distribute  
> anything). Because of this, I don't think crosscompiling is an  
> issue, since when building just for yourself, you don't need the  
> other architecture.

I'm a little puzzled by this statement.  Unless you're willing to  
make all of your distributed applications and libraries into bundles,  
which is quite a bit of work that most folks aren't willing to go to  
anyway, you're going to have hard-coded linker paths pointing  
somewhere no matter what you do!   Since you also can't install  
directly into locations like /usr/bin and /usr/lib (well, you can,  
but a special hit squad of Mac OS X engineers will be dispatched to  
terminate you and your software with extreme prejudice if you do), / 
opt/local is as good a location as /sw, /usr/local or pretty much any  
other location you might come up with.

In fact, if the MacPorts project ever gets off its collective duff  
and starts distributing binary packages (in some, any, package  
format) like was originally intended at the start of all this, one  
can reasonably expect to see a lot of users whacking stuff into /opt/ 
local without really even being aware of it.

> As a note, I once downloaded a program which had just released a  
> new version that used openjade for HTML validation. It didn't work.  
> Why? Because the author had built openjade using MacPorts and  
> bundled it that way. It worked fine on his system, but on anybody  
> else's system it was looking for libraries in /opt/local/lib that  
> simply weren't there. Beware distribution of MacPorts-built binaries.

No offense, but you're barking up the wrong tree with that  
analysis.   The problem wasn't that the author had built openjade  
using MacPorts, the problem was that he didn't instruct you to  
install the dependent libraries as well or simply bundle them with  
his software too.  That's one of the reasons that the MacPorts  
community always gets so hung up on package management - they want to  
distribute packages, but they also want to ensure that any system  
which installs those packages also follows dependencies, deals with  
upgrades and otherwise handles all the messy details of making that  
software work exactly the way it did on the package author's system.

Someday, one hopes, MacPorts will finally reach parity with its  
FreeBSD/Gentoo/Red Hat cousins and offer such a collection, after  
which problems like the ones you're describing will go away and be  
replaced by an entirely new and different set of problems which, at  
least, will be interesting and relevant to a wider audience. :-)

- Jordan

> On Jan 2, 2007, at 10:52 AM, Pau Arumi wrote:
>
>> nowadays is very common that osx software is distributed as  
>> universal binaries, so i'm quite sure somebody have tried to  
>> crosscompile (intel+powerpc) some macports libraries.
>> i'd need to do that for a handful of libraries, so, before  
>> starting my experiments i'd like to hear some previous experiences.
>>
>> do you think its worth trying it? or is definitely better to use  
>> two (intel and powerpc) boxes to produce binaries and then combine  
>> them with lipo? [1]
>
> -- 
> Kevin Ballard
> http://kevin.sb.org
> eridius at macports.org
> http://www.tildesoft.com
>
>
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-users/attachments/20070102/fbe14c80/attachment.html


More information about the macports-users mailing list