[MonetDB-users] monetdb failing tests on FreeBSD
Hi, I just installed MonetDB-4.8.0_rc0 on FreeBSD 5.4-STABLE running on an opteron. To get it to compile I added this to monetdb_config.h: #define __BSD_VISIBLE 1 and I changed /* #define _POSIX_C_SOURCE 200112L */ /* XXX JOE */ #define _POSIX_C_SOURCE 200112 because a freebsd system header already had _POSIX_C_SOURCE defined without the L. when running "gmake check" I get: !ERROR: Testing FAILED SIGNIFICANTLY ! 2 out of 69 tests could not be executed 2 out of 69 tests produced slightly different output 2 out of 69 tests produced SIGNIFICANTLY different output the output is at http://theoden.vpop.net/~joe/mtest/ Any idea what this means and why? I am brand new to monetdb. thanks, -joe
On Thu, May 26, 2005 at 09:24:53PM -0700, Joseph McDonald wrote:
Hi,
Joseph Many thanks for your interest in MonetDB. We very much appreciate your attempt to port it to FreeBSD. Unfortunately we do not have access to such a system at the moment.
I just installed MonetDB-4.8.0_rc0 on FreeBSD 5.4-STABLE running on an opteron.
I would like to integrate these changes somehow in our sources, but the monetdb_config.h file is auto generated by autoconf's configure script, so I guess that we miss some autoconf line needed for FreeBSD.
I had a look at the result The 2 which couldn't be executed are probably related to missing depending libraries, such as lib netcdf. So thats not a problem 2 tests with slightly different output is also not a problem, these are related small differences in round of float and double values. We have these too between a number of our systems The second 'SIGNIFICANT' difference is just the output of random, ie not a problem, but we should fix the test that this doesn't cause a failed test. The remaining failure seems more serious. The value is somehow equal to LLONG_MIN which in our case is the nil (SQL NULL) value. Could you send the LLONG_MIN/MAX values from your system include file (on linux this is /usr/include/limits.h not sure if BSD has it also in this file). Conclusion is that its almost perfect score, not bad for a new platform. Niels
-- Niels Nes, Centre for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands room C0.02, phone ++31 20 592-4098, fax ++31 20 592-4312 url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl
On Thu, May 26, 2005 at 09:24:53PM -0700, Joseph McDonald wrote:
I read some documentation about BSD_VISIBLE. And they claim its a variable you/we shouldn't set. As its supposed to be set correctly by the system headers. So I would like to know what part of the compilation went wrong, ie. which function we use outside of the POSIX_C_SOURCE=200112 set. Niels
-- Niels Nes, Centre for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands room C0.02, phone ++31 20 592-4098, fax ++31 20 592-4312 url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl
Hi Niels!
Yeah, I read that as well, but I don't know of a way around it right now (I'm not a C hacker). Here is the error I get if I fail to define __BSD_VISIBLE: (cd .libs && rm -f libmutils.la && ln -s ../libmutils.la libmutils.la) /usr/local/bin/bash ../../libtool --mode=compile --tag=CC gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I. -DLIBSTREAM -g -O2 -std=c99 -Wall -W -fno-strict-aliasing -Werror-implicit-functio n-declaration -Werror -Wno-format -Wno-unused-function -Wno-unused-label -D_REENTRANT -c -o libstream_la-stream.lo `test -f 'stream.c' || echo './'`stream.c gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I. -DLIBSTREAM -g -O2 -std=c99 -Wall -W -fno-strict-ali asing -Werror-implicit-function-declaration -Werror -Wno-format -Wno-unused-function -Wno-unu sed-label -D_REENTRANT -c stream.c -fPIC -DPIC -o .libs/libstream_la-stream.o In file included from stream.mx:265: /usr/include/netinet/ip.h:49: error: syntax error before "u_int" /usr/include/netinet/ip.h:148: error: syntax error before "u_char" /usr/include/netinet/ip.h:200: error: syntax error before "u_char" The problem is that netinet/ip.h looks like this: struct ip { #if BYTE_ORDER == LITTLE_ENDIAN u_int ip_hl:4, /* header length */ ip_v:4; /* version */ #endif #if BYTE_ORDER == BIG_ENDIAN u_int ip_v:4, /* version */ ip_hl:4; /* header length */ #endif u_char ip_tos; /* type of service */ u_short ip_len; /* total length */ [...] if I set __BSD_VISIBLE then u_int, u_char are typedef'd (in sys/types.h), otherwise they are not. There is probably a better way, I just don't know what it is. thanks, -joe
On Fri, May 27, 2005 at 11:11:03AM -0700, Joseph McDonald wrote: Hi Joe In our linux systems here these kind of system macros are set in the header file /usr/include/features.h, which is include by just about any of the other includes in /usrc/include. So probably there is a similar one on you BSD system. I you could send this file or look into it and find out when BSD_VISIBLE gets set we may fix it the proper way. Thanks Niels
-- Niels Nes, Centre for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands room C0.02, phone ++31 20 592-4098, fax ++31 20 592-4312 url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl
Joseph McDonald wrote:
That's funny. My Mac OS X system has the same files, but in sys/types.h it doesn't use __BSD_VISIBLE, but _POSIX_SOURCE: #ifndef _POSIX_SOURCE typedef unsigned char u_char; typedef unsigned short u_short; typedef unsigned int u_int; typedef unsigned long u_long; typedef unsigned short ushort; /* Sys V compatibility */ typedef unsigned int uint; /* Sys V compatibility */ #endif
On Fri, May 27, 2005 at 11:11:03AM -0700, Joseph McDonald wrote: joe I added your fixes into the current CVS version. I think the bsd include file (sys/cdefs.h) is somewhat broken, thats why the __BSD_VISIBLE is needed. What I found really strange is that autoconf identifies the system as i686-redhat-linux-gnulibc1, could this be related to the linux compatibility layer/tools. I needed to install bison and gnu make to get things to work, ie the bsd's (b)yacc and make didn't work as we expect them. Niels -- Niels Nes, Centre for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands room C0.02, phone ++31 20 592-4098, fax ++31 20 592-4312 url: http://www.cwi.nl/~niels e-mail: Niels.Nes@cwi.nl
Hi Joe, Thank you very much for been interested in MonetDB and for sharing your experiences with us!
as far as I recall, we haven't tried the compile MonetDB on FreeBSD, before (we don't have any FreeBSD machines ourselves), hence, we were not yet aware that the changes you report are necessary. Thanks for reporting them. "Eventually", we will have to fix our configure process to take care of them, but I'm not sure, whether we will have time to do this before the release on Sunday --- especially since we don't have a FreeBSD machine to test the changes --- hence, I hope, it's will not be too much of a problem, if you'll have to apply these patches "by hand" again for the final release.
First of all, though running on an opteron, you seem to have compiled MonetDB with 32-bit. Well, this is not a problem, and I'm actually not completely sure, whether your FreeBSD is 64-bit (though I guess so ;-)); apparently, you have all necessary libraries installed in 32-bit format. The point is, that our configure be default choses 32-bit "even" on 64-bit systems (also here, we haven't had the time to change this; sorry for the inconvenience...). If you prefer 64-bit MonetDB; you need to recompile from scratch, running configure with "--enable-bits=64". The 2 that could not be executed are src/mapi/Tests/utf_8_JAVA & src/modules/mnetcdf/Tests/mnetcdf . For the first one, java is required, but configure apparently could not find a suitable java (MonetDB required java
The 2 "slightly different output"s are src/modules/plain/Tests/aggr & src/modules/plain/Tests/aggrX3 . In both cases, the differences stem from the fact that different systems/machines appear to have (slight) differences in floating point accuracy. Thi sis normal, and hence nothing to worry about. The 2 "SIGNIFICANTLY different output"s are src/gdk/Tests/cast & src/modules/plain/Tests/arith appear since differnt systems do produce different output for these tests. This is the "nature" of these tests, and we provide "system-specific" output for all systems that we know (i.e., have access to, and hence can test on); there is no specific FreeBSD output (yet?). Hence, also these are fine. I hope, this information helps you. Please lets us know, in case you have more questions, suggestions, etc. Kind Regards, Stefan
-- | 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 |
participants (4)
-
Fabian -
Joseph McDonald -
Niels Nes -
Stefan.Manegold＠cwi.nl