plans for 64bit support

[Daniel Oberhoff]

---------- Forwarded message ----------
From: Daniel Oberhoff <daniel at danieloberhoff.de>
Date: Dec 12, 2007 12:29 PM
Subject: Re: plans for 64bit support
To: Weissmann Markus <mww at macports.org>


[...]

>
> we put some research into this during GSOC this year: It's quite hard
> to come up with a magic lipo for everything as it is necessary to
> combine not only binaries (thats the easy part) but also stuff like
> header files (also easy), heap images of interpreters, scripting
> language programs, etc. -- which can get practically impossible.
>
> We could enable four-way builds for (probably) all ports that we can
> build universal right now, but there is currently no way of saying
> "no ppc64 please" (etc.) in a port (and no tests/experience on what
> exactly will be necessary).
>

Hmm, but that would mean I always have to build 4 times and waste lots of
space and time I will never ever need (i.e. on my intel mac I will never use
ppc binaries). Are ppc+interl universals so important? After all macports is
more of a local compile and use thing than about binary distribution, right?




>
> >> Alternatively maybe have two macports trees, one with 64bit, one
> >> with 32bit. Kinda like those lib64 dirs on some linux flavours. Is
> >> that possible right now?
> >
> > You're talking about two collections of port binaries, presumably?
> > Since we don't have any binaries at this point, or any 64-bit
> > builds, anything's possible, of course. Is it wise to have 64-bit-
> > only binaries? I wouldn't have thought so but I really have no idea.
> >
> > If you mean, is it possible to have 64-bit builds go into lib64
> > instead of lib, then I would say if that's not the default for the
> > software already, it would be a rather large hassle to fix every
> > portfile to do this, wouldn't you say? And why is this better than
> > a single all-encompassing superuniversal library installed in the
> > normal expected location?
> >
>
> you could always pass a "-arch x86_64" (or "-arch ppc64") to the
> cflags/cxxflags/.. manually if you desperately need 64 bit support,
> e.g.:
> $> port -d install readline configure.cflags="-O2 -arch x86_64"
> (no idea if that one compiles though)
>
> If you want to make some tests with four-way universal builds,
> replace each occurrence (there are 3) of "-arch i386 -arch ppc" in /
> opt/local/share/macports/Tcl/port1.0/portconfigure.tcl with "-arch
> i386 -arch x86_64 -arch ppc -arch ppc64".
> We are of course interested in your results... ;)
>

Hmm, no, this went down the wrong path. Let me clarify: Someone before said
that on Leopard macports would automatically build 64 bit binaries. Now I
was wondering if

a) I could prevent this (i.e. have it build 32bit as before)
b) If I could have two completely independent macports repos on my disk, one
built 32bit and one 64bit. This would be ideal since most everyday stuff is
32bit, and only some libs and stuiff are needed for 64. I would go as far as
saying this latter option would be the best solution (less hassle than doing
universal builds and better controllable),

for the 32/64 bit versions I would really like this supported in macports
properly, and not have to fiddle with build flags... I would like a
repo-constant switch for this. I.e. some repo (I refer to repo as a local
macports install tree, i.e. what is usually under /opt/local) would be set
up as 64bit and always be 64bit from there on (i.e. update, install and all
when on this repo do 64bit builds). And another would be 32bit. One could do
the same for ppc. I think real universal binaries are only ever needed for
distribution, and then one can always go and lipo things by hand.

So is this kind of repo-based architecture selection possible. And the
installation of multiple macports repos? If not I would even help make it
possible if someone gets me started :).



>
> For octave you're out of luck though as it is build with the vanilla
> gcc 4.2 which cannot produce universal binaries.
> Perhaps you can test the Apple gcc 4.2 beta preview for octave to
> achieve this (if you're on 10.5) -- though the Fortran part may be a
> problem here as octave seems to use it (the Apple compilers don't do
> Fortan while the vanilla ones cannot create universal binaries).


That's ok. I use the regular 4.0 now, building octave from cvs. Octave
building on osx is not very hard anymore, they seem to have a grip on it
now. I would just like macports to handle dependencies :).


Best

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-users/attachments/20071212/ca21135f/attachment-0001.html