Hi,
I just made a very simple attempt to fix the problem by ensuring that --enable-oid32 is handled and MONET_OID32 defined only with 64-bit builds (but ignored/unset otherwise); see also [ 1876580 ] Compile MonetDB on Darwin 9: failed by --enable-oid32 https://sourceforge.net/tracker/index.php?func=detail&aid=1876580&gr...
If this works, we're fine. If not, we can go back to the previous situtation (before Fabian's changes in buildtools/conf/MonetDB.m4), i.e., --enable-bits is only handled on platform where it is known to work (incl. Darwin 8), while on other platforms (e.g., Darwin 9; or when using the Intel compiler), configure stops with the following advice:
"case "$GCC-$CC-$host_os-$host-$bits" not handled with --enable-bits, yet; please use CC, CFLAGS and/or LDFLAGS (instead of --enable-bits=$bits) to make "$CC" produce $bits-bit code"
(obviously with the variables replaced with the respective values...)
Stefan
On Tue, Jan 22, 2008 at 10:25:37AM +0100, Fabian Groffen wrote:
I just noticed http://article.gmane.org/gmane.comp.db.monetdb.devel/937
(3) Indeed, even though it does not make sense, we should not crash on "--enable-bits=32 --enable-oid32", but either (preferred) handle it correctly (e.g., by ignoring the latter in case the former holds (regardless of whether requested explicitly or simply by being the default)), or (at the very least) stop with a proper message saying that it is not required to specify the redundant information.
I would prefer to give a message that the redundant "--enable-oid32" has been discarded and continue.
I think the only "redundant" option here is --enable-bits. Simply because --enable-bits only works for GNU multilib compilers, but it doesn't check them, and also assumes every compiler to be a multilib compiler. I noticed so when I changed MonetDB.m4 for Jennie.
The correct way to deal with multilib compilers is to leave it up to the user, e.g. set CC="gcc -m64" or CC="gcc64" or CHOST/CTARGET=xxx64-xx-xx. Having configure have a flag that switches on the -mX per magic is rather misleading, and from the auto* world's point of view something that should have happened outside. I guess we run the test for the flag early enough in the process such that all AC_COMPILE tests use the -mX flag, but still I think it would clean things up when the flag would disappear.
(I cannot reply on the thread, because I am not subscribed to the list/didn't receive the message.)