A PortGroup for building more 32/64-bit universal packages

[robert delius royar]

Thu, 22 Jan 2009 (06:31 -0600 UTC) Ryan Schmidt wrote:

> zlib uses a post-configure phase to insert the ${configure.universal_cflags} 
> into the Makefile in the right place. With merge-universal, the universal 
> CFLAGS change for each arch. Does merge-universal call the post-configure 
> procedure once for each arch with the correct value of 
> ${configure.universal_cflags} and ${worksrcpath} for that arch? I don't think 
> it does, but I imagine that "weird" ports that don't have usual 
> autoconf-based configure scripts are especially in need of help with 
> universal builds, so I think we need to give the port the freedom to do 
> things in post-configure or other pre- and post- phases, per arch.

With the latest version of autoconf in macports (2.63_0) used as one of 
the auto-tools, any configure will see an -arch statement as a possible 
signal for ENDIAN setting.  If any -arch is used and the system is 
MAC_OS, it sets ac_cv_c_bigendian=universal.  Some configure scripts' 
programs see this as ac_cv_c_bigendian=no because they test for a 'yes' 
value.  The program may compile and run but have errors when it needs to 
access bitwise information.

I discovered this when I compiled (on my own) a recent version of XEmacs 
21.5 (beta28).  I was trying to test it with bignum support for ppc64. 
It failed to dump when it tried to access a byte-compiled lisp file that 
depended on the bit order of a variable.

The XEmacs team knows about this problem, but judging from the tests in 
/opt/local/share/autoconf/autoconf/c.m4, it looks to me that other 
packages that depend on configure could make the same error if the ones 
who maintain the package (upstream) don't have a way to further check 
the ENDIANess on the machine (or know directly about fat binaries).

I just stumbled on this because I wanted to be able to report whether 
the 64-bit compilation would work for PPC.  There had been previous 
reported problems on SPARC and at least one other for 64 bit.  The error 
is the type that might go unnoticed if all you looked for was the 
program's ability to load and run.  The crash was in lisp code and not a 
"real" crash.

-- 
Dr. Robert Delius Royar                   Associate Professor of English
Morehead State University                             Morehead, Kentucky