foo-append working with merger in muniversal?

[Michael Dickens]

Hi Ned - Thanks you for your thoughts and comments.  Some "brief" answers; I'll post a follow-up later today (hopefully this morning in US/ET), since I've figured out a way to get this port to build +universal now, which I think is reasonably backwards-compatible yet reasonably generic.

I think you are correct that Apple's GCC is the only GCC variant that will produce "universal" binaries, by using multiple -arch flags.  My comment about 'installed gcc4[3-5] do not honor "-m32 -m64" at the same time' was not meant to imply that this is a bug in non-Apple GCC; it's just the way GCC (Apple or not) works.

When I talk about merging files, it's a term used by the "muniversal" portgroup.  What this group does is to create a build directory for each arch type (e.g., one each for i386 and x86_64), do the builds independently of each other, destroot each to its own directory, then use Apple's '/usr/bin/lipo' to join binaries into a "universal" file.  For files that are -not- binary joinable by lipo, the "muniversal" file uses various "if" and "switch" logic to determine whether or not the files to be joined are either already identical or differ trivially (e.g., a timestamp) -- in which case only one of the two is chosen and copied over (no merging).  Some binary files that meet this criteria are JAR, ELC, GZ, and BZ2 -- some of these can be "expanded" and then compared, while others are just assumed to be platform independent.  Adding in PYC files to this list is what I am proposing, since, as you say, they are platform independent -- and, in my testing vary trivially: solely by a timestamp (or something like that).

As I discuss above, the "muniversal" portgroup roughly recreates what Apple has done for GCC by adding the option for multiple -arch flags -- so, yes, MacPorts can use vanilla GCC to create universal binaries, and I'm sure it was a significant undertaking.  If you look at the file (for me, using the SVN trunk, it's at "dports/_resources/port1.0/group/muniversal-1.0.tcl", it's pretty extensive and exhaustive, yet generic, in how it goes about dividing up the configuring, building, and merging for different arch's.

I use MacPorts for anything I can, so I really don't know what the NumPy project provides -- 32-bit only or whatever.  I do remember there was a version of NumPy a while back that broke when compiled as 64-bit, but fixes were made and the release compiles as 32 or 64 bit now.  NumPy itself is set up to compile on OSX as universal when using Apple's GCC, but for whatever reason the MacPorts' version chooses to use the vanilla GCC & hence tricks are required to get a universal install.

I've never personally tried a mixed 32/64 bit Python library install, but since Python must use 'dlopen' for libraries, it should work so long as the bittage of all necessary installed compiled libraries match up (e.g., all provide 64-bit binaries).  I will certainly test this theory out before proposing or committing any such changes. - MLD