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 _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
