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
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
