More thoughts on Universal Binaries
3 views
Skip to first unread message
Kevin Barry
Jan 27, 2010, 7:02:31 PM1/27/10
to arch...@googlegroups.com
Hello all,
So we've talked a bit about 64bit binaries but haven't done much with them yet. I'm hoping to change that but have some concerns. Status update first:
There are 2 ways of creating a universal binary. You can compile it with gcc -arch i386 -arch x86_64, or you can use the lipo tool to create a new binary from multiple inputs of different types. Though the gcc flag method seems nicer, it's really fragile with unix Makefiles and would require significantly more complex PKGBUILDs for most packages. So I propose using the latter method.
I've created a makepkg_uni script which builds a 32 bit package, then a 64 bit package, then lipo's all the files it can. The ones it can't it checks their md5s to see if they have different content. If they do it warns the user. There's a few reason they might:
1) Include files to be installed might have #define IS_64BIT or similar which obviously is different. Include files are easy as I just created an include64 directory which is prefixed for 64 bit makepkg but not for 32bit.
2) Include time they were generated. .PKGINFO is one such an example. Not a big deal.
3) I'm sure there are other problems we'll encounter. That's what the warning is for.
Currently makepkg_uni runs without requiring modifying the PKGBUILD. I'll see if I run into problems as I build more packages.
The makepkg_uni script uses 2 makepkg.conf files, one for each architecture. My original plan was to have 32-bit be 10.5 compatible and 64 bit 10.6 only, even though leopard is capable of 64-bit we might get some advantage of dropping support for it. However this doesn't seem to be easy to do. If a universal binary contains a 32-bit 10.5 binary and a 64-bit 10.6 binary, Leopard will still try to run the 10.6 binary. It looks like this can be handled for ".app" bundles, but not via the command line. Hard to google this so I'd appreciate someone else looking into it. Here's what I found:
http://lists.apple.com/archives/xcode-users/2010/Jan/msg00342.html
What that means is if we want to distribute universal binaries we should ship them as 10.5 i386 and 10.5 x86_64 and they will run on Leopard or Snow Leopard and 32-bit or 64-bit processors.
Another option would be to support macx86 and macx86_64 separately. Or even have macuni in the mix too. And/or mac105x86 vs mac106x86_64.
Though i like the idea of having 10.6 binaries, I don't think having multiple binaries is a good idea at this time, too much maintenance for our small team.
Thoughts?
Also what is everyone here running, 10.5 or 10.6? i386 or x86_64?
So we've talked a bit about 64bit binaries but haven't done much with them yet. I'm hoping to change that but have some concerns. Status update first:
There are 2 ways of creating a universal binary. You can compile it with gcc -arch i386 -arch x86_64, or you can use the lipo tool to create a new binary from multiple inputs of different types. Though the gcc flag method seems nicer, it's really fragile with unix Makefiles and would require significantly more complex PKGBUILDs for most packages. So I propose using the latter method.
I've created a makepkg_uni script which builds a 32 bit package, then a 64 bit package, then lipo's all the files it can. The ones it can't it checks their md5s to see if they have different content. If they do it warns the user. There's a few reason they might:
1) Include files to be installed might have #define IS_64BIT or similar which obviously is different. Include files are easy as I just created an include64 directory which is prefixed for 64 bit makepkg but not for 32bit.
2) Include time they were generated. .PKGINFO is one such an example. Not a big deal.
3) I'm sure there are other problems we'll encounter. That's what the warning is for.
Currently makepkg_uni runs without requiring modifying the PKGBUILD. I'll see if I run into problems as I build more packages.
The makepkg_uni script uses 2 makepkg.conf files, one for each architecture. My original plan was to have 32-bit be 10.5 compatible and 64 bit 10.6 only, even though leopard is capable of 64-bit we might get some advantage of dropping support for it. However this doesn't seem to be easy to do. If a universal binary contains a 32-bit 10.5 binary and a 64-bit 10.6 binary, Leopard will still try to run the 10.6 binary. It looks like this can be handled for ".app" bundles, but not via the command line. Hard to google this so I'd appreciate someone else looking into it. Here's what I found:
http://lists.apple.com/archives/xcode-users/2010/Jan/msg00342.html
What that means is if we want to distribute universal binaries we should ship them as 10.5 i386 and 10.5 x86_64 and they will run on Leopard or Snow Leopard and 32-bit or 64-bit processors.
Another option would be to support macx86 and macx86_64 separately. Or even have macuni in the mix too. And/or mac105x86 vs mac106x86_64.
Though i like the idea of having 10.6 binaries, I don't think having multiple binaries is a good idea at this time, too much maintenance for our small team.
Thoughts?
Also what is everyone here running, 10.5 or 10.6? i386 or x86_64?
Reply all
Reply to author
Forward
0 new messages