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&group_id=56967&atid=482468
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.) -- | Dr. Stefan Manegold | mailto:[EMAIL PROTECTED] | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 | ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Monetdb-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-developers
