On Tue, Oct 03, 2006 at 12:53:37PM +0200, Ronald Oussoren wrote:
On Oct 3, 2006, at 12:38 PM, Fabian Groffen wrote:
On 03-10-2006 11:55:52 +0200, Ronald Oussoren wrote:
On Oct 3, 2006, at 10:45 AM, Fabian Groffen wrote:
On 03-10-2006 10:42:24 +0200, Ronald Oussoren wrote:
The machine I was testing on is running 4.10.3 and is definitely listening on port 45123 and only that. I'll upgrade to the latest
Correct, that version is quite old.
'make check' for MonetDB-4.12.1 (downloaded today) complains a lot about:
!ERROR: interpret: no matching MIL operator to 'quit()'. quit();
does this happen with only MonetDB-4.12.1 present on your system, or with a "legacy" MonetDB-4.10.3 installed as well (cf. BTW3 below)?
That doesn't feel right.
That's what I thought as well ;-)
This is on a linux system (SLES9). I aborted 'make check' because it didn't seem to make any progress except printing this error message a lot.
BTW. I also had to suply both '--enable-debug' and '--disable- optimize' to the configure script, without the latter configure claimed I couldn't have both --enable-optimze and --enable-debug.
that's absolutely correct and IMHO desired behavior: the default for the release is "--enable-optimze", and --enable-optimze & --enable-debug do conflict; hence, if you want/need --enable-debug, you also must switch off optimization (--disable-optimize).
There is a default involved here. In order to have monetdb's configure respect your CFLAGS, you have to axe out CFLAGS hackery from the configure script, e.g.:
sed -i \ -e 's|CFLAGS="\$CFLAGS \\\$(X_CFLAGS)"||' \ configure || echo "Fixing configure failed!"
this is IMHO only required if you really need to explicitly proved CFLAGS with configure; --disable-optimize, --enable-debug do (should) not require such hack(s)...
Then configure with --disable-debug --disable-optimize
Is this needed at all when I just want to compile with '-g'? -- disable-optimize --enable-debug seems to work correctly for this. I mentioned the need for --disable-optimize because most other programs with a configure script seem to have no problems with having both optimization and debugging enabled (GCC can compile code like that, even if debugging optimized code can be quite confusing).
gcc can (to a certain extend) compile with both debugging and optimization (at least -O2) enabled (I'm not sure whether it stil works with our "aggressive" optimization options in case of --enable-optimize, i.e., "-O6 -fomit-frame-pointer -finline-functions -malign-loops=4 -malign-jumps=4 -malign-functions=4 -fexpensive-optimizations -funroll-all-loops -funroll-loops -frerun-cse-after-loop -frerun-loop-opt"...) However, when using gdb on gcc compiled code with -g -Ox, (x>0), practice shows that things do not work as you expect them to work (e.g., source tracing not necessarily aligned with actual exection, etc.); hence, we consider only "-g -O0" as "save" option for (indeed) debugable code...
I'm building from source because I want to install into /opt/ monet-4.12.1 and link to a custom build of python.
That's fine and should work as expected (--prefix=/opt/monetdb-${PV})
It does, I was trying to avoid questions about why I wasn't using the RPMs.
BTW2. If monetdb is installed in a different prefix than python the python bindings won't end up on the default search path of the python interpreter. I've added a .pth file to site-packages to fix that, maybe 'make install' should do that automaticly. Building/installing using distutils would be even better :-)
I think that's what PYTHONPATH is for, but I leave that to the python experts. If your solution is to write in the non-prefix to make some sort of alias, then it won't work, as you don't have to be root. Maybe you don't even want to do that. (Using another version of python, for example.)
PYTHONPATH works as well, but I prefer .pth files unless I want to use multiple versions. Anyway, this seems to be a bug in the install target, I didn't notice this before but the python files are installed in ${monetPrefix}${pythonPrefix} instead of just $ {pythonPrefix}, MonetSQLdb.__file__ is '/opt/monet-4.12.1/opt/ python2.4/lib/python2.4/site-packages/MonetSQLdb/__init__.pyc' on my system.
Just to be anal: you cannot share extensions between multiple versions of python. It happens to work in most cases, but python 2.x and 2.y (x != y) aren't binary compatible.
BTW3. The version info for the shared libraries is incorrect, which means you cannot have two versions of monetdb installed at the same time, I got a Mserver 4.12.1 that claimed it was 4.10 and didn't work at all. I guess this is "don't do that" territory ;-). Removing the older installation solved this.
If Mserver claims to be 4.10, then it indeed is 4.10 --- to be more precise, it at least loads the 4.10 libmonet.so for the "known" location; in case you install both 4.12.1 & 4.10, you need to make sure that they are installed in different locations (prefixes), and your PATH (& LD_LIBRARY_PATH) point indeed to the version you intend to use.
I think slotting is not supported, and that the best way out of there is to just install into different prefixes.
I did, but had both prefixes on LD_LIBRARY_PATH (that is, I wasn't paying attentention)
Ok, then probably when calling the 4.12.1 Mserver, your 4.10 libdir was first in your LD_LIBRARY_PATH --- amaising that it did load the wrong libmonet at all --- this might also explain the make check problems you mentioned above ... Stefan
Thanks for your help, Ronald
-- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | 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 |