[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)
(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.)
(Why don't you simply set the "reply-to:" header in your posting accordingly?) (I did it with this posting ;-))
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
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 ...
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)
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
Stefan Manegold wrote:
(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.)
(Why don't you simply set the "reply-to:" header in your posting accordingly?) (I did it with this posting ;-))
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).
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 ...
That was my diagnosis also. But I think the appropriate ifdefs are there.
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)
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 ???
CVS HEAD.
tarball stable used to compile, will ask whether it still compiles on updated machine. (Fink was run)
Stefan Manegold wrote:
(Why don't you simply set the "reply-to:" header in your posting accordingly?) (I did it with this posting ;-))
I don't know what your intentions were, but you set the reply-to to yourself.
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 ...)
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).
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...
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 ...
That was my diagnosis also. But I think the appropriate ifdefs are there.
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
Stefan Manegold wrote:
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 ...)
Although in the RFC, modern MUAs cannot see it, neither craft messages like that.
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...
yes, it should be This list.
as of when?
now 2 days ago
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.
The stable tarbal compiles fine without any problem.
Stefan Manegold wrote:
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 ...)
Although in the RFC, modern MUAs cannot see it, neither craft messages like that.
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".
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...
yes, it should be This list.
I'll check with Sjoerd.
as of when?
now 2 days ago
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.
The stable tarbal compiles fine without any problem.
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
Stefan Manegold wrote:
MUAs cannot see what? The "Reply-To:" header?
they are limited to view one, but can send multiple
- That's another (good) reason for me to stick to my old but reliable elm ;-)
- 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!
- A MUA where the user cannot add/modify (custom) headers IMHO doesn't deserve to be called "MUA".
A program that can customize all of the headers is called 'telnet'. A User Agent simply acts on behalf of the user to do some standard tasks. The RFC nowhere mentions that a MUA should be able to produce all kinds of headers available in the protocol.
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 stable tarbal compiles fine without any problem.
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 )
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
On Sun, Mar 20, 2005 at 12:24:05AM +0100, Stefan Manegold wrote:
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
It probably found the include files of lib bz but not the library?
Niels
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 |
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On Sun, Mar 20, 2005 at 09:55:34AM +0100, Niels Nes wrote:
On Sun, Mar 20, 2005 at 12:24:05AM +0100, Stefan Manegold wrote:
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
It probably found the include files of lib bz but not the library?
Indeed in case of auto checking for lib bz (and probably other libs), the *_CFLAGS isn't reset in case the libraries aren't found.
Temporal solutions 1) install libbz libraries 2) or use configure --without-bz2
Niels
Niels
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 |
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
--
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
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
participants (3)
-
Fabian -
Niels Nes -
Stefan.Manegold＠cwi.nl