Is there anyone that can think of a solution for this problem?
cc1: warnings being treated as errors
/Volumes/Scratch/monetdb/stable/monetdb/src/modules/plain/bat.mx: In function 'local_itoa':
/Volumes/Scratch/monetdb/stable/monetdb/src/modules/plain/bat.mx:1253: warning: format '%zd' expects type 'signed size_t', but argument 4 has type 'ssize_t'
I mean... is there a difference between "signed size_t" and "ssize_t"?
Ehrm.
[Orion:src/modules/plain] fabian% uname -a
Darwin Orion.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc PowerBook4,3 Darwin
[Orion:src/modules/plain] fabian% gcc --version
gcc (GCC) 4.0.1 (Apple Computer, Inc. build 5341)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Probably just need to compile without -Werror.
On Thu, Nov 29, 2007 at 12:01:39PM +0000, Sjoerd Mullender wrote:
> Update of /cvsroot/monetdb/java
> In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv28680
>
> Modified Files:
> configure.ag rpm.mk.in
> Log Message:
> Added more rpmrc files to the --rcfile flag of rpmbuild. This is
> required for rpmbuild to recognize that in can build for a noarch CPU
> architecture.
> Removed references to host type from configure. This makes that the
> configure which is called by rpmbuild doesn't choke on the noarch CPU
> architecture.
>
> Together these two changes make that we can build the rpms.
>
> As a bonus:
> Removed AC_DEFINE calls from configure. We don't actually include
> monetdb_java_config.h anywhere, so we don't need to add anything extra
> to it.
Sjoerd said:
"Just check it in so more people can have a look at it"
THANKS!
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 |
Dear fellow MonetDB developers,
today, I separated MonetDB-related Java code from "MonetDB Clients"
clients/src/java
into its own new "MonetDB Java" CVS module
java
(obviously in the "Current" development trunk only).
"MonetDB Java" compiles just like the remaining MonetDB-related code, and
requires buildtools only when compiled from CVS source.
"MonetDB Java" does not require any other MonetDB package.
No other MonetDB package requires "MonetDB Java".
Hence, "MonetDB Java" can be built independently of the other MonetDB
packages.
Background & Details:
---------------------
To allow implementation of versioning-, packaging-, & release-schemes for
MonetDB'\''s Java/JDBC Support & Interface that are decoupled from the
respective schemes used for the (mainly C-based) remainder of the MonetDB
product family,
I implemented a move of the code from "clients/src/java/" into "java/", a
new separate CVS module for "MonetDB Java".
It comes with all the infrastructure of the usual MonetDB building process
(stripped-down, though, to the limited requirements), including
`./bootstrap`, `configure`, `make`, `make check`, `sh RunMtest`, `make
dist`, `make rpm`, `make install`, & .`Mtest.py -rq`.
Version number maintenance within "java/" is done exclusively by
java/version.sh, no vertoo involved, here.
To build, the new "MonetDB Java" requires only the buildtools (and that only
when building straight from CVS).
To run `make check` and/or `Mtest.py -rq`, Mtest.py from MonetDB Common must
be available in the PATH, though.
sql and pathfinder now check for the availability of MonetDB Java before
running their Java/JDBC tests.
On the live web site, the related Current-TestWeb pages have been updated.
Updating the build documentation in the development web site still has to be
done.
Caveat:
-------
`make rpm` requesting "noarch" does not work, yet.
ToDo:
-----
The "xrpcwrapper" Java code from pathfinder/src/tools/java/ should also be
moved into the new "MonetDB Java" package.
(Note, though, that "MonetDB Java" currently requires Java >= 1.4 & < 1.6,
while "xrpcwrapper" requires Java >= 1.5 .)
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 |
Please revert.
This is not the solution. It is also *blatantly* untrue that nobody
cares. We (at least Niels, Stefan, and I--we didn't discuss this with
Peter) do care, but we want a proper solution, and this is not it. We
agree that there should not be a call to umask in the code, but we
should also check the modes that are used in calls to creat, open,
mkdir, etc.
If you think this umask thing is important for you, say so in the bug
report and increase the priority accordingly. You can also *talk* to
people if something is important to you.
Fabian wrote:
> Update of /cvsroot/monetdb/MonetDB/src/gdk
> In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv7068
>
> Modified Files:
> gdk_utils.mx
> Log Message:
> Because nobody cares but me.
> Don't wipe out the user's umask if gdk_dont_unset_umask is set in the
> environment. Can't use GDKgetenv as that stuff is not yet initialised
> at this point.
>
>
> Index: gdk_utils.mx
> ===================================================================
> RCS file: /cvsroot/monetdb/MonetDB/src/gdk/gdk_utils.mx,v
> retrieving revision 1.196
> retrieving revision 1.197
> diff -u -d -r1.196 -r1.197
> --- gdk_utils.mx 14 Nov 2007 13:22:59 -0000 1.196
> +++ gdk_utils.mx 28 Nov 2007 11:59:39 -0000 1.197
> @@ -1636,7 +1636,8 @@
> if (GDKrecovery && unlink(GDKLOCK) < 0) {
> GDKfatal("GDKlockHome: unlock DB failed\n");
> }
> - umask(0000);
> + if (getenv("gdk_dont_unset_umask") == NULL)
> + umask(0000);
> if (MT_lockf(GDKLOCK, F_TLOCK, 4, 1) < 0) {
> GDKlockFile = 0;
> GDKfatal("GDKlockHome: Database lock '%s' denied\n", GDKLOCK);
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Monetdb-checkins mailing list
> Monetdb-checkins(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/monetdb-checkins
--
Sjoerd Mullender
On 27-11-2007 13:39:32 +0000, Stefan Manegold wrote:
> Update of /cvsroot/monetdb/geom/src/sql/Tests
> In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv24450/src/sql/Tests
>
> Modified Files:
> geom_surface.stable.err geom_surface.stable.err.Five
> spatial.stable.err spatial.stable.err.Five spatial.stable.out
> Log Message:
>
> "down"dated output from goes 3.0.0 to geos 2.2.3.
> The latter seems to be working just fine, and is no available as RPM
> on our Fedora testing machines (cluster & crux-farm);
> and will hopefully soon also be available on our desktops...
Hmmm... I have 3.0 installed (not using it really...) but doesn't this
approval mean configure should require 2.2 then?
On Sun, Nov 25, 2007 at 10:18:26AM +0000, Fabian wrote:
> Update of /cvsroot/monetdb/sql/src/backends/monet5
> In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv26685
>
> Modified Files:
> merovingian.mx
> Log Message:
> Attempt to fix some compiler warnings. I cannot test myself, as I don't
> get them, and if I use TestWeb's CFLAGS the code doesn't compile at all
> at a much earlier stage.
"TestWeb" does not use any (particular) CFLAGS, but just the default that
(our) configure uses/provides (with --enable-strict, which is default for
the development trunk).
In case you have problems with this (or other) settings, please help us
fixing them by reporting them ans bug report.
The compiler warning is triggered by the following setting in lines 742,3 of
buildtools/conf/MonetDB.m4
========
dnl The default configure invocation when doing an rpmbuild also uses this
X_CFLAGS="$X_CFLAGS -Wp,-D_FORTIFY_SOURCE=2"
========
Some functions (system calls) do return, whether they were successful, or
not, and the calling ocde should check the respective return values.
Ignoring them via (e.g.)
(void)write(...);
will (most probably) not help.
Rather, the code should check the results, e.g.,
if (write(...) < 0) {
...
}
or at least pretend to do so, e.g.,
ssize_t wrt_res = 0;
wrt_res = write(...);
(void)wrt_res; /* deliberately irgnore portential errors */
Stefan
> Index: merovingian.mx
> ===================================================================
> RCS file: /cvsroot/monetdb/sql/src/backends/monet5/merovingian.mx,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -u -d -r1.9 -r1.10
> --- merovingian.mx 25 Nov 2007 09:55:05 -0000 1.9
> +++ merovingian.mx 25 Nov 2007 10:18:24 -0000 1.10
> @@ -1203,10 +1203,10 @@
> case -1:
> /* oops, forking went wrong, cheat a bit in order to write to
> * the console */
> - write(oerr, "unable to fork into background: ",
> + (void)write(oerr, "unable to fork into background: ",
> sizeof("unable to fork into background: "));
> - write(oerr, strerror(errno), strlen(strerror(errno)));
> - write(oerr, "\n", 1);
> + (void)write(oerr, strerror(errno), strlen(strerror(errno)));
> + (void)write(oerr, "\n", 1);
> return(1);
> case 0:
> /* the child, we want to keep it, try to lock, we can only
> @@ -1217,17 +1217,17 @@
> * remain available, otherwise we loose the lock */
> if ((ret = MT_lockf(buf, F_TLOCK, 4, 1)) == -1) {
> /* locking failed */
> - write(oerr, "another merovingian is already running\n",
> + (void)write(oerr, "another merovingian is already running\n",
> sizeof("another merovingian is already running\n"));
> exit(1);
> } else if (ret == -2) {
> /* directory or something doesn't exist */
> - write(oerr, "unable to create .merovingian_lock file in ",
> + (void)write(oerr, "unable to create .merovingian_lock file in ",
> sizeof("unable to create .merovingian_lock file in "));
> - write(oerr, dbfarm, strlen(dbfarm));
> - write(oerr, ": ", 2);
> - write(oerr, strerror(errno), strlen(strerror(errno)));
> - write(oerr, "\n", 1);
> + (void)write(oerr, dbfarm, strlen(dbfarm));
> + (void)write(oerr, ": ", 2);
> + (void)write(oerr, strerror(errno), strlen(strerror(errno)));
> + (void)write(oerr, "\n", 1);
> exit(1);
> }
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Monetdb-sql-checkins mailing list
> Monetdb-sql-checkins(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/monetdb-sql-checkins
>
--
| 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 |
The MonetDB team at CWI is pleased to announce a new bug fix release of
the MonetDB suite of programs.
The following packages have been released:
MonetDB Clients 1.20.2
MonetDB5 Server 5.2.2
MonetDB SQL 2.20.2
There is of course also a new "Super Source Ball", a tarball containing
the combined sources.
All this is available on our SourceForge project page. See
https://sourceforge.net/project/showfiles.php?group_id=56967 for the
downloadable files.
See
http://monetdb.cwi.nl/projects/monetdb/Development/Releases/Version4.20/ind…
for a list of fixes.
--
Sjoerd Mullender
Hello everyone,
I am an Italian student, and I will work at MonetDB/SPARQL for my master
thesis starting from next January, in Amsterdam.
Prof. Martin Kersten told to have a look at the code, in particular the
SQL->MAL translator. So I downloaded the code, and managed to compile and
install it correctly (on Linux). Then I opened the code in Eclipse (do you
use it too? do you use some better C IDE?) and started to look at
MonetDB5-server. Prof. Kersten told not to worry... but that's impressive!
So where do you suggest me to start? Which c files and functions first?
Thanks in advance and kind regards,
Marco Antonelli
On 21-11-2007 15:07:04 +0000, Stefan Manegold wrote:
> +case "$host-$GCC-$CC-$enableval" in
> +ia64*-*-*-32)
> + AC_MSG_ERROR([we do not support 32 bits on $host]);;
So HPUX's 32-bits support on ia64 is not supported :(
> +i?86*-*-*-64)
> + AC_MSG_ERROR([$host does not support 64 bits]);;
So Darwin's multilib compiler (i386-apple-darwin[89]) is assumed not to
handle 64-bits code here :(
> +*--icc*-32|*--icc*-64)
> + AC_MSG_ERROR([icc does not support a command line option to switch between 32- & 64-bit compilation; use CC & PATH (instead of --enable-bits=$enableval) to point to the $enableval-bit version of icc]);;
> +*-*-*-32|*-*-*-64)
> ;;
> -*) AC_MSG_ERROR(--enable-bits argument must be either 32 or 64);;
> +*)
> + AC_MSG_ERROR(--enable-bits argument must be either 32 or 64);;
Clever one ;)
On Wed, Nov 21, 2007 at 11:07:47AM +0000, Niels Nes wrote:
> Update of /cvsroot/monetdb/sql/src/test/mapi/Tests
> In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv25856
>
> Modified Files:
> Tag: SQL_2-20
> All
> Log Message:
> disabled python_dbapi_embedded as fixing this problem requires an embedded
> api change (ie we should pass more configuration options, ie monetdb_mod_path
> too find sql_server/sql in weird places)
>
> !!! this should not be forwarded to the current branch !!!
propagation of this change has been prevented.
Stefan
> Index: All
> ===================================================================
> RCS file: /cvsroot/monetdb/sql/src/test/mapi/Tests/All,v
> retrieving revision 1.1.2.6
> retrieving revision 1.1.2.7
> diff -u -d -r1.1.2.6 -r1.1.2.7
> --- All 22 Oct 2007 19:58:08 -0000 1.1.2.6
> +++ All 21 Nov 2007 11:07:44 -0000 1.1.2.7
> @@ -8,6 +8,6 @@
> mclient-lsql--help
> HAVE_PERL_SWIG?perl_dbi
> HAVE_PYTHON_SWIG?python_dbapi
> -HAVE_PYTHON_SWIG?python_dbapi_embedded
> +#HAVE_PYTHON_SWIG?python_dbapi_embedded
> HAVE_PHP?php_monetdb
>
>
>
--
| 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 |