Re: [PATCHES] configure.in / xml / quoting trouble
On Fri, Jul 20, 2007 at 09:37:15AM -0400, Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Am Freitag, 20. Juli 2007 13:28 schrieb Patrick Welche: > >> Also, why did postgresql choose not to use automake? > > > The was never such a choice made. > > According to the archives, it was brought up a couple times around the > 1999-2000 time frame, but no one ever made a case that it'd be worth the > pain of changing over. At the time, we had subprojects in the tree with > their own configure/build systems (odbc, libpqxx) and I think > automake-ification was considered a way to try to clean that situation > up. But now it's been resolved by kicking the subprojects out again, > and so I don't really see that automake has much to offer us. OK - I was just playing with that libxml2 problem with a test project, and somehow the linking went correctly and used the right flags. It seems (not tested to the extremes) that I just got "do the right thing with libxml2.la" for free (i.e., use libtool --mode=link) just by having used automake. (I'll look at that a bit more to make sure.) Also, what was the danger with linking pthread? (I do see a --with-threads add multithread support(on) switch to turn it off in libxml2) Cheers, Patrick ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] configure.in / xml / quoting trouble
On Fri, Jun 29, 2007 at 12:35:44PM -0400, Tom Lane wrote: > The other thing that's a bit strange here is the reference to > libpthread --- does libxml2 really depend on that? I'd definitely > advise against linking libpthread into the backend if you can > avoid it. Just out of curiosity, why should one avoid linking libpthread? Also, why did postgresql choose not to use automake? Cheers, Patrick ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] configure.in / xml / quoting trouble
On Thu, Jun 28, 2007 at 04:16:37PM -0400, Tom Lane wrote: > Patrick Welche <[EMAIL PROTECTED]> writes: > > The thing is, if xml2-config is meant to give the flags necessary to > > compile a programme with libxml, then why pick-and-choose which flags > > you are going to use? > > Well, if they gave the flags in a sane format (distinguishing CPPFLAGS > from CFLAGS, and LDFLAGS from LIBS), then we could just use them as-is. > They don't, so we have to do some picking-apart. Fair point - I will try to use libxml2.la instead, as libtool knows how to link to shared libraries portably. (Begs a question on how ac_check_lib would cope, but I need to look into that more.) > What exactly does xml2-config --libs produce on your machine? -Wl,-R/usr/local/lib -L/usr/local/lib -lxml2 -lz -lpthread -lm but because I added the -R - it isn't the default as distributed, but seemed to be the right place to store the flags I need to link to libxml. So, feel free to drop the first part of that patch... Cheers, Patrick ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] configure.in / xml / quoting trouble
On Thu, Jun 28, 2007 at 03:41:57PM -0400, Andrew Dunstan wrote: > Should a library we are using really be able to set the rpath for us? Are > there any other libraries that do that? After further thought, I should use the libxml2.la which libxml does install by default - libtool knows what the flags should be - rather than xml2-config which I have had to change on my system to include the -rpath. I need to think about this some more... Cheers, Patrick ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] configure.in / xml / quoting trouble
On Thu, Jun 28, 2007 at 02:39:37PM -0400, Andrew Dunstan wrote: > Patrick Welche wrote: > >The first part I needed when configuring --with-libxml. Why go to the > >effort of finding xml2-config, and then disbelieve what it tells you? > > Which in particular are we disbelieving? The one that broke things for me in NetBSD is the rpath flag that got ignored. The thing is, if xml2-config is meant to give the flags necessary to compile a programme with libxml, then why pick-and-choose which flags you are going to use? I suppose I see two extremes, either you look for foo-config and use its flags, or you leave it up to the user to fill in CFLAGS/LDFLAGS/CPPFLAGS appropriately (maybe with the aid of --with-libxml=[directory]) (and ac_check_lib). I was caught out as the current configure.in seems to be a bit of both. Cheers, Patrick ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] configure.in / xml / quoting trouble
I found I needed the enclosed patch when configuring today's CVS - I haven't
been keeping up since 8.2beta3.
The first part I needed when configuring --with-libxml. Why go to the
effort of finding xml2-config, and then disbelieve what it tells you?
The second part is a shell quoting problem. As the printf is inside
single quotes, the double quotes don't need to be escaped. My awk
received the backslashes and complained.
Cheers,
Patrick
Index: configure.in
===
RCS file: /projects/cvsroot/pgsql/configure.in,v
retrieving revision 1.515
diff -u -r1.515 configure.in
--- configure.in4 Jun 2007 21:55:43 - 1.515
+++ configure.in28 Jun 2007 18:18:10 -
@@ -571,16 +571,8 @@
if test "$with_libxml" = yes ; then
AC_CHECK_PROGS(XML2_CONFIG, xml2-config)
if test -n "$XML2_CONFIG"; then
-for pgac_option in `$XML2_CONFIG --cflags`; do
- case $pgac_option in
--I*|-D*) CPPFLAGS="$CPPFLAGS $pgac_option";;
- esac
-done
-for pgac_option in `$XML2_CONFIG --libs`; do
- case $pgac_option in
--L*) LDFLAGS="$LDFLAGS $pgac_option";;
- esac
-done
+CPPFLAGS="$CPPFLAGS `$XML2_CONFIG --cflags`"
+LDFLAGS="$LDFLAGS `$XML2_CONFIG --libs`"
fi
fi
@@ -698,7 +690,7 @@
# awk -F is a regex on some platforms, and not on others, so make "." a tab
PG_VERSION_NUM="`echo "$PACKAGE_VERSION" | sed 's/[A-Za-z].*$//' |
tr '.' ' ' |
-$AWK '{printf \"%d%02d%02d\", $1, $2, (NF >= 3) ? $3 : 0}'`"
+$AWK '{printf "%d%02d%02d", $1, $2, (NF >= 3) ? $3 : 0}'`"
AC_DEFINE_UNQUOTED(PG_VERSION_NUM, $PG_VERSION_NUM, [PostgreSQL version as a
number])
##
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [PATCHES] COPY FROM performance improvements
On Thu, Jul 21, 2005 at 09:19:04PM -0700, Luke Lonergan wrote: > Joshua, > > On 7/21/05 7:53 PM, "Joshua D. Drake" <[EMAIL PROTECTED]> wrote: > > Well I know that isn't true at least not with ANY of the Dells my > > customers have purchased in the last 18 months. They are still really, > > really slow. > > That's too bad, can you cite some model numbers? SCSI? I would be interested too, given http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=30531 Cheers, Patrick ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
