[MonetDB-users] Compilation issue on OS X Panther

(I am not the one with the problem here, but reporting on behalf to stick to the protocol. Please ignore your user agent's default reply to address and send replies to the list, not to me.) The following build error appears for a user that compiles on a Mac: gcc -g -O2 -std=c99 -Wall -W -Werror-implicit-function-declaration -Werror -Wno-format -Wno-unused-function -Wno-unused-label -Wno-uninitialized -D_REENTRANT -o .libs/MapiClient MapiClient.o ReadlineTools.o -L/sw/lib ./.libs/libMapi.dylib /Users/rvjansen/Desktop/MonetDB/src/common/.libs/libstream.dylib -lreadline ../../../common/.libs/libmutils.dylib ../../../common/.libs/libstream.dylib /Users/rvjansen/Desktop/MonetDB/src/common/.libs/libmutils.dylib -lz /sw/lib/libiconv.dylib ld: Undefined symbols: _BZ2_bzclose _BZ2_bzflush _BZ2_bzopen _BZ2_bzread _BZ2_bzwrite make[7]: *** [MapiClient] Error 1 make[6]: *** [all] Error 2 make[5]: *** [all-recursive] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 The user's tools versions: automake 1.9.3 aclocal 1.9.3 autoconf 2.59 libtool ? (there is no --version: default Apple distribution one)

(Why don't you simply set the "reply-to:" header in your posting accordingly?) (I did it with this posting ;-))
Hm, at a first glance, this looks as if libbz[2] was not found by configure, but the code / makefiles do not properly check whether libbz2 is indeed available ... "someone" needs to check this ...
one MacOS/Darwin, we have to use "glibtool". ./bootstrap takes care of this and even tells you the version of [g]libtool ;-) ======== 17:46:48 monet@monet:~/Monet/MonetDB $ uname -a Darwin monet.cs.umass.edu 7.8.0 Darwin Kernel Version 7.8.0: Wed Dec 22 14:26:17 PST 2004; root:xnu/xnu-517.11.1.obj~1/RELEASE_PPC Power Macintosh powerpc 17:46:55 monet@monet:~/Monet/MonetDB $ type -a libtool glibtool libtool is /usr/bin/libtool glibtool is /usr/bin/glibtool 17:47:06 monet@monet:~/Monet/MonetDB $ ./bootstrap using /usr/bin/glibtool and /usr/bin/glibtoolize. automake 1.6.3 is 1.5 or newer. Good. autoconf 2.57 is 2.57 or newer. Good. libtool 1.5 is 1.4 or newer. Good. Python 2.3 is 2.0.0 or newer. Good. [...] ======== More importantly: Which version of MonetDB are we dealing with ??? 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 |

Stefan Manegold wrote:
I don't know what your intentions were, but you set the reply-to to yourself. I expect the mailing list provider to set the stuff correctly, like all those other mailing list providers do (for instance the mozdev mailing lists).
That was my diagnosis also. But I think the appropriate ifdefs are there.
CVS HEAD. tarball stable used to compile, will ask whether it still compiles on updated machine. (Fink was run)

My intention was to make your user agent (respectively the mail protocol) send your reply to both the mailing list and myself "even" if you simply say "reply" and not "group-reply"/"reply-all" or the like. I did this by setting the "Reply-To:" header to both the mailing list address and my own address --- I guess, that's how it is supposed to work ;-) (of course, since I am subscribed and do read this mailing-list, I could have omitted my own address from the "Reply-To:" header ...)
Here's what SF recommends about setting the reply-to automatically: ========= MonetDB-users Mailing list Configuration Help reply_goes_to_list Option reply_goes_to_list (general): Where are replies to list messages directed? Poster is strongly recommended for most mailing lists. This option controls what Mailman does to the Reply-To: header in messages flowing through this mailing list. When set to Poster, no Reply-To: header is added by Mailman, although if one is present in the original message, it is not stripped. Setting this value to either This list or Explicit address causes Mailman to insert a specific Reply-To: header in all messages, overriding the header in the original message if necessary (Explicit address inserts the value of reply_to_address). There are many reasons not to introduce or override the Reply-To: header. One is that some posters depend on their own Reply-To: settings to convey their valid return address. Another is that modifying Reply-To: makes it much more difficult to send private replies. See eply-To' Munging Considered Harmful for a general discussion of this issue. See Reply-To Munging Considered Useful for a dissenting opinion. Some mailing lists have restricted posting privileges, with a parallel list devoted to discussions. Examples are atches' or heckin' lists, where software changes are posted by a revision control system, but discussion about the changes occurs on a developers mailing list. To support these types of mailing lists, select Explicit address and set the Reply-To: address below to point to the parallel list. Where are replies to list messages directed? Poster is strongly recommended for most mailing lists. _X_ Poster ___ This list ___ Explicit address ======== Hence, the point is basically: Since mailman does not seem to allow to extend the Reply-To: header, but only to overwrite it, one should better not touch it ... we can of course set it to "This list" anyway --- I'll check this with Sjoerd on Monday...
More importantly: Which version of MonetDB are we dealing with ???
CVS HEAD.
as of when?
tarball stable used to compile, will ask whether it still compiles on updated machine. (Fink was run)
Yep, this might be valuable info to localize the problem. 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 |

MUAs cannot see what? The "Reply-To:" header? 1) That's another (good) reason for me to stick to my old but reliable elm ;-) 2) If the user simply hits "reply" [s]he doesn't have to "see" the "Reply-To:" header; the mail program should of cause adhere to the protocol and act accordingly! 3) A MUA where the user cannot add/modify (custom) headers IMHO doesn't deserve to be called "MUA".
I'll check with Sjoerd.
Ok. Could you please ask the user[s] to try also the head of the CVS MonetDB_4-6 branch (i.e., MonetDB 4.6.1 iso. MonetDB 4.6.0 or MonetDB 4.7.1)? Thus we could locate the problem to be either in teh changes between the "released" MonetDB 4.6.0 and the "bug-fixed" MonetDB 4.6.1, or between the "bug-fixed" MonetDB 4.6.1 and the "developed" MonetDB 4.7.1 . (Of course, if the "bug-fixed" MonetDB 4.6.1 fails, too, we still don't know, whether the problem is in the code changes between 4.6.0 & 4.6.1, or rather in the fact that the tarball of th previous is pre-bootstrap, while the latter is a CVS check-out that is to be bootstrap --- Hence, instead of checking out the latest MonetDB_4-6 from CVS, you could also send her/him/them the lastest respective tarball: /ufs/monet/Testing/Stable/MonetDB/.GNU_32-d/Fedora3/MonetDB-4.6.1.tar.gz ) 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 |

MUAs cannot see what? The "Reply-To:" header?
Stefan Manegold wrote: they are limited to view one, but can send multiple
Ohw come on... yes there are people that are not common to type 'find x -name "y.z" | xargs grep v' just to find a certain message. :p So, since we're talking about the users-list, we should even be prepared for the worst of all: Microsoft Outlook users. So let's quit whining about MUA's. Now, back to the "real(tm)" problem.
The user[s] need 4.7.1. Well... let's quit pretending all kinds of things. The problem has been solved already. It just compiles again. ! ! ! !Administrator, please cancel my pending message please, as it is not of any use any more. ! ! ! ! ! Sorry, can't help you here.

Hm, at a first glance, this looks as if libbz[2] was not found by configure,
Could you please ask "the user" to check, whether libbz2 was found or not, i.e. send us the output of grep -i bz <monetdb-builddir>/config.status Thanks in advance! 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 |

On Sun, Mar 20, 2005 at 12:24:05AM +0100, Stefan Manegold wrote:
It probably found the include files of lib bz but not the library? 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 Sun, Mar 20, 2005 at 09:55:34AM +0100, Niels Nes wrote:
Temporal solutions 1) install libbz libraries 2) or use configure --without-bz2 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
participants (3)
-
Fabian
-
Niels Nes
-
Stefan.Manegold@cwi.nl