Bugs item #2774951, was opened at 2009-04-19 23:18 Message generated for change (Comment added) made by mr-meltdown You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2774951&group_id=56967
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: MonetDB Common CVS Head >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Syeed Mansur (smansur) Assigned to: Sjoerd Mullender (sjoerd) Summary: Build Fails on OpenSolaris 64-Bit Initial Comment: I am using SunOS opensolaris 5.11 64-bit, and my builds are failing. I downloaded all the sources from the CVS repository, and used bootstrap to setup the build. This produced a configure script in the MonetDB package directory, which when invoked produced the following error: configure: error: need GCC version >=3.X for 64 bits However, I am using gcc version 3.4.3: #gcc --version gcc (GCC) 3.4.3 So, to work-through the problem, I used aclocal and autoconf to rebuild the configure script, which produced the following errors: #aclocal /usr/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE /usr/share/aclocal/audiofile.m4:12: run info '(automake)Extending aclocal' /usr/share/aclocal/audiofile.m4:12: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal configure.in:63: warning: macro `AM_MONETDB_XQ_VARS_1' not found in library configure.in:66: warning: macro `AM_MONETDB_DEFAULTS' not found in library configure.in:69: warning: macro `AM_MONETDB_COMPILER' not found in library configure.in:70: warning: macro `AM_MONETDB_TOOLS' not found in library configure.in:71: warning: macro `AM_MONETDB_OPTIONS' not found in library configure.in:72: warning: macro `AM_MONETDB_UTILS' not found in library configure.in:85: warning: macro `AM_MONETDB_LIBS' not found in library configure.in:103: warning: macro `AM_MONETDB_XQ_VARS_2' not found in library #autoconf -f configure.in:63: error: possibly undefined macro: AM_MONETDB_XQ_VARS_1 If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:66: error: possibly undefined macro: AM_MONETDB_DEFAULTS configure.in:69: error: possibly undefined macro: AM_MONETDB_COMPILER configure.in:70: error: possibly undefined macro: AM_MONETDB_TOOLS configure.in:71: error: possibly undefined macro: AM_MONETDB_OPTIONS configure.in:72: error: possibly undefined macro: AM_MONETDB_UTILS configure.in:85: error: possibly undefined macro: AM_MONETDB_LIBS configure.in:103: error: possibly undefined macro: AM_MONETDB_XQ_VARS_2 A configure script did get produced, and when I invoked this script, I received the following errors: #configure --prefix=/root/makemonet/bin --enable-bits=64 --enable-debug=no --enable-assert=no --enable-optimize=yes /root/sourcemonet/MonetDB/configure: line 19267: syntax error at line 19887: `>' unexpected I must be doing something wrong, but after several days of reviewing, I can't seem to figure out the problem. Any help would be greatly appreciated. Thanks, Sid ---------------------------------------------------------------------- >Comment By: Fabian (mr-meltdown) Date: 2009-05-27 15:57 Message: closing per comment 2009-05-03 08:46 ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2009-05-03 08:55 Message: Due to a reconnection of the main power supply, CWI is without power this weekend, and hence, the MonetDB web server is indeed down --- sorry for the inconveniences --- it should be back up by Monday (not before 9am CEST, though). ---------------------------------------------------------------------- Comment By: Syeed Mansur (smansur) Date: 2009-05-03 08:46 Message: Thanks Stefan - that worked like a charm. I revised my conf file and restarted merovingian. I have not yet implemented Fabian's directions for bootstrapping on OpenSolaris - for now, I'll just go ahead and rely on the pre-bootstrapped build. Perhaps we should go ahead and route this bug for closure (incidentally, I am unable to download the pre-bootstrapped sources from monetdb.cwi.nl - is the webserver down?). ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2009-05-03 08:31 Message: look for "gdk_nr_threads=" in your monetdb5.conf ; if it's there, change it to "gdk_nr_threads=1"; otherwise add a line "gdk_nr_threads=1" to your monetdb5.conf; then stop and restart your server / database. ---------------------------------------------------------------------- Comment By: Syeed Mansur (smansur) Date: 2009-05-03 08:13 Message: If I use merovingian, is there a way to specify the number of threads? Or, must I use mserver5? ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2009-05-03 08:08 Message: Sid, I assume you hit a bug in multi-threaded bulk-loading similar or identical to the one reported in ID: 2771052 "M5/SQL: parallel bulk-load (copy into) incorrect" https://sourceforge.net/tracker/?func=detail&aid=2771052&group_id=56967&atid=482468 For bulk-loading (COPY INTO), please start your mserver5 in single-threaded mode (using "--set gdk_nr_threads=1" on the command line) and try again. Stefan ---------------------------------------------------------------------- Comment By: Syeed Mansur (smansur) Date: 2009-05-03 07:16 Message: After a bit more investigation on why my 517GB file was consuming more than 1.1TB of space on MonetDB (please see comment from 2009-04-29 17:13), it looks like I have to use the OFFSET command in order to load the file properly. I am not sure if this is a bug, but this is what I've discovered thus far: 1) If I perform "COPY 9999 RECORDS into mytable from data.txt", the copy works fine (9,999 rows are loaded). 2) If I perform "COPY 10000 RECORDS into mytable from data.txt", the copy seems aberrant (108,000 instead of 10,000 rows are loaded). 3) If I perform "COPY 10000 offset 100 RECORDS into mytable from data.txt", the copy works fine (10,000 rows as specified are loaded). I've tested on both OpenSolaris 64-bit and Fedora 10 64-bit. In both scenarios the above behavior occurred. It seems that I MUST use "OFFSET" in order to get more than 9,999 records loaded properly. Is this a bug, or intentional design? ---------------------------------------------------------------------- Comment By: Syeed Mansur (smansur) Date: 2009-05-01 10:01 Message: Storage size is a rather important issue because we are trying to overcome the I/O boundedness of our queries by moving over to SSD Drives connected via PCI-E (such as the Fusion-IO Duo product). To minimize expense of the SSD devices, and be able to fit almost a terabyte of data into storage, we are eager to compress. Even if we don't use SSD (solid state disks), compression allows us to "cheat" I/O throughput from normal SAS drives (so, to that end, storage size is a significant issue for us --> Indeed, that is another reason for our interest in X100). Thanks for the instructions - I'll attempt a compile of the non pre-bootstrapped sources over the weekend. ---------------------------------------------------------------------- Comment By: Fabian (mr-meltdown) Date: 2009-05-01 09:39 Message: Sid, since you ask for it, this is how I get my compiler, using the 64-bits instructions: http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml As for the ZFS configuration, I have both a mirror and a stripe, and I checked their usage (simply `zfs status` shows it) which align with what `df -h` reports. The only occasion when it will differ is when using raidz. I don't know why your file on disk is twice the size of your CSV file, as it was on Linux, but with compression it seems you can cut it down to an amazing small size. I'm not sure how much storage size is an issue for you? ---------------------------------------------------------------------- Comment By: Syeed Mansur (smansur) Date: 2009-05-01 09:09 Message: Fabian: The ZFS pool is setup as raid0 with 4 disks. I'm measuring space usage via the ZFS get all command. I'm also using du -h to measure disk utilization. As for your compiler, I was wondering if you can provide instructions on how to use specially configured compilers to get the head sources from CVS to compile on 64-bit opensolaris. Stefan: I stopped mserver5, and started merovingian (although, I can't seem to figure out how to stop merovingian). I then truncated my 517GB CSV file down to 5.17GB and tried loading that into an uncompressed ZFS pool. I loaded it in, and the total disk utilization was 12.69GB. I ran a query, and successfully got a response in 14 seconds (compared to 348 seconds on Infobright for the same exact hardware setup but on Fedora). Once this completed, I changed ZFS to use Gzip-1 compression and then reloaded the 5.17GB file. In this scenario, I got 5.1x compression and used roughly 2.6GB of space. I resubmitted the same query as above, and my result came back in 8.7 seconds! I just kicked off a load where I'll attempt to put 51.7GB of data into MonetDB - I'll let you know how that works out. However, given the incredible performance that we're already seeing with the 5GB file, we're quite eager to get our 500GB data set working. To that end, we're especially eager to hear your feedback from the X100 team (you or the X100 team can contact me directly at [email protected] or [email protected]). One thing we can do to get around the excessive memory use problem on a single server is to go to a MPP setup. In one of Peter Boncz's papers, he mentions the possibility of partitioning a data set across a shared-nothing architecture of servers. The technical overview of MonetDB also delineates some information about partitioning BATS and using TCP/IP to configure multiple servers - but, its not clear from the literature how we can make this work. Since my questions are going beyond the central crux of the original bug report, I would rather take this discussion offline and discuss over email/phone with your team. In the meantime, I would suggest we close this bug report once you or Fabian can suggest some details about how to successfully compile non pre-bootstrapped sources. Last but not least, thanks to both you & Fabian for your earnest help and for contributing to the development of a rather amazing database engine (we have been evaluating Vertica, Greenplum, LucidDB, Infobright, etc, and have found MonetDB to be the richest in terms of intellectual thought-leadership and in terms of performance!). As a company, there is great interest from our team to become involved with MonetDB - and with respect to this, it may perhaps make sense to further the discussion offline and outside of this bug report. Thanks, Sid ---------------------------------------------------------------------- Comment By: Fabian (mr-meltdown) Date: 2009-04-30 10:23 Message: Sid, I use a 64-bits compiler, e.g. x86_64-pc-solaris2.11-gcc. Hence, the trickery with --enable-bits or CC="gcc -m64" isn't necessary, and also the code path in the .m4 file isn't activated. I built this compiler myself (with some help of Portage actually), as it is not available on any *Solaris system. How is your ZFS pool setup? mirror, stripe, raidz? How many disks does it contain? How did you measure the space usage? Note that zfs has some different metrics to report used diskspace, depending on your configuration. ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2009-04-29 23:35 Message: Sid, wrt. X100: It is actively being developed, but not yet publicly available --- I'll ask the X100 developers, whether they could comment in more detail (publicly or privately). wrt. bootstrapping on OpenSolaris: The patch for buildtools/conf/MonetDB.m4 that I suggested is indeed a bug fix that I committed to the CVS repository on 2009/04/21. wrt.ZFS: did/could you try to load your 517 GB CSV on OpenSolaris with a non-comprssing file system to check whether the problems are indeed ZFS related, or rather OpenSolaris related? Or the combination of both --- I'm not sure how well OpenSolaris + ZFS can handle memory-mapped files ... Stefan ---------------------------------------------------------------------- Comment By: Syeed Mansur (smansur) Date: 2009-04-29 23:15 Message: Fabian & Stefan: A third question - the main reason that we are using OpenSolaris is because we are trying to "cheat" the I/O boundedness by using Gzip-1 compression on the filesystem (and that's giving us about 5.3x compression). Do you know what is the state of X100 development, and whether or not we can use it on Fedora10? If so, then I don't think we would continue to entertain OpenSolaris any further. ---------------------------------------------------------------------- Comment By: Syeed Mansur (smansur) Date: 2009-04-29 23:13 Message: Fabian, Sorry for the delay in posting my response. I have been attempting to upload my 517GB CSV file into a table on MonetDB over the last 3 days, and after 76 hours, the upload is still not finished. However, that 517GB CSV file is now consuming upwards of 1.1TB of space on MonetDB. I don't know if something has gone wrong - I suspect something fishy is happening on the ZFS filesystem in OpenSolaris, as I did not have this problem on Fedora 10. With respect to the crux of this bug report, I believe I have installed all the up-to-date development tools (gcc, automake, autoheader, autoconfig, autoreconfig, m4, etc.). I may have to thoroughly start from scratch and see what happens. However, I am a bit surprised that you were able to bootstrap succcessfully on OpenSolaris 2008.11 - I could not make any progress without implementing the following change per Stefan's directions to the buildtools/conf/MonetDB.m4 file. Should I go ahead and request closure of this bug report and try to begin bootstrapping MonetDB from a completely new and fresh install of OpenSolaris? Also, should I not worry about the 517GB CSV file upload taking 1.1TB in MonetDB (i.e., this is what you would expect).? ---------------------------------------------------------------------- Comment By: Fabian (mr-meltdown) Date: 2009-04-28 12:51 Message: Is this still an issue? I'm able to build MonetDB on my 64-bits OpenSolaris system for a while now. Bootstrapping simply requires many (up-to-date) developement tools that you (may) have to install in some way. ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2009-04-23 13:45 Message: Sid, thank you very much for keeping us posted --- loading a 1.5 billion rows 530GB table on a 64-bit system with "just" 4 GB RAM is something we hadn't tried (or heard of) before --- good to know that it works on Linux, and keeping my fingers crossed that it will also work on OpenSolaris ... We are also very curious to learn about your experiences with using MonetDB on ZFS! We are successfully compiling MonetDB from plain CVS sources every night in our testing environment (cf., http://monetdb.cwi.nl/Development/TestWeb/) on two different OpenSolaris installations (cf., http://monetdb.cwi.nl/Development/TestWeb/Platforms/): 1) $ cat /etc/release OpenSolaris 2008.11 snv_101b_rc2 X86 Copyright 2008 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 19 November 2008 64-bit on an Athlon 64 X2 3800+ using Gentoo Prefix Base System version 1.12.5 2) $ cat /etc/release Solaris Express Community Edition snv_93 X86 Copyright 2008 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 03 July 2008 32-bit on a Xeon E5405 (Quad-Core) using the plain system tools. Hence, I'm confident we will also be able to collaboratively sort-out and solve your problems with compiling from plain CVS source on your OpenSolaris installation (respectively an update or fix of that). Stefan ---------------------------------------------------------------------- Comment By: Syeed Mansur (smansur) Date: 2009-04-22 23:34 Message: Fabian: I recovered the server after it crashed, and updated the 2008.11 OpenSolaris install that I had running. I'm not sure why the whole system crashed, but it is back up and running now. Stefan: I agree - I think it is quite impressive that MonetDB (without using X100) was able to bring up a 530GB table, and I was able to run a simple query in Linux. As for my OpenSolaris installation, I now have rebuilt MonetDB using the pre-bootstrapped code (via install.sh) and have set CC='gcc -m64'. I started mserver5 with a single thread, and I am happy to say that so far so good (thank you very much for your help). I started loading the 530GB table, and it will take another 23 hours to finish loading, but there are no failures thus far. As a side note, I am trying to use MonetDB on OpenSolaris so that I can take advantage of the ZFS filesystem, which provides transparent compression. On the Linux deployment, I saw that I was very much I/O bound (CPU utilization was at 40-50%), and I'd like to cheat the I/O boundedness by using transparent compression. Hopefully, this will give me a noticeable performance boost. If I'm able to run my queries successfully in OpenSolaris, I think our team will want to switch there focus onto X100 and we will have to see if there is any way for us to get our hands on the X100 module. I'll let you know tomorrow if the data upload successfully completes and if I'm able to successfully run a query. Once again, thank you so much for your help thus far. -Sid p.s. Note, I do think that once we start playing with the MonetDB source code itself, we will still need to figure out how to get the non-pre-bootstrapped sources to compile. ---------------------------------------------------------------------- Comment By: Fabian (mr-meltdown) Date: 2009-04-21 10:12 Message: I'd like to note that OpenSolaris 2008.05 (and I also think 2008.11) is unstable. I had it installed on my desktop and had crashes all the time. I updated to "SunOS 5.11 snv_101b i86pc i386 i86pc Solaris" and ever since never had to reboot for anything. I think you'll have to update your OpenSolaris system, or install Solaris 10 to get a stable system. I use OpenSolaris 64-bits on a single core 2GB RAM machine with 32G swap. CPU/core detection of MonetDB works also on Solaris/OpenSolaris. ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2009-04-21 10:01 Message: MonetDB is indeed supposed to automatically detect the number of cores and parallelize query execution accordingly --- at least it does on Linux; on my quad-core CPU, it says: $ mserver5 # MonetDB server v5.10.4, based on kernel v1.28.3 # Serving database 'demo', using 4 threads I'm not completely sure, whether it also works on OpenSolaris --- please check the welcome message of your mserver5. Did your OpenSolaris box freeze (right) after the error message you reported? How big is your 1.5 billion rows table that you managed to load on the 4GB Linux box? 530GB as mentioned earlier? That would indeed be very impressive ... ---------------------------------------------------------------------- Comment By: Syeed Mansur (smansur) Date: 2009-04-21 09:45 Message: The OpenSolaris and the Linux machine are identical (I installed MonetDB on the Linux machine last week, and then wiped Linux off that machine and installed OpenSolaris - my goal is to test the ZFS filesystem and see if I can get performance increases on Monetdb using the compression feature of ZFS). Anyway, the computer has 1 CPU, 2 cores, with 4GB of physical RAM and 4GB of swap. I was remote-logged in to my machine and it froze after I tried to copy the records into MonetDB. I will have to try the reload in single-threaded mode (by the way, does MonetDB automatically recognize the number of cores and spawn multiple threads to coincide with the cores?) after I go into the office and reboot the machine (probably in 5 hours). ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2009-04-21 09:33 Message: How much physical (RAM) and virtual (swap) memory do your OpenSolaris and Linux machines have? How many CPUs/cores do your machines have? If the OpenSolaris has more than 1 CPU/core, could you please try to start the mserver5 in single-threaded mode (--set gdk_nr_threads=1) for loading the data via copy into? (cf., https://sourceforge.net/tracker/?func=detail&aid=2771052&group_id=56967&atid=482468) In case the above doesn't work, instead of using the source tarball of the development trunk, could you please try the latest Stable release MonetDB-Feb2009-SuperBall-SP1.tar.{bz2,lzma} from http://monetdb.cwi.nl/downloads/sources/Feb2009-SP1/ ? ---------------------------------------------------------------------- Comment By: Syeed Mansur (smansur) Date: 2009-04-21 09:12 Message: Stefan, I did indeed try the pre-bootstrapped sourceball with 'gcc -m64'; monetdb-install.sh. That compiles fine, and then when I try to load my data (using COPY command for 1.5Billion rows), I get the following error: mclient -lsql --database=syscodb < /root/load_xactions.sql MAPI = mone...@localhost:50000 QUERY = copy 1500000000 records into transactions ERROR = !SQLException:importTable:failed to import table !ERROR: HEAPextend: failed to extend to 3000000000 for 20/2060tail !ERROR: TABLETcreate_bats: Failed to create bat of size 1500000000 !ERROR: TABLETload_file:could not allocate bats Note, this failure occurs on OpenSolaris, but this does not occur on Linux (Fedora 10). For reference, the results of 'mserver5 --version' is: MonetDB server v5.11.0 (64-bit), based on kernel v1.29.0 (64-bit oids) Copyright (c) 1993-July 2008 CWI Copyright (c) August 2008-2009 MonetDB B.V., all rights reserved Visit http://monetdb.cwi.nl/ for further information Configured for prefix: /root/MonetDB Libraries: libpcre: 7.4 2007-09-21 (compiled with 7.4) openssl: OpenSSL 0.9.8a 11 Oct 2005 (+ security patches to 2007-10-13) (compiled with OpenSSL 0.9.8a 11 Oct 2005 (+ security patches to 2007-10-13)) libxml2: 2.6.31 (compiled with 2.6.31) Compiled by: @opensolaris Compilation: gcc -m64 -m64 -I/usr/sfw/include -L/usr/sfw/lib -D__EXTENSIONS__ -std=c99 -O6 -fomit-frame-pointer -finline-functions -falign-loops=4 -falign-jumps=4 -falign-functions=4 -fexpensive-optimizations -funroll-loops -frerun-cse-after-loop -frerun-loop-opt Linking : /usr/ccs/bin/ld -m64 -L/usr/sfw/lib -R/usr/sfw/lib So, it looks like the 64-bit version of MonetDB has been picked up, so I'm not sure why my COPY is failing. In an attempt to work-through this issue from scratch, I figured I'd try to download the sources directly from CVS and build everything afresh. That led me to the errors which caused me to open this bug report. With respect to your other question below, I did recompile everything from scratch (I may have missed something, so I will re-do everything). I completely removed my build directory and install prefix directory. I'll let you know what happens. In the meantime, should I open a different bug report for the COPY failure above, or is that considered a part of this current bug report? Regards, Sid ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2009-04-21 08:07 Message: Syeed, after applying my patch, did you recompile everything from srcatch, i.e., remove your complete build director(y|ies) and install prefix, and then start with ./bootstrap in buildtools? If so, could you please provide us with the exact configure call you used as well as the complete output of ./bootstrap, configure, make & make install for buildtools & MonetDB? Alternatively, did you try the pre-bootstrapped super sourceball with export CC='gcc -m64' ; ./monetdb-install.sh ... ? Stefan ---------------------------------------------------------------------- Comment By: Syeed Mansur (smansur) Date: 2009-04-21 03:51 Message: Fabian & Stefan: Thanks for your quick responses. Fabian, the reason I'm not using the pre-bootstrapped install.sh command is that I've already tried it, and on OpenSolaris 64-bit it seems to produce binaries that are 32-bit, which is not good enough for me to load up a 530GB table. Stefan: I implemented your suggestion, and the build process got past the original error, but not it looks like its getting caught in a different problem. configure seems to complete successfully, and then when I issue the gmake command, the process finishes as follows: gmake[5]: Leaving directory `/root/makemonet/src/gdk' gmake[4]: Leaving directory `/root/makemonet/src/gdk' gmake[4]: Entering directory `/root/makemonet/src' gmake[4]: Nothing to be done for `all-am'. gmake[4]: Leaving directory `/root/makemonet/src' gmake[3]: Leaving directory `/root/makemonet/src' gmake[2]: Leaving directory `/root/makemonet/src' Making all in conf gmake[2]: Entering directory `/root/makemonet/conf' /usr/sfw/bin/gmake all-am gmake[3]: Entering directory `/root/makemonet/conf' gmake[3]: Nothing to be done for `all-am'. gmake[3]: Leaving directory `/root/makemonet/conf' gmake[2]: Leaving directory `/root/makemonet/conf' gmake[2]: Entering directory `/root/makemonet' gmake[2]: Leaving directory `/root/makemonet' gmake[1]: Leaving directory `/root/makemonet' I went ahead and invoked the "gmake install" command, and that (as expected) did not install any binaries. For reference, during the bootstrap, I recieved the following errors: Remember to add `AC_PROG_LIBTOOL' to `configure.in'. You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'. Putting files in AC_CONFIG_AUX_DIR, `conf'. /usr/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE /usr/share/aclocal/audiofile.m4:12: run info '(automake)Extending aclocal' /usr/share/aclocal/audiofile.m4:12: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal Looks like a unified context diff. Hunk #1 failed at line 6386. 1 out of 1 hunks failed: saving rejects to aclocal.m4.rej done configure.in:33: installing `conf/missing' configure.in:33: installing `conf/install-sh' By the way, the gcc -v command returns the following: l# gcc -v Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs Configured with: /builds2/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,f77,objc --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-20050802) ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2009-04-20 08:28 Message: Fabian: Internally (i.e., in buildtools/conf/MonetDB.m4), --enable-bits=<bits> is translated into CC="$CC -m<bits>"; hence, I don't see much of a difference... Syeed: Could you please undo/remove all your modification to checked-out and/or generated file, patch your checked-out buildtools/conf/MonetDB.m4 as follows: -------- Index: buildtools/conf/MonetDB.m4 =================================================================== RCS file: /cvsroot/monetdb/buildtools/conf/MonetDB.m4,v retrieving revision 1.108.2.2 diff -u -r1.108.2.2 MonetDB.m4 --- buildtools/conf/MonetDB.m4 14 Apr 2009 11:36:50 -0000 1.108.2.2 +++ buildtools/conf/MonetDB.m4 20 Apr 2009 06:24:04 -0000 @@ -586,7 +586,7 @@ *-*-*-*-$native_bits) ;; yes-*-solaris*-*-*) - case `$bits-$CC -v 2>&1` in + case "$bits-`$CC -v 2>&1`" in 32-*|*-*'gcc version '[[34]]'.'*) ;; *) AC_MSG_ERROR([need GCC version >=3.X for 64 bits]);; esac -------- and then try to compile & install buildtools & MonetDB from scratch, again, and report what happens? Also, could you please send us the output of `gcc -v` on your systems? ---------------------------------------------------------------------- Comment By: Fabian (mr-meltdown) Date: 2009-04-20 08:16 Message: Is it possible to use pre-bootstrapped sources, like e.g. the monetdb-install.sh script does? If you have to use CVS sources, does monetdb-install.sh --cvs produce the same autoconf errors? It seems to me you have an order problem. Last suggestion, don't use --enable-bits, but use export CC="gcc -m64" CXX="g++ -m64" instead. Be aware that the shipped compiler is quite old, and uses Sun ld though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2774951&group_id=56967 ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ Monetdb-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
