Adventures in 64-bit computing

[Anders F Björklund]

Emil Lundberg wrote:

> Still failing to get 64-bit MacPorts to work properly, I though I'd  
> relay my progress so far. The short story is some ports do not  
> compile properly as ppc64. Others do, but don't compile properly on  
> x86_64. I'm prepared, of course, to notify the individual  
> maintainers of these ports, but first I'd like your opinion on  
> whether my general strategy is sound.

Not sure, since you say you're on a 32-bit platform you are in  
essence trying to cross-compile everything which isn't supported  
(except for only partially, by using the +universal variant and  
building universal binaries)

Had you been on a native 64-bit platform, it would have been somewhat  
easier. Pretty much the same as when trying to building universal  
from an Intel machine with Rosetta (easier) versus building on a  
PowerPC machine (harder).

> Note: I've given up the "universal" strategy using MacPorts 1.7  
> (trunk) for the time being, as I can't even get '+universal' to  
> work on Leopard (see this post: http://lists.macosforge.org/ 
> pipermail/macports-dev/2008-March/004704.html). But maybe this is a  
> known issue?

"worksforme", but I'm back on Tiger after having downgraded from  
Leopard. There are known problems with universal (only works with  
configure, etc) but for the basic autotools-using ports it should  
indeed being limping along already.

You might want to open a bug report about it, and attach some  
details. Maybe some one else who is running Leopard on PowerPC is  
able to reproduce the issue, it seems to be working OK on Tiger (and  
the configure.universal_target variable is present)

> * Case 1: Installing ppc and ppc64 binaries in separate directories
> ...
> - The following ports (prerequisites) now produce ppc64 binaries  
> and libraries. Manual compilation of ppc64 binaries depending on  
> these libraries also work fine.
> 	expat, libiconv, gettext (w/ deps), popt
>
> - Trying to install 64-bit "R", I fail on some dependencies:
> 	"gmp" builds, but needs to be edited as follows:
> 		configure.env ABI=mode64
> 	"mpfr" builds.
> 	"gcc42" (for some reason a library and compiler dependency) I  
> cannot get it to to compile on 64-bit. Some stages produce ppc64  
> object files but some ignore the -m64 flag and build ppc object  
> files. Needless to say, the linker is not happy.

This approach sounds sound to me, but as you noticed some ports  
ignore CFLAGS altogether.

> * Case 2: Installing i386 and x86_64 "universal" binaries.
>
> Environment: OS X 10.5.2, MacPorts 1.6, CoreDuo MBP (32-bit  
> machine, I know!)
>
> - Installed MacPorts 1.6 from disk image into /opt/local, then  
> editing the following files:
> 	variants.conf:
> 		added +universal
> 	portconfigure.tcl
> 		set/added "-arch i386 -arch x86_64" in default variables:
> 			configure.universal_cflags, configure.universal_cxxflags,  
> configure.universal_ldflags

You should probably set "configure.universal_archs i386 x86_64"  
instead (this setting is new for 1.7/trunk).

> - Trying to install 64-bit "R", I fail on some dependencies:
> 	"gmp" builds, but needs to be edited as follows. This is  
> reasonable, as this port does not have a universal variant, plus  
> I'm on a 32-bit machine:
> 		configure.cflags-append -m64

You shouldn't set -m64 explicitly for a universal build, as it'll  
mess up the 32-bit platforms (i386 and ppc).

> 	"mpfr" fails in the configure stage: "configure: error: libgmp not  
> found or uses a different ABI". I suspect this is due to the  
> configure script trying to compile and run a 64-bit code snippet,  
> which of course will fail on the CoreDuo. I will try to get my  
> hands on a proper x86_64 machine and let you know how it turns out.
> 	"gcc42" depends on mpfr, so this has not been tested yet.

I downgraded from ppc64 to i386 (from the PPC G5 to the Core Duo), so  
I only have 32-bit available for testing.

> Any feedback is appreciated. A 64-bit clean MacPorts would (in my  
> view) be a significant improvement to an already great tool.

It's on the wish list, but there has been no real work in "base" for  
it yet (except for universal_archs and configure.m64).

For instance, there is no variants for 64-bit compilation and the  
generated packages/archives still think they're on a 32-bit platform  
(mostly because that is what `uname -m` tells them, but that's  
another story I suppose) Support for that (+m32 and +m64 perhaps?)  
would need to be added to base, before starting to adopt those  
Portfiles that needs extra configuration and hand-holding done.

Not sure if building Universal Binaries is "clean", but 64-bit  
support and non-admin installs are frequently requested....

--anders