Re: gcc and universal binaries
After building the universal gcc48 and compiling for the i386 target, I was
disappointed to see that the library didn't work on an older MacBook I had
lying around :-(
I think I'll abandon support for anything other than 64 bit OS X.
--
Sam
On 25 Aug 2013, at 18:22, Sam Halliday sam.halli...@gmail.com wrote:
Ok, thanks.
In that case I'll abandon the idea of supporting PPC. It sounds like there
would be too much tweaking of mac ports above and beyond the SO instructions
for obtaining a PPC SDK.
Btw, I don't really care about LIPO. I would be happy with four binaries of
my project.
Kind regards,
Sam Halliday
--
Sent from my iPhone
On 25 Aug 2013, at 16:33, Jeremy Huddleston Sequoia jerem...@macports.org
wrote:
On Aug 25, 2013, at 4:21, Samuel Halliday sam.halli...@gmail.com wrote:
Thanks all,
In order to build a ppc gfortran app, I need the Xcode 3 PPC compiler (I
think that's what a lot of these comments have been about). There is a SO
thread about how to do this:
http://stackoverflow.com/questions/5333490
But once I have my universal gcc48 (not apple-gcc*), it would appear that
the -arch flags must be passed one at a time. BTW, it seems the default
gcc48 can build 32 bit fortran apps (even though it's a x86_64 build) but
can't link them (hence the need for gcc48 +universal).
Before I embark on the insane mission of obtaining xcode3 ppc compilers,
can somebody confirm for me if the gcc48 +universal (with universal
including ppc) will be able to compile ppc binaries using -arch ppc?
No, it won't. +universal in the gcc ports means i386/x86_64 or ppc/ppc64:
platform powerpc {
configure.universal_archs ppc ppc64
}
platform i386 {
configure.universal_archs i386 x86_64
}
If you want to fix that, you'll need to bring the Apple gcc driver driver
into the gccXX ports and update those ports to build once for ppc and then
again for i386 ... see the apple-gcc42 port for how this is done as well as
the driver driver source code.
* one could edit
https://trac.macports.org/browser/trunk/dports/lang/apple-gcc42/Portfile to
include the fortran language, but I'd rather not get into customising
portfiles. Besides, I thought apple used LLVM nowadays.
You're not going to solve this without either:
1) Moving to Snow Leopard or earlier (so you can have a MacPorts ppc
runtime, so you can have a gfortran compiler that produces ppc code)
2) Making a darwin-ppc cross compiler (again, not in MacPorts, but our
assembler (cctools) and linker (ld64) should work for you)
3) Adding fortran support to apple-gcc42 (and using the 10.5 or 10.4u SDK)
4) Adding support for generating ppc code with the gccXX ports when running
on intel
You're going to need to change around Portfiles or do a lot by hand to solve
this problem.
Alternatively, you could have a SL or Leopard machine do the ppc bits and a
ML machine do the i386/x86_64 bits. Then just lipo them all together into
the final executable. This is essentially how I build the host support
library that is shipped with quartz-wm.
--Jeremy
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc and universal binaries
Thanks all, In order to build a ppc gfortran app, I need the Xcode 3 PPC compiler (I think that's what a lot of these comments have been about). There is a SO thread about how to do this: http://stackoverflow.com/questions/5333490 But once I have my universal gcc48 (not apple-gcc*), it would appear that the -arch flags must be passed one at a time. BTW, it seems the default gcc48 can build 32 bit fortran apps (even though it's a x86_64 build) but can't link them (hence the need for gcc48 +universal). Before I embark on the insane mission of obtaining xcode3 ppc compilers, can somebody confirm for me if the gcc48 +universal (with universal including ppc) will be able to compile ppc binaries using -arch ppc? * one could edit https://trac.macports.org/browser/trunk/dports/lang/apple-gcc42/Portfile to include the fortran language, but I'd rather not get into customising portfiles. Besides, I thought apple used LLVM nowadays. -- Sam On 25 Aug 2013, at 03:17, Jeremy Huddleston Sequoia jerem...@macports.org wrote: On Aug 24, 2013, at 8:00, Ryan Schmidt ryandes...@macports.org wrote: On Aug 24, 2013, at 07:29, Samuel Halliday wrote: I'm using the macports distro of gcc in order to get fortran support. Could somebody please show me how to build universal binaries that work on the four targets: PPC/Intel 32/64? I presume I'll need to get this fixed: $ file /opt/local/lib/libgcc/libgfortran.3.dylib /opt/local/lib/libgcc/libgfortran.3.dylib: Mach-O 64-bit x86_64 dynamically linked shared library Edit /opt/local/etc/macports/macports.conf and set universal_archs to x86_64 i386 ppc64 ppc. Then reinstall libgcc with the universal variant. And maybe the gcc port you're using too. If you already had any ports installed using the universal variant they'll have to be rebuilt using the new set of architectures. Not sure if MacPorts will do that for you automatically or not. I would expect that modern versions of OS X cannot build for PowerPC anymore, so you'll need to be running as sufficiently old version of OS X. Lion and later are too new. Snow Leopard is probably old enough. Leopard is definitely old enough. Tiger is too old to build 64-bit in some cases. If you're on SL, you'll need to use the 10.5 SDK if you actually want ppc64 support. You probably don't want or need ppc64 support (and ppc64 is likely horrifically broken in MacPorts), so I suggest using Snow Leopard with universal_archs to x86_64 i386 ppc. On Aug 24, 2013, at 15:07, Samuel Halliday sam.halli...@gmail.com wrote: On 24 Aug 2013, at 16:24, Ryan Schmidt wrote: what command line arguments do I use to get universal builds in my own projects? add all the -arch flags (e.g. -arch x86_64 -arch i386 -arch ppc64 -arch ppc) I'm guessing these instructions are for the apple gcc? Because doing this with the gcc / gfortran that I've been installing with macports gives gcc-mp-4.8: error: unrecognized command line option '-arch' Did you build it with the +universal variant? Also, I think FSF just aliases -arch to -mXXX. It does not seem to support multiple -arch options right: ~ $ gcc-mp-4.8 -arch x86_64 -c test.c ~ $ file test.o test.o: Mach-O 64-bit x86_64 object ~ $ gcc-mp-4.8 -arch x86_64 -arch i386 -c test.c ~ $ file test.o test.o: Mach-O i386 object ~ $ gcc-mp-4.8 -arch i386 -arch x86_64 -c test.c /var/folders/1b/f1bzh5152y9bvygzl07fn87mgn/T//cc7eJXt5.s:5:bad register name `%rbp' /var/folders/1b/f1bzh5152y9bvygzl07fn87mgn/T//cc7eJXt5.s:7:bad register name `%rsp' /var/folders/1b/f1bzh5152y9bvygzl07fn87mgn/T//cc7eJXt5.s:10:bad register name `%rbp' and trying to compile C code on Mountain Lion with the apple gcc gives llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory Yeah. You need to be on Snow Leopard if you want to compile for ppc. So I'm concluding it is impossible to build universal fortran apps since the apple gcc doesn't come with gfortran. That depends on what you mean by universal. It's possible to build i386/x86_64 using gfortran plus lipo (look at the libgcc subport of gcc48 for example) My only hope would be to build separate binaries for each architecture by: 1. access to old OS X machines (+ macports) 2. cross compile I don't have access to old machines (and it would be incredibly inconvenient in any case), and I'm guessing macports doesn't supply cross compilers for older OS X architectures. You just need the SDK. It's theoretically possible for you to use the 10.5 SDK on a modern system, but you'll need to build a ppc compiler. There's a chance that the apple-gcc42 port may work for you, but it will likely require a bit
Re: gcc and universal binaries
On Aug 25, 2013, at 4:21, Samuel Halliday sam.halli...@gmail.com wrote:
Thanks all,
In order to build a ppc gfortran app, I need the Xcode 3 PPC compiler (I
think that's what a lot of these comments have been about). There is a SO
thread about how to do this:
http://stackoverflow.com/questions/5333490
But once I have my universal gcc48 (not apple-gcc*), it would appear that the
-arch flags must be passed one at a time. BTW, it seems the default gcc48 can
build 32 bit fortran apps (even though it's a x86_64 build) but can't link
them (hence the need for gcc48 +universal).
Before I embark on the insane mission of obtaining xcode3 ppc compilers, can
somebody confirm for me if the gcc48 +universal (with universal including
ppc) will be able to compile ppc binaries using -arch ppc?
No, it won't. +universal in the gcc ports means i386/x86_64 or ppc/ppc64:
platform powerpc {
configure.universal_archs ppc ppc64
}
platform i386 {
configure.universal_archs i386 x86_64
}
If you want to fix that, you'll need to bring the Apple gcc driver driver into
the gccXX ports and update those ports to build once for ppc and then again for
i386 ... see the apple-gcc42 port for how this is done as well as the driver
driver source code.
* one could edit
https://trac.macports.org/browser/trunk/dports/lang/apple-gcc42/Portfile to
include the fortran language, but I'd rather not get into customising
portfiles. Besides, I thought apple used LLVM nowadays.
You're not going to solve this without either:
1) Moving to Snow Leopard or earlier (so you can have a MacPorts ppc runtime,
so you can have a gfortran compiler that produces ppc code)
2) Making a darwin-ppc cross compiler (again, not in MacPorts, but our
assembler (cctools) and linker (ld64) should work for you)
3) Adding fortran support to apple-gcc42 (and using the 10.5 or 10.4u SDK)
4) Adding support for generating ppc code with the gccXX ports when running
on intel
You're going to need to change around Portfiles or do a lot by hand to solve
this problem.
Alternatively, you could have a SL or Leopard machine do the ppc bits and a ML
machine do the i386/x86_64 bits. Then just lipo them all together into the
final executable. This is essentially how I build the host support library
that is shipped with quartz-wm.
--Jeremy
smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc and universal binaries
Ok, thanks.
In that case I'll abandon the idea of supporting PPC. It sounds like there
would be too much tweaking of mac ports above and beyond the SO instructions
for obtaining a PPC SDK.
Btw, I don't really care about LIPO. I would be happy with four binaries of my
project.
Kind regards,
Sam Halliday
--
Sent from my iPhone
On 25 Aug 2013, at 16:33, Jeremy Huddleston Sequoia jerem...@macports.org
wrote:
On Aug 25, 2013, at 4:21, Samuel Halliday sam.halli...@gmail.com wrote:
Thanks all,
In order to build a ppc gfortran app, I need the Xcode 3 PPC compiler (I
think that's what a lot of these comments have been about). There is a SO
thread about how to do this:
http://stackoverflow.com/questions/5333490
But once I have my universal gcc48 (not apple-gcc*), it would appear that
the -arch flags must be passed one at a time. BTW, it seems the default
gcc48 can build 32 bit fortran apps (even though it's a x86_64 build) but
can't link them (hence the need for gcc48 +universal).
Before I embark on the insane mission of obtaining xcode3 ppc compilers, can
somebody confirm for me if the gcc48 +universal (with universal including
ppc) will be able to compile ppc binaries using -arch ppc?
No, it won't. +universal in the gcc ports means i386/x86_64 or ppc/ppc64:
platform powerpc {
configure.universal_archs ppc ppc64
}
platform i386 {
configure.universal_archs i386 x86_64
}
If you want to fix that, you'll need to bring the Apple gcc driver driver
into the gccXX ports and update those ports to build once for ppc and then
again for i386 ... see the apple-gcc42 port for how this is done as well as
the driver driver source code.
* one could edit
https://trac.macports.org/browser/trunk/dports/lang/apple-gcc42/Portfile to
include the fortran language, but I'd rather not get into customising
portfiles. Besides, I thought apple used LLVM nowadays.
You're not going to solve this without either:
1) Moving to Snow Leopard or earlier (so you can have a MacPorts ppc
runtime, so you can have a gfortran compiler that produces ppc code)
2) Making a darwin-ppc cross compiler (again, not in MacPorts, but our
assembler (cctools) and linker (ld64) should work for you)
3) Adding fortran support to apple-gcc42 (and using the 10.5 or 10.4u SDK)
4) Adding support for generating ppc code with the gccXX ports when running
on intel
You're going to need to change around Portfiles or do a lot by hand to solve
this problem.
Alternatively, you could have a SL or Leopard machine do the ppc bits and a
ML machine do the i386/x86_64 bits. Then just lipo them all together into
the final executable. This is essentially how I build the host support
library that is shipped with quartz-wm.
--Jeremy
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc and universal binaries
On Aug 25, 2013, at 1:22 PM, Sam Halliday sam.halli...@gmail.com wrote: In that case I'll abandon the idea of supporting PPC. It sounds like there would be too much tweaking of mac ports above and beyond the SO instructions for obtaining a PPC SDK. Btw, I don't really care about LIPO. I would be happy with four binaries of my project. Lipo-ing the build products together would be by far the simplest part of this whole thing. vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
gcc and universal binaries
Hi all, I'm using the macports distro of gcc in order to get fortran support. Could somebody please show me how to build universal binaries that work on the four targets: PPC/Intel 32/64? I presume I'll need to get this fixed: $ file /opt/local/lib/libgcc/libgfortran.3.dylib /opt/local/lib/libgcc/libgfortran.3.dylib: Mach-O 64-bit x86_64 dynamically linked shared library -- Sam ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc and universal binaries
On Aug 24, 2013, at 07:29, Samuel Halliday wrote: I'm using the macports distro of gcc in order to get fortran support. Could somebody please show me how to build universal binaries that work on the four targets: PPC/Intel 32/64? I presume I'll need to get this fixed: $ file /opt/local/lib/libgcc/libgfortran.3.dylib /opt/local/lib/libgcc/libgfortran.3.dylib: Mach-O 64-bit x86_64 dynamically linked shared library Edit /opt/local/etc/macports/macports.conf and set universal_archs to x86_64 i386 ppc64 ppc. Then reinstall libgcc with the universal variant. And maybe the gcc port you're using too. If you already had any ports installed using the universal variant they'll have to be rebuilt using the new set of architectures. Not sure if MacPorts will do that for you automatically or not. I would expect that modern versions of OS X cannot build for PowerPC anymore, so you'll need to be running as sufficiently old version of OS X. Lion and later are too new. Snow Leopard is probably old enough. Leopard is definitely old enough. Tiger is too old to build 64-bit in some cases. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc and universal binaries
Thanks Ryan, Assuming my Mountain Lion can actually build PPC binaries, your solution would appear to want to build universal bins for everything on my system. Can I specify that I just want the gfortran and its deps to be built universally? Also, what command line arguments do I use to get universal builds in my own projects? -- Sam On 24 Aug 2013, at 16:00, Ryan Schmidt ryandes...@macports.org wrote: On Aug 24, 2013, at 07:29, Samuel Halliday wrote: I'm using the macports distro of gcc in order to get fortran support. Could somebody please show me how to build universal binaries that work on the four targets: PPC/Intel 32/64? I presume I'll need to get this fixed: $ file /opt/local/lib/libgcc/libgfortran.3.dylib /opt/local/lib/libgcc/libgfortran.3.dylib: Mach-O 64-bit x86_64 dynamically linked shared library Edit /opt/local/etc/macports/macports.conf and set universal_archs to x86_64 i386 ppc64 ppc. Then reinstall libgcc with the universal variant. And maybe the gcc port you're using too. If you already had any ports installed using the universal variant they'll have to be rebuilt using the new set of architectures. Not sure if MacPorts will do that for you automatically or not. I would expect that modern versions of OS X cannot build for PowerPC anymore, so you'll need to be running as sufficiently old version of OS X. Lion and later are too new. Snow Leopard is probably old enough. Leopard is definitely old enough. Tiger is too old to build 64-bit in some cases. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc and universal binaries
On Sat, Aug 24, 2013 at 5:08 PM, Samuel Halliday wrote: Thanks Ryan, Assuming my Mountain Lion can actually build PPC binaries, It cannot. You really need to use Snow Leopard if you want to build for x86_64, i386 and ppc (conditionally Leopard, but support for x86_64 is not quite mature there yet). I don't know about ppc64, but basically nobody uses those. Also, if you are using Mountain Lion your binaries will only work on Lion (if you configure the project properly, otherwise it will only work on 10.8 and later) and Lion doesn't work on PowerPC and i386, it doesn't even work on all 64-bit machines. Also, what command line arguments do I use to get universal builds in my own projects? export CFLAGS=-arch i386 -arch ppc -arch x86_64 and same for CXXFLAGS, LDFLAGS, ... I would say also FFLAGS, but I'm not sure where you will get a suitable fortran compiler to accept these. You might need to compile for each architecture separately and lipo the binaries together at the end (I might be wrong, but Fortran compilers are a mess with relatively pure support in general. You first need to check which flags are supported by the Fortran compiler. Maybe the gnu compiler started supporting -arch recently, but some years ago it only supported -m32 and -m64. There were some other compilers that supported -arch) Mojca PS: Honestly, if you plan to build Fortran code for four architectures, all I can say is good luck. It's probably not impossible, but you'll need a bit more than a few settings in MacPorts configuration, and you definitely need an older OS first. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc and universal binaries
On Aug 24, 2013, at 10:08, Samuel Halliday wrote: Assuming my Mountain Lion can actually build PPC binaries, I'd be surprised if it could. I don't think Apple is including PowerPC compilers anymore. your solution would appear to want to build universal bins for everything on my system. You'll only get universal builds if you ask for the +universal variant. Can I specify that I just want the gfortran and its deps to be built universally? Yes, only install the gcc port you're using with the +universal variant (and don't use that variant for other unrelated ports). MacPorts will automatically install its dependencies with the universal variant, if they weren't already. If they were already installed with the old (i386 x86_84) universal variant, I do not know if MacPorts will rebuild them as 4-way universal for you; if it doesn't, the build will fail and you'll have to manually rebuild the ports, in the right order. Also, what command line arguments do I use to get universal builds in my own projects? It varies from project to project. The default setup in MacPorts is to add all the -arch flags (e.g. -arch x86_64 -arch i386 -arch ppc64 -arch ppc) to CFLAGS, CXXFLAGS, LDFLAGS, OBJCFLAGS, OBJCXXFLAGS. But not all projects respect those variables. Also, some projects will not build correctly for multiple architectures: either the build will fail, or the build will succeed but be faulty. To fix this, you have to build the project separately for each architecture and then all the different versions of each library or binary need to be joined together using `lipo`. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc and universal binaries
On Aug 24, 2013, at 10:23, Mojca Miklavec wrote: It cannot. You really need to use Snow Leopard if you want to build for x86_64, i386 and ppc (conditionally Leopard, but support for x86_64 is not quite mature there yet). I don't know about ppc64, but basically nobody uses those. Leopard should be fine for 64-bit. Tiger has trouble with it sometimes since 64-bit was new in Tiger. Maybe the gnu compiler started supporting -arch recently, but some years ago it only supported -m32 and -m64. There were some other compilers that supported -arch) I hear FSF gcc started supporting -arch flags in version 4.7 but does not support multiple -arch flags in a single invocation. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc and universal binaries
On 24 Aug 2013, at 16:24, Ryan Schmidt wrote: what command line arguments do I use to get universal builds in my own projects? add all the -arch flags (e.g. -arch x86_64 -arch i386 -arch ppc64 -arch ppc) I'm guessing these instructions are for the apple gcc? Because doing this with the gcc / gfortran that I've been installing with macports gives gcc-mp-4.8: error: unrecognized command line option '-arch' and trying to compile C code on Mountain Lion with the apple gcc gives llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory So I'm concluding it is impossible to build universal fortran apps since the apple gcc doesn't come with gfortran. My only hope would be to build separate binaries for each architecture by: 1. access to old OS X machines (+ macports) 2. cross compile I don't have access to old machines (and it would be incredibly inconvenient in any case), and I'm guessing macports doesn't supply cross compilers for older OS X architectures. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc and universal binaries
In article b673f8f2-3c21-4ea7-b5f7-2b33fd895...@gmail.com, Samuel Halliday sam.halli...@gmail.com wrote: On 24 Aug 2013, at 16:24, Ryan Schmidt wrote: what command line arguments do I use to get universal builds in my own projects? add all the -arch flags (e.g. -arch x86_64 -arch i386 -arch ppc64 -arch ppc) I'm guessing these instructions are for the apple gcc? Because doing this with the gcc / gfortran that I've been installing with macports gives gcc-mp-4.8: error: unrecognized command line option '-arch' and trying to compile C code on Mountain Lion with the apple gcc gives llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory So I'm concluding it is impossible to build universal fortran apps since the apple gcc doesn't come with gfortran. My only hope would be to build separate binaries for each architecture by: 1. access to old OS X machines (+ macports) 2. cross compile I don't have access to old machines (and it would be incredibly inconvenient in any case), and I'm guessing macports doesn't supply cross compilers for older OS X architectures. You *might* be able to build for all four architectures on Mountain LIon if you can successfully install a version of Xcode 3 (like 3.2.6) as a secondary Xcode and use the build tools and 10.5 SDK it provides. xcrun can help with this but I don't think MacPorts supports building with a non-installed SDK so you'd still be on your own. Another, more reliable option to consider is running an older version of OS X, like 10.5 server, as a virtual machine in VMware Fusion or similar. Be aware that the software license of 10.5 (non-server) prohibited use as a virtual client and Fusion does enforce that but the Interwebs tell of ways to get around that when running on a Mac host. -- Ned Deily, n...@acm.org ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc and universal binaries
On Aug 24, 2013, at 8:00, Ryan Schmidt ryandes...@macports.org wrote: On Aug 24, 2013, at 07:29, Samuel Halliday wrote: I'm using the macports distro of gcc in order to get fortran support. Could somebody please show me how to build universal binaries that work on the four targets: PPC/Intel 32/64? I presume I'll need to get this fixed: $ file /opt/local/lib/libgcc/libgfortran.3.dylib /opt/local/lib/libgcc/libgfortran.3.dylib: Mach-O 64-bit x86_64 dynamically linked shared library Edit /opt/local/etc/macports/macports.conf and set universal_archs to x86_64 i386 ppc64 ppc. Then reinstall libgcc with the universal variant. And maybe the gcc port you're using too. If you already had any ports installed using the universal variant they'll have to be rebuilt using the new set of architectures. Not sure if MacPorts will do that for you automatically or not. I would expect that modern versions of OS X cannot build for PowerPC anymore, so you'll need to be running as sufficiently old version of OS X. Lion and later are too new. Snow Leopard is probably old enough. Leopard is definitely old enough. Tiger is too old to build 64-bit in some cases. If you're on SL, you'll need to use the 10.5 SDK if you actually want ppc64 support. You probably don't want or need ppc64 support (and ppc64 is likely horrifically broken in MacPorts), so I suggest using Snow Leopard with universal_archs to x86_64 i386 ppc. On Aug 24, 2013, at 15:07, Samuel Halliday sam.halli...@gmail.com wrote: On 24 Aug 2013, at 16:24, Ryan Schmidt wrote: what command line arguments do I use to get universal builds in my own projects? add all the -arch flags (e.g. -arch x86_64 -arch i386 -arch ppc64 -arch ppc) I'm guessing these instructions are for the apple gcc? Because doing this with the gcc / gfortran that I've been installing with macports gives gcc-mp-4.8: error: unrecognized command line option '-arch' Did you build it with the +universal variant? Also, I think FSF just aliases -arch to -mXXX. It does not seem to support multiple -arch options right: ~ $ gcc-mp-4.8 -arch x86_64 -c test.c ~ $ file test.o test.o: Mach-O 64-bit x86_64 object ~ $ gcc-mp-4.8 -arch x86_64 -arch i386 -c test.c ~ $ file test.o test.o: Mach-O i386 object ~ $ gcc-mp-4.8 -arch i386 -arch x86_64 -c test.c /var/folders/1b/f1bzh5152y9bvygzl07fn87mgn/T//cc7eJXt5.s:5:bad register name `%rbp' /var/folders/1b/f1bzh5152y9bvygzl07fn87mgn/T//cc7eJXt5.s:7:bad register name `%rsp' /var/folders/1b/f1bzh5152y9bvygzl07fn87mgn/T//cc7eJXt5.s:10:bad register name `%rbp' and trying to compile C code on Mountain Lion with the apple gcc gives llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory Yeah. You need to be on Snow Leopard if you want to compile for ppc. So I'm concluding it is impossible to build universal fortran apps since the apple gcc doesn't come with gfortran. That depends on what you mean by universal. It's possible to build i386/x86_64 using gfortran plus lipo (look at the libgcc subport of gcc48 for example) My only hope would be to build separate binaries for each architecture by: 1. access to old OS X machines (+ macports) 2. cross compile I don't have access to old machines (and it would be incredibly inconvenient in any case), and I'm guessing macports doesn't supply cross compilers for older OS X architectures. You just need the SDK. It's theoretically possible for you to use the 10.5 SDK on a modern system, but you'll need to build a ppc compiler. There's a chance that the apple-gcc42 port may work for you, but it will likely require a bit of massaging (patches welcome). --Jeremy smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Why does Virtualbox need Universal binaries?
Second on the buildbot + universal suggestion. That was my big disappointment with building Virtualbox- now almost every package has going to have to be built from source, rather than installed from binary from now on. On Wed, May 15, 2013 at 7:32 PM, Bradley Giesbrecht pixi...@macports.orgwrote: On May 15, 2013, at 1:40 PM, Ryan Schmidt wrote: On May 15, 2013, at 15:38, John Ruschmeyer wrote: I decided to install Virtualbox via MacPorts as opposed to installing the binary from Oracle. What has happended, though, is that MacPorts has started recompiling dependencies with +Universal (currently on glib2). What I don't understand is why this is necessary, particularly since Virtualbox will never run on anything other than an Intel-based system? Virtualbox installs a kernel extension. So it needs to build for the same architecture as your kernel. Your Mac is presumably one of the early Intel Macs that uses a 32-bit kernel, therefore Virtualbox builds itself 32-bit. In order to do that, MacPorts must first rebuild all of its dependencies universal (32-bit and 64-bit). buildbot +universal would be nice Regards, Bradley Giesbrecht (pixilla) ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Why does Virtualbox need Universal binaries?
On Thu, May 16, 2013 at 5:50 AM, John Ruschmeyer jrusc...@gmail.com wrote: Second on the buildbot + universal suggestion. That was my big disappointment with building Virtualbox- now almost every package has going to have to be built from source, rather than installed from binary from now on. -- Eric A. Borisch I'm a fan of using MacPorts for many things as much as the next guy, but why not just use the official builds of VirtualBox? (I went down the same path a while back, and when I saw MP start to rebuild all the deps +universal I aborted and said I can download one thing from Oracle and live with myself.) - Eric ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Why does Virtualbox need Universal binaries?
I'm a fan of using MacPorts for many things as much as the next guy, but why not just use the official builds of VirtualBox? (I went down the same path a while back, and when I saw MP start to rebuild all the deps +universal I aborted and said I can download one thing from Oracle and live with myself.) I hope though you whip yourself at least once a week in penance for your sin ;) ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Why does Virtualbox need Universal binaries?
A further question: Does the virtualbox-guest-additions port install the additions on the current system (i.e., a VM of Mac OS X) or install the multi-platform .iso file? Thanks... JR On Thu, May 16, 2013 at 11:40 AM, Chris Jones jon...@hep.phy.cam.ac.ukwrote: I'm a fan of using MacPorts for many things as much as the next guy, but why not just use the official builds of VirtualBox? (I went down the same path a while back, and when I saw MP start to rebuild all the deps +universal I aborted and said I can download one thing from Oracle and live with myself.) I hope though you whip yourself at least once a week in penance for your sin ;) ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Why does Virtualbox need Universal binaries?
On May 16, 2013, at 10:16 AM, John Ruschmeyer wrote: A further question: Does the virtualbox-guest-additions port install the additions on the current system (i.e., a VM of Mac OS X) or install the multi-platform .iso file? This might answer your question: $ port distfiles virtualbox-guest-additions ... http://download.virtualbox.org/virtualbox/4.2.12/VBoxGuestAdditions_4.2.12.iso ... Regards, Bradley Giesbrecht (pixilla) ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Why does Virtualbox need Universal binaries?
On May 16, 2013, at 16:33, Bradley Giesbrecht wrote: On May 16, 2013, at 10:16 AM, John Ruschmeyer wrote: A further question: Does the virtualbox-guest-additions port install the additions on the current system (i.e., a VM of Mac OS X) or install the multi-platform .iso file? This might answer your question: $ port distfiles virtualbox-guest-additions ... http://download.virtualbox.org/virtualbox/4.2.12/VBoxGuestAdditions_4.2.12.iso … And (if you already installed the port): $ port contents virtualbox-guest-additions Port virtualbox-guest-additions contains: /Applications/MacPorts/VirtualBox.app/Contents/MacOS/additions/VBoxGuestAdditions.iso ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Why does Virtualbox need Universal binaries?
On May 16, 2013, at 05:50, John Ruschmeyer wrote: Second on the buildbot + universal suggestion. https://trac.macports.org/ticket/35897 That was my big disappointment with building Virtualbox- now almost every package has going to have to be built from source, rather than installed from binary from now on. Only on Macs that don't use the 64-bit Intel kernel. Note that some early 64-bit Intel Macs that use the 32-bit kernel under Snow Leopard use the 64-bit kernel under Lion and Mountain Lion, so upgrading your OS may be a way that you can avoid the problem. There are many restrictions to binaries; you've merely found one more (which only applies to the ports that build kernel extensions, which can be counted on one hand). We only have buidbots for Snow Leopard, Lion and Mountain Lion; only for 64-bit (unless a universal version is required by a port); only for default variants; only for default prefix, frameworks_dir and applications_dir; only for ports where the licenses allow binary redistribution, … Binaries are a convenience (and a recently-added one at that), and not a necessity. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Why does Virtualbox need Universal binaries?
I decided to install Virtualbox via MacPorts as opposed to installing the binary from Oracle. What has happended, though, is that MacPorts has started recompiling dependencies with +Universal (currently on glib2). What I don't understand is why this is necessary, particularly since Virtualbox will never run on anything other than an Intel-based system? Thanks... JR ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Why does Virtualbox need Universal binaries?
On May 15, 2013, at 15:38, John Ruschmeyer wrote: I decided to install Virtualbox via MacPorts as opposed to installing the binary from Oracle. What has happended, though, is that MacPorts has started recompiling dependencies with +Universal (currently on glib2). What I don't understand is why this is necessary, particularly since Virtualbox will never run on anything other than an Intel-based system? Virtualbox installs a kernel extension. So it needs to build for the same architecture as your kernel. Your Mac is presumably one of the early Intel Macs that uses a 32-bit kernel, therefore Virtualbox builds itself 32-bit. In order to do that, MacPorts must first rebuild all of its dependencies universal (32-bit and 64-bit). ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Why does Virtualbox need Universal binaries?
On May 15, 2013, at 1:40 PM, Ryan Schmidt wrote: On May 15, 2013, at 15:38, John Ruschmeyer wrote: I decided to install Virtualbox via MacPorts as opposed to installing the binary from Oracle. What has happended, though, is that MacPorts has started recompiling dependencies with +Universal (currently on glib2). What I don't understand is why this is necessary, particularly since Virtualbox will never run on anything other than an Intel-based system? Virtualbox installs a kernel extension. So it needs to build for the same architecture as your kernel. Your Mac is presumably one of the early Intel Macs that uses a 32-bit kernel, therefore Virtualbox builds itself 32-bit. In order to do that, MacPorts must first rebuild all of its dependencies universal (32-bit and 64-bit). buildbot +universal would be nice Regards, Bradley Giesbrecht (pixilla) ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Universal Binaries
2009/1/25 Joshua Root j...@macports.org Timothy Lee wrote: Ryan- Thanks for the tip on not adding the '/' to the --prefix - that fixed the problem. In regards to the +universal variants - my universal_target only contains i386 as suggested by Josh. My other settings look like this: *# Options for Universal Binaries (+universal variant)* * * *# MACOSX_DEPLOYMENT_TARGET* *universal_target10.4* * * *# the SDK sysroot to use * *universal_sysroot /Xcode3_0/SDKs/MacOSX10.4u.sdk* * * *# machine architectures* *universal_archs i386* Again- my variants.conf only contains +universal and my macports.conf as the variants_conf path set correctly - yet I still see the deployment is being set to 10.5. Argh, sorry, I forgot - this is broken in the released version. I fixed it here: http://trac.macports.org/changeset/44363 You can apply that change to /opt/local/share/macports/Tcl/port1.0/portmain.tcl, or install MP from svn trunk if you're so inclined. That might also be the reason why it worked for me by accident. I installed the pre 1.7 svn trunk somewhere in October/November and worked with it until 5th or 6th of January. I skipped the official 1.7 version and installed a new version of the svn trunk (somewhere on 4-6 January), obviously including the patch (didn't even know there was one). Sorry for also introducing some confusion due to this. Harry ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
On 2009-01-24 19:25:51 +0100, Harry van der Wolf wrote: It is something completely different. Most linux, netbsd and freebsd packages rely on X11. MacOSX has support for x11 but the native windowing system of MacOSX is aqua. Using the -x11 option means that you don't build for X11. An increasing amount of binaries and libraries support native aqua and in that case I don't want to build for X11. It's slower, bigger (X11 takes also memory and resources next to the already available aqua) and ugglier. But the last is off course a matter of taste. But in MacPorts, is it possible to have both an Aqua version and an X11 version (for execution on a remote display)? -- Vincent Lefèvre vinc...@vinc17.org - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
Harry van der Wolf wrote: 2009/1/25 Joshua Root j...@macports.org mailto:j...@macports.org Timothy Lee wrote: Again- my variants.conf only contains +universal and my macports.conf as the variants_conf path set correctly - yet I still see the deployment is being set to 10.5. Argh, sorry, I forgot - this is broken in the released version. I fixed it here: http://trac.macports.org/changeset/44363 You can apply that change to /opt/local/share/macports/Tcl/port1.0/portmain.tcl, or install MP from svn trunk if you're so inclined. That might also be the reason why it worked for me by accident. I installed the pre 1.7 svn trunk somewhere in October/November and worked with it until 5th or 6th of January. I skipped the official 1.7 version and installed a new version of the svn trunk (somewhere on 4-6 January), obviously including the patch (didn't even know there was one). Sorry for also introducing some confusion due to this. The fix has now been merged to the 1.7.x branch as well, so there's the option to get that if you don't want to be quite so on the bleeding edge. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
If I hand edit the /opt/local/share/macports/Tcl/port1.0/portmain.tcl file, will it be 'merged' automatically the next time macports version is bumped or is it a simple 'rm' and then 'cp' the new file in? thanks Harry van der Wolf hvdw...@gmail.com wrote: 2009/1/25 Joshua Root j...@macports.org Timothy Lee wrote: Ryan- Thanks for the tip on not adding the '/' to the --prefix - that fixed the problem. In regards to the +universal variants - my universal_target only contains i386 as suggested by Josh. My other settings look like this: *# Options for Universal Binaries (+universal variant)* * * *# MACOSX_DEPLOYMENT_TARGET* *universal_target10.4* * * *# the SDK sysroot to use * *universal_sysroot /Xcode3_0/SDKs/MacOSX10.4u.sdk* * * *# machine architectures* *universal_archs i386* Again- my variants.conf only contains +universal and my macports.conf as the variants_conf path set correctly - yet I still see the deployment is being set to 10.5. Argh, sorry, I forgot - this is broken in the released version. I fixed it here: http://trac.macports.org/changeset/44363 You can apply that change to /opt/local/share/macports/Tcl/port1.0/portmain.tcl, or install MP from svn trunk if you're so inclined. That might also be the reason why it worked for me by accident. I installed the pre 1.7 svn trunk somewhere in October/November and worked with it until 5th or 6th of January. I skipped the official 1.7 version and installed a new version of the svn trunk (somewhere on 4-6 January), obviously including the patch (didn't even know there was one). Sorry for also introducing some confusion due to this. Harry ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
tim...@rochester.rr.com wrote: If I hand edit the /opt/local/share/macports/Tcl/port1.0/portmain.tcl file, will it be 'merged' automatically the next time macports version is bumped or is it a simple 'rm' and then 'cp' the new file in? The file is overwritten on upgrade, but that won't be an issue because the fix will be in 1.7.1. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
2009/1/26 Vincent Lefevre vincent-opd...@vinc17.org On 2009-01-24 19:25:51 +0100, Harry van der Wolf wrote: It is something completely different. Most linux, netbsd and freebsd packages rely on X11. MacOSX has support for x11 but the native windowing system of MacOSX is aqua. Using the -x11 option means that you don't build for X11. An increasing amount of binaries and libraries support native aqua and in that case I don't want to build for X11. It's slower, bigger (X11 takes also memory and resources next to the already available aqua) and ugglier. But the last is off course a matter of taste. But in MacPorts, is it possible to have both an Aqua version and an X11 version (for execution on a remote display)? No. That's not possible in one macports tree. Libraries and binaries need to be compiled either for X11 or for Aqua. If you are adventurous you can off course create/install the default tree in /opt/local and compile macports by hand and set the prefix and so on to (for example) /aqua/local. It will be a complicated setup as you also have to be very careful about PATH settings and so on, but I have used it a short while when moving from X11 to Aqua for avidemux (but it is very error prone). Harry ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
Ryan- Thanks for the tip on not adding the '/' to the --prefix - that fixed the problem. In regards to the +universal variants - my universal_target only contains i386 as suggested by Josh. My other settings look like this: # Options for Universal Binaries (+universal variant) # MACOSX_DEPLOYMENT_TARGET universal_target10.4 # the SDK sysroot to use universal_sysroot /Xcode3_0/SDKs/MacOSX10.4u.sdk # machine architectures universal_archs i386 Again- my variants.conf only contains +universal and my macports.conf as the variants_conf path set correctly - yet I still see the deployment is being set to 10.5. Any suggestions? thanks On Jan 24, 2009, at 8:21 PM, Ryan Schmidt wrote: On Jan 24, 2009, at 14:01, Timothy Lee wrote: Exact same settings as below (except I'm only building i386), yet I'm still seeing DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.5'. Any Ideas? Only building i386 -- does that mean you are not using the +universal variant? If so, the universal_target setting is not used, as I believe Josh mentioned earlier in this thread. Also - I'm seeing Warning: Please fix or indicate this misbehavior (if it is intended) on every install saying that / mopt/local/bin is in violation - any ideas on this? Did you have a slash at the end of your --prefix when you configured -- i.e. ./configure --prefix=/mopt/local/bin/? If so, reconfigure and omit the slash at the end -- i.e. ./configure --prefix=/mopt/ local/bin (and then of course make and sudo make install). This will be fixed in MacPorts 1.8.0. http://trac.macports.org/ticket/13789 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
Harry- Thanks for the response! On Jan 25, 2009, at 3:37 PM, Harry van der Wolf wrote: 2009/1/25 Timothy Lee tim...@rochester.rr.com Ryan- Thanks for the tip on not adding the '/' to the --prefix - that fixed the problem. In regards to the +universal variants - my universal_target only contains i386 as suggested by Josh. My other settings look like this: # Options for Universal Binaries (+universal variant) # MACOSX_DEPLOYMENT_TARGET universal_target10.4 # the SDK sysroot to use universal_sysroot /Xcode3_0/SDKs/MacOSX10.4u.sdk # machine architectures universal_archs i386 Again- my variants.conf only contains +universal and my macports.conf as the variants_conf path set correctly - yet I still see the deployment is being set to 10.5. Any suggestions? thanks The line # machine architectures universal_archs i386 is not correct. Sorry for maybe explaining the obvious but do you know what universal means? It means that it will run on both the ppc as well as the intel platform. In it's basic form this means that you will need to make a 32bit binary/library that is both ppc and i386. If you really want to build for all options you should even make 4way architecture builds for 32bit and 64bit, meaning: ppc, i386 (intel single core), ppc64 (G5) and x86_64 (intel core duo and better). ppc can be ppc (runs on =G3), ppc740 (runs on =G4) and ppc750 (runs on =G5 in 32bit mode). So to be able to build universal for all systems =G3 you need ppc and i386. This means that you need to specify # machine architectures universal_archs ppc i386 With your line you only build for i386. This is not universal. Macports does not yet support the 64bit builds. (When I build 4way architecture builds (occasionally for Hugin) I build them outside macports.) Yep - all too familiar with the different architectures. My reasoning for adding i386 on a line by itself is that I only care about i386 builds (suggested by Joshua). I have a ppc 10.4 machine that I am performing my 10.4 builds on and when the i386-10.4-compatible builds are complete on my 10.5 machine, I will 'lipo' the ppc and i386 builds together. Unfortunately my target build (Musicbrainz Picard v0.11) currently needs to be 'lipo'-ed together due to endian-issues. With regard to your Again- my variants.conf only contains +universal and my macports.conf as the variants_conf path set correctly - yet I still see the deployment is being set to 10.5. Please check whether /Xcode3_0/SDKs/MacOSX10.4u.sdk is really the correct path. If it can't find the 10.4u.sdk it might default to the 10.5.sdk using the 0.5 deplyment target (which is default for 10.5). My macports is using the 10.4u.sdk for deployment target 10.4.This functions for me but I do have my sdk's in the default /Developer/ SDKs/MacOSX10.4u.sdk. Yes, I have BOTH xcode 2.5 and 3.0 installed. Why? Aaron Hillegas's Cocoa book uses Xcode 2.5 and there are many changes in Xcode 3.0 that make using the book difficult to use to learn cocoa. So - I have 2.5 installed for educational purposes and Xcode 3.x installed to 'stay current. My directories are /Xcode3_0/SDKs/ and /Xcode2_5/SDKs/. When build with the -v flag in macports I do see it properly linking against /Xcode3_0/SDKs/MacOSX10.4u.sdk. For some reason the I'm still seeing 10.5 show up in my deployment target though. You might even check if /Developer/SDKs/MacOSX10.5.sdk exists. Macports runs on top off gcc. I'm not sure how solid macports can overrule gcc standard settings if gcc finds a 10.5.sdk in / Developer. (I have no experience with that. It's only guessing on this part). Finally: you mention /mopt/local/bin. Do you also have an old default /opt/local/bin that still can be found via the path? So - again, to be confusing :) I keep a 10.5 macports in /opt and my 10.4 'compatible' macports install in /mopt/ (actually i just changed it to /tigeropt/). All paths are properly set in each shell that I use based on which macports install I am using (I have my normal .bash_profile use my /opt/ install and if I want to use my tiger install I explicitly source a file that changes all paths with / opt in it to /tigeropt/ in my env. All configuration files reference the correct (version-dependent) macports install. I've even tried changing my /opt/local/etc/macports/macports.conf's universal_target (when using my /tigeropt/ paths) to see if somehow I was incorrectly reading my /opt/ config files - and that didn't work either - still receiving '10.5' as my deployment target. Harry ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
(Sorry, my previous mail was a direct mail and not to the macports users group). Why don't you use the ready available universal dmg available for OSX ( http://musicbrainz.org/ftpmirror/pub/musicbrainz/users/robert/picard-0.9.0beta1-build2.dmg ) Harry ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
Timothy Lee wrote: Ryan- Thanks for the tip on not adding the '/' to the --prefix - that fixed the problem. In regards to the +universal variants - my universal_target only contains i386 as suggested by Josh. My other settings look like this: *# Options for Universal Binaries (+universal variant)* * * *# MACOSX_DEPLOYMENT_TARGET* *universal_target10.4* * * *# the SDK sysroot to use * *universal_sysroot /Xcode3_0/SDKs/MacOSX10.4u.sdk* * * *# machine architectures* *universal_archs i386* Again- my variants.conf only contains +universal and my macports.conf as the variants_conf path set correctly - yet I still see the deployment is being set to 10.5. Argh, sorry, I forgot - this is broken in the released version. I fixed it here: http://trac.macports.org/changeset/44363 You can apply that change to /opt/local/share/macports/Tcl/port1.0/portmain.tcl, or install MP from svn trunk if you're so inclined. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
2009/1/24 Ryan Schmidt ryandes...@macports.org On Jan 23, 2009, at 09:11, tim...@rochester.rr.com tim...@rochester.rr.com wrote: Joshua Root j...@macports.org wrote: Timothy Lee wrote: Do you know if its possible for me (on leopard) to build x86 code (all my macports ports) that will also run on Tiger? Short of physical access to an intel 10.4 install, is there anything I can do? I am the OSX bundle maintainer of avidemux (I maintain others too but via other ways). I build my avidemux binaries and dependent libs as universal ones on Leopard (using macports for all necessary libs) and the bundle (including binary and necessary libraries) is used on Tiger as well as Leopard. Note that avidemux is available as macports package, but I build (b)leeding edge svn bundles. I need to compile avidemux for i386 and ppc from svn trunk and lipo merge them to make them universal. The bundle contains some complicated libraries (glib, pango, cairo, gtk and they are all built universal and without X11 (so native aqua) via macports) and this works fine. (Two libs are not yet in macports and I need to make ports as soon as I have time to do so, but maintaining three packages and developing my own takes quite some spare time) Don't forget to use Reply All so the discussion goes to the list as well. There are no guarantees that this will work, but the way to do what you want would be to set universal_target to 10.4, universal_sysroot to /Developer/SDKs/MacOSX10.4u.sdk, and universal_archs to i386. Then build everything with +universal (best to add it to your variants.conf). Also set x11prefix to /usr/X11R6; Leopard's X11 prefix /usr/X11 does not exist on Tiger. Thanks for the tip! Has anyone tried this? Success/failure stories? openssl failed for me when I tried it this way on Leopard. Switching back to 10.5 and the 10.5 SDK fixed it. 90% builds OK. Some other binaries and libraries fail to build this universal way: gimp (now built as i386 aqua), sqlite3 (is a pain in the backside anyway), subversion (svn), wxwidgets (wxMac), wine, libGLEW, libOrbit, libSDL*, liba52*, libav*, libbonobo, libboost, libgnome, libpoppler and some others. I build these binaries/libraries with sudo port package -universal as I have +universal (and -x11) in my variants.conf Next to that: some libraries can be build universal as static libs, but not as dynamic libs like x264 (can't remember the other one) Also: some libs are so POSIX compliant that, when build via macports on Leopard, they can't be used on Tiger. (lib)xvid is one. I need to build that one manually. Note: I mentioned in a earlier post in this thread that I have # the SDK sysroot to use universal_sysroot /Developer/SDKs/MacOSX10.4u.sdk in my macports.conf. Technically speaking you can just as well use the 10.5 SDK as that one builds for 10.4 too as long as you set the deployment target to 10.4. I choose the 10.4 SDK as quite some packages are not yet 10.5 SDK optimized which led to some errors (pango and gtk). The 10.5 SDK uses some new stuff that works fine on Leopard but not on Tiger as most ports are actually linux based and ported to Mac. Maybe they are already fixed but I did not check yet. Harry ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
Thanks for the reply Harry- I'm fairly sure that I will need to lipo together the builds for Musicbrainz' Picard. So - in your experience what are all the options that I must set after a fresh src install to have a 10.5 setup building binaries for 10.4? Also, does anyone know how UB deals with endian-specific code? Does the c-preprocessor run twice and eval all the #ifdef big_endian (or whatever the define/macro would be)? Or is there some other way to do this that wouldn't require two runs of the cpp. Thanks Tim On Jan 24, 2009, at 8:49 AM, Harry van der Wolf wrote: 2009/1/24 Ryan Schmidt ryandes...@macports.org On Jan 23, 2009, at 09:11, tim...@rochester.rr.com tim...@rochester.rr.com wrote: Joshua Root j...@macports.org wrote: Timothy Lee wrote: Do you know if its possible for me (on leopard) to build x86 code (all my macports ports) that will also run on Tiger? Short of physical access to an intel 10.4 install, is there anything I can do? I am the OSX bundle maintainer of avidemux (I maintain others too but via other ways). I build my avidemux binaries and dependent libs as universal ones on Leopard (using macports for all necessary libs) and the bundle (including binary and necessary libraries) is used on Tiger as well as Leopard. Note that avidemux is available as macports package, but I build (b)leeding edge svn bundles. I need to compile avidemux for i386 and ppc from svn trunk and lipo merge them to make them universal. The bundle contains some complicated libraries (glib, pango, cairo, gtk and they are all built universal and without X11 (so native aqua) via macports) and this works fine. (Two libs are not yet in macports and I need to make ports as soon as I have time to do so, but maintaining three packages and developing my own takes quite some spare time) Don't forget to use Reply All so the discussion goes to the list as well. There are no guarantees that this will work, but the way to do what you want would be to set universal_target to 10.4, universal_sysroot to /Developer/SDKs/MacOSX10.4u.sdk, and universal_archs to i386. Then build everything with +universal (best to add it to your variants.conf). Also set x11prefix to /usr/X11R6; Leopard's X11 prefix /usr/X11 does not exist on Tiger. Thanks for the tip! Has anyone tried this? Success/failure stories? openssl failed for me when I tried it this way on Leopard. Switching back to 10.5 and the 10.5 SDK fixed it. 90% builds OK. Some other binaries and libraries fail to build this universal way: gimp (now built as i386 aqua), sqlite3 (is a pain in the backside anyway), subversion (svn), wxwidgets (wxMac), wine, libGLEW, libOrbit, libSDL*, liba52*, libav*, libbonobo, libboost, libgnome, libpoppler and some others. I build these binaries/libraries with sudo port package - universal as I have +universal (and -x11) in my variants.conf Next to that: some libraries can be build universal as static libs, but not as dynamic libs like x264 (can't remember the other one) Also: some libs are so POSIX compliant that, when build via macports on Leopard, they can't be used on Tiger. (lib)xvid is one. I need to build that one manually. Note: I mentioned in a earlier post in this thread that I have # the SDK sysroot to use universal_sysroot /Developer/SDKs/MacOSX10.4u.sdk in my macports.conf. Technically speaking you can just as well use the 10.5 SDK as that one builds for 10.4 too as long as you set the deployment target to 10.4. I choose the 10.4 SDK as quite some packages are not yet 10.5 SDK optimized which led to some errors (pango and gtk). The 10.5 SDK uses some new stuff that works fine on Leopard but not on Tiger as most ports are actually linux based and ported to Mac. Maybe they are already fixed but I did not check yet. Harry ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
On Jan 24, 2009, at 3:36 AM, Ryan Schmidt wrote: On Jan 23, 2009, at 09:11, tim...@rochester.rr.com tim...@rochester.rr.com wrote: Joshua Root j...@macports.org wrote: Timothy Lee wrote: Do you know if its possible for me (on leopard) to build x86 code (all my macports ports) that will also run on Tiger? Short of physical access to an intel 10.4 install, is there anything I can do? Don't forget to use Reply All so the discussion goes to the list as well. There are no guarantees that this will work, but the way to do what you want would be to set universal_target to 10.4, universal_sysroot to /Developer/SDKs/MacOSX10.4u.sdk, and universal_archs to i386. Then build everything with +universal (best to add it to your variants.conf). Also set x11prefix to /usr/X11R6; Leopard's X11 prefix /usr/X11 does not exist on Tiger. If I do this, how will I be able to run the executables on my 10.5 setup? Thanks for the tip! Has anyone tried this? Success/failure stories? openssl failed for me when I tried it this way on Leopard. Switching back to 10.5 and the 10.5 SDK fixed it. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
Timothy Lee wrote: On Jan 24, 2009, at 3:36 AM, Ryan Schmidt wrote: On Jan 23, 2009, at 09:11, tim...@rochester.rr.com tim...@rochester.rr.com wrote: Joshua Root j...@macports.org wrote: Timothy Lee wrote: Do you know if its possible for me (on leopard) to build x86 code (all my macports ports) that will also run on Tiger? Short of physical access to an intel 10.4 install, is there anything I can do? Don't forget to use Reply All so the discussion goes to the list as well. There are no guarantees that this will work, but the way to do what you want would be to set universal_target to 10.4, universal_sysroot to /Developer/SDKs/MacOSX10.4u.sdk, and universal_archs to i386. Then build everything with +universal (best to add it to your variants.conf). Also set x11prefix to /usr/X11R6; Leopard's X11 prefix /usr/X11 does not exist on Tiger. If I do this, how will I be able to run the executables on my 10.5 setup? There's a symlink on at least some Leopard installs. If you don't have one, make one. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
2009/1/24 Timothy Lee tim...@rochester.rr.com Thanks for the reply Harry-I'm fairly sure that I will need to lipo together the builds for Musicbrainz' Picard. So - in your experience what are all the options that I must set after a fresh src install to have a 10.5 setup building binaries for 10.4? Nothing more than setting the right options in your macports.conf and then see how far you get. 2009/1/24 Timothy Lee tim...@rochester.rr.com On Jan 24, 2009, at 3:36 AM, Ryan Schmidt wrote: On Jan 23, 2009, at 09:11, tim...@rochester.rr.com tim...@rochester.rr.com wrote: Joshua Root j...@macports.org wrote: Timothy Lee wrote: Do you know if its possible for me (on leopard) to build x86 code (all my macports ports) that will also run on Tiger? Short of physical access to an intel 10.4 install, is there anything I can do? Don't forget to use Reply All so the discussion goes to the list as well. There are no guarantees that this will work, but the way to do what you want would be to set universal_target to 10.4, universal_sysroot to /Developer/SDKs/MacOSX10.4u.sdk, and universal_archs to i386. Then build everything with +universal (best to add it to your variants.conf). Also set x11prefix to /usr/X11R6; Leopard's X11 prefix /usr/X11 does not exist on Tiger. If I do this, how will I be able to run the executables on my 10.5 setup? I ran into the same issue and simply decided to make links. On Tiger I simply did sudo ln -s /usr/X11R6 /usr/X11. If you build on Tiger and bring them to Leopard you do sudo ln -s /usr/X11 /usr/X11R6. This works only on your own system off course, unless you make an installer that checks whether it runs on Tiger or Leopard and creates a softlink accordingly. Harry ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
Harry- You made reference to adding the -x11 tag to your variants.conf. By doing this, do you force macports to use Apple's X11? Or is it something else entirely different? thanks On Jan 24, 2009, at 12:59 PM, Harry van der Wolf wrote: 2009/1/24 Timothy Lee tim...@rochester.rr.com Thanks for the reply Harry- I'm fairly sure that I will need to lipo together the builds for Musicbrainz' Picard. So - in your experience what are all the options that I must set after a fresh src install to have a 10.5 setup building binaries for 10.4? Nothing more than setting the right options in your macports.conf and then see how far you get. 2009/1/24 Timothy Lee tim...@rochester.rr.com On Jan 24, 2009, at 3:36 AM, Ryan Schmidt wrote: On Jan 23, 2009, at 09:11, tim...@rochester.rr.com tim...@rochester.rr.com wrote: Joshua Root j...@macports.org wrote: Timothy Lee wrote: Do you know if its possible for me (on leopard) to build x86 code (all my macports ports) that will also run on Tiger? Short of physical access to an intel 10.4 install, is there anything I can do? Don't forget to use Reply All so the discussion goes to the list as well. There are no guarantees that this will work, but the way to do what you want would be to set universal_target to 10.4, universal_sysroot to /Developer/SDKs/MacOSX10.4u.sdk, and universal_archs to i386. Then build everything with +universal (best to add it to your variants.conf). Also set x11prefix to /usr/X11R6; Leopard's X11 prefix /usr/X11 does not exist on Tiger. If I do this, how will I be able to run the executables on my 10.5 setup? I ran into the same issue and simply decided to make links. On Tiger I simply did sudo ln -s /usr/X11R6 /usr/X11. If you build on Tiger and bring them to Leopard you do sudo ln -s /usr/X11 /usr/X11R6. This works only on your own system off course, unless you make an installer that checks whether it runs on Tiger or Leopard and creates a softlink accordingly. Harry ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
It is something completely different. Most linux, netbsd and freebsd packages rely on X11. MacOSX has support for x11 but the native windowing system of MacOSX is aqua. Using the -x11 option means that you don't build for X11. An increasing amount of binaries and libraries support native aqua and in that case I don't want to build for X11. It's slower, bigger (X11 takes also memory and resources next to the already available aqua) and ugglier. But the last is off course a matter of taste. Note that some binaries and libraries are still considered beta under aqua (like Gimp) but function very good. If you take a look at openoffice (not macports) you see what I mean. It has already been available for MacOSX in X11 form for a long period. Recently they also released a 3.0 beta version for Aqua which works fine. NeoOffice is an aqua spin-off of OpenOffice and has a native Aqua interface for about 1½ years now. In versioning it runs a bit behind OpenOffice (OOO 3.0.x versus NOO 2.2.5) Note also that some packages that are compiled with -x11, simply miss the X11 gui but only compile/create the command line versions. Harry 2009/1/24 Timothy Lee tim...@rochester.rr.com Harry-You made reference to adding the -x11 tag to your variants.conf. By doing this, do you force macports to use Apple's X11? Or is it something else entirely different? thanks On Jan 24, 2009, at 12:59 PM, Harry van der Wolf wrote: 2009/1/24 Timothy Lee tim...@rochester.rr.com Thanks for the reply Harry-I'm fairly sure that I will need to lipo together the builds for Musicbrainz' Picard. So - in your experience what are all the options that I must set after a fresh src install to have a 10.5 setup building binaries for 10.4? Nothing more than setting the right options in your macports.conf and then see how far you get. 2009/1/24 Timothy Lee tim...@rochester.rr.com On Jan 24, 2009, at 3:36 AM, Ryan Schmidt wrote: On Jan 23, 2009, at 09:11, tim...@rochester.rr.com tim...@rochester.rr.com wrote: Joshua Root j...@macports.org wrote: Timothy Lee wrote: Do you know if its possible for me (on leopard) to build x86 code (all my macports ports) that will also run on Tiger? Short of physical access to an intel 10.4 install, is there anything I can do? Don't forget to use Reply All so the discussion goes to the list as well. There are no guarantees that this will work, but the way to do what you want would be to set universal_target to 10.4, universal_sysroot to /Developer/SDKs/MacOSX10.4u.sdk, and universal_archs to i386. Then build everything with +universal (best to add it to your variants.conf). Also set x11prefix to /usr/X11R6; Leopard's X11 prefix /usr/X11 does not exist on Tiger. If I do this, how will I be able to run the executables on my 10.5 setup? I ran into the same issue and simply decided to make links. On Tiger I simply did sudo ln -s /usr/X11R6 /usr/X11. If you build on Tiger and bring them to Leopard you do sudo ln -s /usr/X11 /usr/X11R6. This works only on your own system off course, unless you make an installer that checks whether it runs on Tiger or Leopard and creates a softlink accordingly. Harry ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
Hmm.. thats interesting. So, does that imply that aqua provides a X11-like API (w/ libs) or does that mean that the actual people writing packages (like openoffice) need to support aqua calls conditionally compiled in on detection of the aqua include/libs? thanks On Jan 24, 2009, at 1:25 PM, Harry van der Wolf wrote: It is something completely different. Most linux, netbsd and freebsd packages rely on X11. MacOSX has support for x11 but the native windowing system of MacOSX is aqua. Using the -x11 option means that you don't build for X11. An increasing amount of binaries and libraries support native aqua and in that case I don't want to build for X11. It's slower, bigger (X11 takes also memory and resources next to the already available aqua) and ugglier. But the last is off course a matter of taste. Note that some binaries and libraries are still considered beta under aqua (like Gimp) but function very good. If you take a look at openoffice (not macports) you see what I mean. It has already been available for MacOSX in X11 form for a long period. Recently they also released a 3.0 beta version for Aqua which works fine. NeoOffice is an aqua spin-off of OpenOffice and has a native Aqua interface for about 1½ years now. In versioning it runs a bit behind OpenOffice (OOO 3.0.x versus NOO 2.2.5) Note also that some packages that are compiled with -x11, simply miss the X11 gui but only compile/create the command line versions. Harry 2009/1/24 Timothy Lee tim...@rochester.rr.com Harry- You made reference to adding the -x11 tag to your variants.conf. By doing this, do you force macports to use Apple's X11? Or is it something else entirely different? thanks On Jan 24, 2009, at 12:59 PM, Harry van der Wolf wrote: 2009/1/24 Timothy Lee tim...@rochester.rr.com Thanks for the reply Harry- I'm fairly sure that I will need to lipo together the builds for Musicbrainz' Picard. So - in your experience what are all the options that I must set after a fresh src install to have a 10.5 setup building binaries for 10.4? Nothing more than setting the right options in your macports.conf and then see how far you get. 2009/1/24 Timothy Lee tim...@rochester.rr.com On Jan 24, 2009, at 3:36 AM, Ryan Schmidt wrote: On Jan 23, 2009, at 09:11, tim...@rochester.rr.com tim...@rochester.rr.com wrote: Joshua Root j...@macports.org wrote: Timothy Lee wrote: Do you know if its possible for me (on leopard) to build x86 code (all my macports ports) that will also run on Tiger? Short of physical access to an intel 10.4 install, is there anything I can do? Don't forget to use Reply All so the discussion goes to the list as well. There are no guarantees that this will work, but the way to do what you want would be to set universal_target to 10.4, universal_sysroot to /Developer/SDKs/MacOSX10.4u.sdk, and universal_archs to i386. Then build everything with +universal (best to add it to your variants.conf). Also set x11prefix to /usr/X11R6; Leopard's X11 prefix /usr/X11 does not exist on Tiger. If I do this, how will I be able to run the executables on my 10.5 setup? I ran into the same issue and simply decided to make links. On Tiger I simply did sudo ln -s /usr/X11R6 /usr/X11. If you build on Tiger and bring them to Leopard you do sudo ln -s /usr/X11 /usr/X11R6. This works only on your own system off course, unless you make an installer that checks whether it runs on Tiger or Leopard and creates a softlink accordingly. Harry ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
It's definitely not the first. I assume they added code to support aqua and it's API's. I'm not a developer. just google for answers :) Harry 2009/1/24 Timothy Lee tim...@rochester.rr.com Hmm.. thats interesting.So, does that imply that aqua provides a X11-like API (w/ libs) or does that mean that the actual people writing packages (like openoffice) need to support aqua calls conditionally compiled in on detection of the aqua include/libs? thanks On Jan 24, 2009, at 1:25 PM, Harry van der Wolf wrote: It is something completely different. Most linux, netbsd and freebsd packages rely on X11. MacOSX has support for x11 but the native windowing system of MacOSX is aqua. Using the -x11 option means that you don't build for X11. An increasing amount of binaries and libraries support native aqua and in that case I don't want to build for X11. It's slower, bigger (X11 takes also memory and resources next to the already available aqua) and ugglier. But the last is off course a matter of taste. Note that some binaries and libraries are still considered beta under aqua (like Gimp) but function very good. If you take a look at openoffice (not macports) you see what I mean. It has already been available for MacOSX in X11 form for a long period. Recently they also released a 3.0 beta version for Aqua which works fine. NeoOffice is an aqua spin-off of OpenOffice and has a native Aqua interface for about 1½ years now. In versioning it runs a bit behind OpenOffice (OOO 3.0.x versus NOO 2.2.5) Note also that some packages that are compiled with -x11, simply miss the X11 gui but only compile/create the command line versions. Harry 2009/1/24 Timothy Lee tim...@rochester.rr.com Harry-You made reference to adding the -x11 tag to your variants.conf. By doing this, do you force macports to use Apple's X11? Or is it something else entirely different? thanks On Jan 24, 2009, at 12:59 PM, Harry van der Wolf wrote: 2009/1/24 Timothy Lee tim...@rochester.rr.com Thanks for the reply Harry- I'm fairly sure that I will need to lipo together the builds for Musicbrainz' Picard. So - in your experience what are all the options that I must set after a fresh src install to have a 10.5 setup building binaries for 10.4? Nothing more than setting the right options in your macports.conf and then see how far you get. 2009/1/24 Timothy Lee tim...@rochester.rr.com On Jan 24, 2009, at 3:36 AM, Ryan Schmidt wrote: On Jan 23, 2009, at 09:11, tim...@rochester.rr.com tim...@rochester.rr.com wrote: Joshua Root j...@macports.org wrote: Timothy Lee wrote: Do you know if its possible for me (on leopard) to build x86 code (all my macports ports) that will also run on Tiger? Short of physical access to an intel 10.4 install, is there anything I can do? Don't forget to use Reply All so the discussion goes to the list as well. There are no guarantees that this will work, but the way to do what you want would be to set universal_target to 10.4, universal_sysroot to /Developer/SDKs/MacOSX10.4u.sdk, and universal_archs to i386. Then build everything with +universal (best to add it to your variants.conf). Also set x11prefix to /usr/X11R6; Leopard's X11 prefix /usr/X11 does not exist on Tiger. If I do this, how will I be able to run the executables on my 10.5 setup? I ran into the same issue and simply decided to make links. On Tiger I simply did sudo ln -s /usr/X11R6 /usr/X11. If you build on Tiger and bring them to Leopard you do sudo ln -s /usr/X11 /usr/X11R6. This works only on your own system off course, unless you make an installer that checks whether it runs on Tiger or Leopard and creates a softlink accordingly. Harry ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
Exact same settings as below (except I'm only building i386), yet I'm still seeing DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.5'. Any Ideas? Also - I'm seeing Warning: Please fix or indicate this misbehavior (if it is intended) on every install saying that /mopt/local/bin is in violation - any ideas on this? thanks On Jan 23, 2009, at 9:14 AM, Harry van der Wolf wrote: Hi, I've setup my MacPorts 1.7 to always build universal (does not always work and sometimes needs a manual change of the Portfile). To do this I configured in the macports.conf the following: # Options for Universal Binaries (+universal variant) # MACOSX_DEPLOYMENT_TARGET universal_target10.4 # the SDK sysroot to use universal_sysroot /Developer/SDKs/MacOSX10.4u.sdk # machine architectures universal_archs ppc i386 and in variants.conf: +universal Harry 2009/1/23 Joshua Root j...@macports.org Timothy Lee wrote: Hey Joshua- Thanks for the reply. Do you know if its possible for me (on leopard) to build x86 code (all my macports ports) that will also run on Tiger? Short of physical access to an intel 10.4 install, is there anything I can do? Don't forget to use Reply All so the discussion goes to the list as well. There are no guarantees that this will work, but the way to do what you want would be to set universal_target to 10.4, universal_sysroot to /Developer/SDKs/MacOSX10.4u.sdk, and universal_archs to i386. Then build everything with +universal (best to add it to your variants.conf). - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
On Jan 24, 2009, at 14:01, Timothy Lee wrote: Exact same settings as below (except I'm only building i386), yet I'm still seeing DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.5'. Any Ideas? Only building i386 -- does that mean you are not using the +universal variant? If so, the universal_target setting is not used, as I believe Josh mentioned earlier in this thread. Also - I'm seeing Warning: Please fix or indicate this misbehavior (if it is intended) on every install saying that / mopt/local/bin is in violation - any ideas on this? Did you have a slash at the end of your --prefix when you configured -- i.e. ./configure --prefix=/mopt/local/bin/? If so, reconfigure and omit the slash at the end -- i.e. ./configure --prefix=/mopt/ local/bin (and then of course make and sudo make install). This will be fixed in MacPorts 1.8.0. http://trac.macports.org/ticket/13789 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
Ryan Schmidt wrote: On Jan 22, 2009, at 21:59, Timothy Lee wrote: I just compile 1.7.0 from source and my macports.conf universal_target has a 10.4 next to it. However, when I compile on my Leopard machine, I see DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.5'. I thought universal_targe would set the MACOSX_DEPLOYMENT_TARGET. Am I wrong? universal_target is what is used to fill the MACOSX_DEPLOYMENT_TARGET variable. MacPorts should be setting this by default to whatever is right for the current OS: 10.3 on 10.3, 10.4 on 10.4, 10.5 on 10.5. If the macports.conf has this setting listed, then that overrides the default behavior. Not quite. It uses universal_target when the universal variant is selected, otherwise it uses a variable called macosx_deployment_target, which can be changed from portfiles but not from macports.conf. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
Timothy Lee wrote: Hey Joshua- Thanks for the reply. Do you know if its possible for me (on leopard) to build x86 code (all my macports ports) that will also run on Tiger? Short of physical access to an intel 10.4 install, is there anything I can do? Don't forget to use Reply All so the discussion goes to the list as well. There are no guarantees that this will work, but the way to do what you want would be to set universal_target to 10.4, universal_sysroot to /Developer/SDKs/MacOSX10.4u.sdk, and universal_archs to i386. Then build everything with +universal (best to add it to your variants.conf). - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
Hi, I've setup my MacPorts 1.7 to always build universal (does not always work and sometimes needs a manual change of the Portfile). To do this I configured in the macports.conf the following: # Options for Universal Binaries (+universal variant) # MACOSX_DEPLOYMENT_TARGET universal_target10.4 # the SDK sysroot to use universal_sysroot /Developer/SDKs/MacOSX10.4u.sdk # machine architectures universal_archs ppc i386 and in variants.conf: +universal Harry 2009/1/23 Joshua Root j...@macports.org Timothy Lee wrote: Hey Joshua- Thanks for the reply. Do you know if its possible for me (on leopard) to build x86 code (all my macports ports) that will also run on Tiger? Short of physical access to an intel 10.4 install, is there anything I can do? Don't forget to use Reply All so the discussion goes to the list as well. There are no guarantees that this will work, but the way to do what you want would be to set universal_target to 10.4, universal_sysroot to /Developer/SDKs/MacOSX10.4u.sdk, and universal_archs to i386. Then build everything with +universal (best to add it to your variants.conf). - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
Thanks for the tip! Has anyone tried this? Success/failure stories? Joshua Root j...@macports.org wrote: Timothy Lee wrote: Hey Joshua- Thanks for the reply. Do you know if its possible for me (on leopard) to build x86 code (all my macports ports) that will also run on Tiger? Short of physical access to an intel 10.4 install, is there anything I can do? Don't forget to use Reply All so the discussion goes to the list as well. There are no guarantees that this will work, but the way to do what you want would be to set universal_target to 10.4, universal_sysroot to /Developer/SDKs/MacOSX10.4u.sdk, and universal_archs to i386. Then build everything with +universal (best to add it to your variants.conf). - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
On Jan 21, 2009, at 19:22, Timothy Lee wrote: Hi Macports people! Two questions: 1. What is the current state of the +universal variant? Do most ports work? Not all ports do, but many do. gimp and inkscape do, for instance... If something doesn't work for you, file a bug. I think it's mostly usable now. 2. How is dependencies and the +universal variants used? Meaning if I type sudo port install pan2 +universal will that pass the variant to all dependencies that get built before pan2? It's probably best to start from scratch and put it in your $prefix/ etc/macports/variants.conf MacPorts doesn't support variants in dependencies ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
On Jan 21, 2009, at 21:22, Timothy Lee wrote: 1. What is the current state of the +universal variant? Do most ports work? It's unknown if most ports work. If it doesn't work for ports you want, file tickets. Note that 64-bit universal support is likely more broken than plain 32-bit universal support. It's possible we could fix this situation a great deal by switching ports to the new universal build strategy available in the merge- universal portgroup. 2. How is dependencies and the +universal variants used? Meaning if I type sudo port install pan2 +universal will that pass the variant to all dependencies that get built before pan2? Yes, as with all variants, the variants you ask for will get passed down to any other port that needs to get *installed* (but not to any other port that's needed that you already have installed). If you want to install X universal, and X depends on Y and Z, and Y and/or Z are already installed, you must ensure that Y and Z are already universal, otherwise you will get (possibly cryptic) errors installing X universal. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
I just compile 1.7.0 from source and my macports.conf universal_target has a 10.4 next to it. However, when I compile on my Leopard machine, I see DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.5'. I thought universal_targe would set the MACOSX_DEPLOYMENT_TARGET. Am I wrong? On Jan 22, 2009, at 4:19 AM, Ryan Schmidt wrote: On Jan 21, 2009, at 21:22, Timothy Lee wrote: 1. What is the current state of the +universal variant? Do most ports work? It's unknown if most ports work. If it doesn't work for ports you want, file tickets. Note that 64-bit universal support is likely more broken than plain 32-bit universal support. It's possible we could fix this situation a great deal by switching ports to the new universal build strategy available in the merge- universal portgroup. 2. How is dependencies and the +universal variants used? Meaning if I type sudo port install pan2 +universal will that pass the variant to all dependencies that get built before pan2? Yes, as with all variants, the variants you ask for will get passed down to any other port that needs to get *installed* (but not to any other port that's needed that you already have installed). If you want to install X universal, and X depends on Y and Z, and Y and/or Z are already installed, you must ensure that Y and Z are already universal, otherwise you will get (possibly cryptic) errors installing X universal. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal Binaries
On Jan 22, 2009, at 21:59, Timothy Lee wrote: I just compile 1.7.0 from source and my macports.conf universal_target has a 10.4 next to it. However, when I compile on my Leopard machine, I see DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.5'. I thought universal_targe would set the MACOSX_DEPLOYMENT_TARGET. Am I wrong? universal_target is what is used to fill the MACOSX_DEPLOYMENT_TARGET variable. MacPorts should be setting this by default to whatever is right for the current OS: 10.3 on 10.3, 10.4 on 10.4, 10.5 on 10.5. If the macports.conf has this setting listed, then that overrides the default behavior. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Universal Binaries
Hi Macports people! Two questions: 1. What is the current state of the +universal variant? Do most ports work? 2. How is dependencies and the +universal variants used? Meaning if I type sudo port install pan2 +universal will that pass the variant to all dependencies that get built before pan2? Thanks! Tim ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
universal binaries seems difficult
Creating portfiles/Makefiles for universal binary builds seems not so easy. Example: port install zlib -universal produces a fat ppc/i386 library on a ppc machine, while it produces non-fat i386 library on an intel platform. port install freetype -universal produces non-fat i386 libraries on an intel mac, while the installation stops with errors on a ppc mac. port install rxvt -universal produces a non-fat i386 executable on an intel mac and a non-fat ppc executable on a ppc mac. Is this the rule, that the MacPort -universal directive is ignored or has unpredictable results for most ports? ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: universal binaries seems difficult
On Aug 9, 2007, at 07:35, Bengt Nilsson wrote: Creating portfiles/Makefiles for universal binary builds seems not so easy. The problem is you are using a minus sign when you need to use a plus sign. The minus sign *deselects* a variant, while the plus sign selects it. You want sudo port install zlib +universal (to select the universal variant) rather than sudo port install zlib - universal (which deselects the universal variant, which has no effect, because the universal variant is deselected by default). Example: port install zlib -universal produces a fat ppc/i386 library on a ppc machine, while it produces non-fat i386 library on an intel platform. zlib builds just fine universal on my MacBook Pro (if you say +universal instead of -universal). $ port installed zlib The following ports are currently installed: zlib @1.2.3_1+universal (active) $ file /opt/local/lib/libz.1.2.3.dylib /opt/local/lib/libz.1.2.3.dylib: Mach-O universal binary with 2 architectures /opt/local/lib/libz.1.2.3.dylib (for architecture i386):Mach- O dynamically linked shared library i386 /opt/local/lib/libz.1.2.3.dylib (for architecture ppc): Mach-O dynamically linked shared library ppc $ uname -a Darwin seven.local 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 i386 i386 $ port install freetype -universal produces non-fat i386 libraries on an intel mac, while the installation stops with errors on a ppc mac. I have a report from you and one other individual that universal installation of freetype did not work on a PowerPC. I have other reports that universal installation of freetype does work on PowerPC. It does work for me on Intel: $ port installed freetype The following ports are currently installed: freetype @2.3.5_0+doc+universal (active) $ file /opt/local/lib/libfreetype.6.3.16.dylib /opt/local/lib/libfreetype.6.3.16.dylib: Mach-O universal binary with 2 architectures /opt/local/lib/libfreetype.6.3.16.dylib (for architecture i386):Mach-O dynamically linked shared library i386 /opt/local/lib/libfreetype.6.3.16.dylib (for architecture ppc): Mach- O dynamically linked shared library ppc $ Of course, freetype depends on zlib, so if you have not built the zlib port universal, then you will not be able to build the freetype port universal either. port install rxvt -universal produces a non-fat i386 executable on an intel mac and a non-fat ppc executable on a ppc mac. I'm not familiar with rxvt, but it seems to build universal just fine. rxvt depends on freetype, so you will need freetype and its dependencies (zlib) built universal first. $ sudo port install rxvt +universal Password: --- Fetching rxvt --- Attempting to fetch rxvt-2.7.10.tar.gz from http:// downloads.sourceforge.net/rxvt --- Verifying checksum(s) for rxvt --- Extracting rxvt --- Configuring rxvt --- Building rxvt with target all --- Staging rxvt into destroot --- Installing rxvt 2.7.10_1+universal --- Activating rxvt 2.7.10_1+universal --- Cleaning rxvt $ port contents rxvt Port rxvt contains: /opt/local/bin/rclock /opt/local/bin/rxvt /opt/local/bin/rxvt-2.7.10 /opt/local/share/man/man1/rclock.1.gz /opt/local/share/man/man1/rxvt.1.gz $ file /opt/local/bin/rclock /opt/local/bin/rclock: Mach-O universal binary with 2 architectures /opt/local/bin/rclock (for architecture i386): Mach-O executable i386 /opt/local/bin/rclock (for architecture ppc): Mach-O executable ppc $ file /opt/local/bin/rxvt /opt/local/bin/rxvt: Mach-O universal binary with 2 architectures /opt/local/bin/rxvt (for architecture i386):Mach-O executable i386 /opt/local/bin/rxvt (for architecture ppc): Mach-O executable ppc $ Is this the rule, that the MacPort -universal directive is ignored or has unpredictable results for most ports? The universal variant is made available to all ports. It should work with many of them. It will fail for many others. For each port where it fails, the port will need to be fixed. This is in the FAQ: http://trac.macosforge.org/projects/macports/wiki/ FAQ#IsMacPortsUniversal ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Universal Binaries
I think you're starting with a fundamental premise that Universal binaries are something of an optional frill (and that they somehow use more memory than non-universal ones) - neither statement is, unfortunately, true. First, you have to remember that even people who build all their own bits are still going to run into scenarios where the bits they build on MachineA would be useful on MachineB and they'd rather just copy a tree over than wait multiple hours for something like KDE or xemacs to build from scratch every single time they want it on a new machine (and even if you only own a single machine, eventually you're going to come up against the upgrade case where Migration Assistant will helpfully copy all your old bits, including /opt, onto the new machine and do you really want to run all your MacPorts stuff under Rosetta?). Right now, the large majority of Mac users are still using PPC machines (consider the installed base) but this balance is tipping more and more every day as the Mac installed base actually expands and enjoys a rate of growth far in excess of traditional PC market growth (yay). Building universal as a DEFAULT position means that this change is essentially painless as people switch machines, get new machines to slide next to existing ones, and so on. Yes, it's a fair amount of pain for us, the producers of MacPorts, but that's just the nature of the beast - developers are accustomed to suffering pain once so that end-users do not have to suffer it multiple times. :-) At Apple, we build everything universal and that includes a LOT of open source. It's sometimes a bit of a pain to beat it into compliance, but surprisingly not all that much pain. Second, universal binaries do NOT use more memory than non-universal ones. They take up a little more space on disk, but only the bits relevant to your architecture are actually loaded into memory. What DOES take a lot more memory is running PPC binaries under Rosetta, which essentially needs to translate and cache the results of code morphing on the fly. - Jordan On Feb 23, 2007, at 10:23 AM, Altoine Barker wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm reading up on universal binaries and such now. I see your point but I think it should be an option or flag that you can choose for any particular port and not default for all ports, unless, an option to choose to the contrary is selected to address memory space issues. I see a need for what you are talking about and I desire such functionality with the idea environment, which I do not have but you do. I would like to sign up for such a cause, except, I am trying to get a few of my own projects to the point where I would then need to look at macports providing universal binary support. I think the premise of macports is to be self-supporting without bloat for those that seek such a feature. I agree for an enhanced macports that has that as an option and not default. Since most open source code is written to be cross-platform, there shouldn't be too many problems. Alot of work, but not too many problems. Of course, an ability to choose the location of or a default one created (i.e. /opt/local/universal) You wouldn't want to put it under /System/Library/Frameworks since an update may flush your universal ports. My $0.02. - -Altoine P.S. On further reading, I see it being possible. I just am not at that point in my goals to incorporate that task. I am more than available to test but I can not start or join such an endeavor until I finish a few that I have now. Jordan K. Hubbard wrote: Is that one of them-there rhetorical questions? :-) There are lots of good reasons to want universal binaries. For one, it allows you to NFS/AFP/... share a single /opt/local among machines (who says that directory always has to be local?) without having to worry about which architecture those machines are. It also allows you to archive up a carefully built-up /opt/local (+ /Applications/ DarwinPorts) and give it to other people, of course. Finally, perhaps the best reason for building universal is the eventual (any year now, I'm sure, and almost certainly by the next millennium) move to releasing packaged versions of MacPorts software, complete with dependency tracking. You don't want to have 2 sets of packages (assuming that only 32 bit ABIs are important) in what would eventually be a multi-thousand package archive. Universal Binaries are definitely the way forward on the Mac and porters should be encouraged to shoot for them as the rule rather than the exception. If disk space is a problem for any of the targets (and it's not that big an increase), they can always be thinned post-install time. - Jordan On Feb 23, 2007, at 7:35 AM, Kevin Ballard wrote: I'm curious as to why you want universal binaries. In general, binaries produced via MacPorts can't be copied
Re: Universal Binaries
On Feb 23, 2007, at 11:36 AM, Ryan Schmidt wrote: Now, what we could think about doing is providing some kind of default, where +universal would use the standard CFLAGS, LDFLAGS and --disable-dependency-tracking, unless the port itself defines a +universal variant. This would allow many ports to build universal. However, those for which is doesn't would then be broken. Either building with +universal would cause compilation or configuration errors, which the user could then report to the maintainer, or the software would seem to compile and build properly, but then not actually run properly on the non-native architecture. It's hard to know until you try it, separately for each software package. I think this is a good idea. Yes, software will break, but if you make it a goal to build everything universal, it will also quickly get fixed and then you're over the hump and don't have to think about it anymore. Getting this done will also make the 32-64 bit Intel shift easier to deal with since you want to build i386/x86_64 versions universal as well (running apps as 64 bit on Core2 Duo systems is starting to become more attractive due to the extra registers you get and, of course, the larger address space). That's probably not a short-term goal, but it's somewhere on the horizon and this is one more step in the right direction. As I said before, Apple has already gone through this for hundreds of apps and it's not as painful as many people think. A consistent build harness like MacPorts makes it even easier, since you can deal with issues like broken configure scripts (which make static determinations of endian-ness or arch) by post-processing their output before starting the build phase. - Jordan ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Universal Binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jordan, I did not intend for it to be viewed as a optional frill, but more an option in the sense that the no-option choice is for the single user and the optional choice is for people with either both architectures or developers of products for both architectures. Maybe the /opt/local/universal is a stretch, but I meant for that path to be reserved for the software developer/multi-architecture users. As far as memory issues, yes, I was referring to hard drive space and not RAM memory. Myself, I have to have an external drive to do most of the development that I like to do because I am into a lot of geek-ary. I make remastered wedding videos from VHS or whatever format that is brought to me and make nice menu driven dvd videos. That takes alot of space which leaves me having to get creative with how I manage my hard drive space for on the go using my notebook. I have my setup like this. Both development environments are stored on my external hard drive (400GB) with their own partitions. When I am leaving for awhile, I have to consider what project I will be doing the most on the go and what projects I can not do with out. So, I sync between the partitions what I need from both and go. I have a 60GB internal hard drive with 11GB of free space with mostly my software development kits from subversion, cvs, git, rsync, and whatever means available. 11GB is not a whole lot of real estate when you are working with video and photo editing. Other than that, I would love for universal to be default. But since that isn't my situation, I want the option to choose. - -Altoine Jordan K. Hubbard wrote: I think you're starting with a fundamental premise that Universal binaries are something of an optional frill (and that they somehow use more memory than non-universal ones) - neither statement is, unfortunately, true. First, you have to remember that even people who build all their own bits are still going to run into scenarios where the bits they build on MachineA would be useful on MachineB and they'd rather just copy a tree over than wait multiple hours for something like KDE or xemacs to build from scratch every single time they want it on a new machine (and even if you only own a single machine, eventually you're going to come up against the upgrade case where Migration Assistant will helpfully copy all your old bits, including /opt, onto the new machine and do you really want to run all your MacPorts stuff under Rosetta?). Right now, the large majority of Mac users are still using PPC machines (consider the installed base) but this balance is tipping more and more every day as the Mac installed base actually expands and enjoys a rate of growth far in excess of traditional PC market growth (yay). Building universal as a DEFAULT position means that this change is essentially painless as people switch machines, get new machines to slide next to existing ones, and so on. Yes, it's a fair amount of pain for us, the producers of MacPorts, but that's just the nature of the beast - developers are accustomed to suffering pain once so that end-users do not have to suffer it multiple times. :-) At Apple, we build everything universal and that includes a LOT of open source. It's sometimes a bit of a pain to beat it into compliance, but surprisingly not all that much pain. Second, universal binaries do NOT use more memory than non-universal ones. They take up a little more space on disk, but only the bits relevant to your architecture are actually loaded into memory. What DOES take a lot more memory is running PPC binaries under Rosetta, which essentially needs to translate and cache the results of code morphing on the fly. - Jordan On Feb 23, 2007, at 10:23 AM, Altoine Barker wrote: I'm reading up on universal binaries and such now. I see your point but I think it should be an option or flag that you can choose for any particular port and not default for all ports, unless, an option to choose to the contrary is selected to address memory space issues. I see a need for what you are talking about and I desire such functionality with the idea environment, which I do not have but you do. I would like to sign up for such a cause, except, I am trying to get a few of my own projects to the point where I would then need to look at macports providing universal binary support. I think the premise of macports is to be self-supporting without bloat for those that seek such a feature. I agree for an enhanced macports that has that as an option and not default. Since most open source code is written to be cross-platform, there shouldn't be too many problems. Alot of work, but not too many problems. Of course, an ability to choose the location of or a default one created (i.e. /opt/local/universal) You wouldn't want to put it under /System/Library/Frameworks since an update may flush your universal ports. My $0.02
Re: Universal Binaries
On Feb 23, 2007, at 5:21 PM, Altoine Barker wrote: Jordan, I did not intend for it to be viewed as a optional frill, but more an option in the sense that the no-option choice is for the single user and the optional choice is for people with either both architectures or developers of products for both architectures. Maybe the /opt/local/universal is a stretch [ ] Well, the beauty(?) of Universal binaries is that there doesn't need to be any special place for them to go - you just install them where you always installed them and everything Just Works™. If it's not transparent to the user, there's really not much point. Your other concerns seem to largely revolve around disk space and having enough room for your wedding videos. I guess I'm curious to know how much extra space you're thinking these universal binaries will take? Don't forget, you're not replicating all the Resource directories or the Data and symbol table sections of all these Mach-O binaries, simply the text sections. I also don't expect any of what I'm suggesting to affect the storage of your external drive, where your wedding videos are, unless you're going out of your way to put /opt/local on that firewire/USB drive as well, in which case I still suspect that the relative size increase would be dwarfed by even the smallest, shortest wedding video in history (You want him? ``Yes.'' You want her? ``Yowza!''. Good, done, we're outta here - these tuxes were rented by the hour, people, so let's MOVE! Reception is at the Taco Bell drive-through after everyone gets changed! video ends) - Jordan ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Universal Binaries
On Feb 22, 2007, at 02:35, Nathan Brazil wrote: Hi. Is it possible to produce universal binaries from MacPorts? For example, are the GTK+ binaries produced from MacPorts specific to the architecture of the machine it is produced on (PPC vs Intel), or is there a way to produce binaries that will work natively on both? MacPorts produces platform-native binaries. There is no way to produce universal binaries. For many projects, it is a simple matter to produce universal binaries. However, some projects need to be handled specially, so MacPorts cannot provide a guaranteed way of automatically building universal binaries of all software. A very few ports provide a +universal variant. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
