This is a discussion on configure.in / xml / quoting trouble within the Pgsql Patches forums, part of the PostgreSQL category; --> I found I needed the enclosed patch when configuring today's CVS - I haven't been keeping up since 8.2beta3. ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly |
| |||
| Patrick Welche wrote: > 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? > > > Which in particular are we disbelieving? cheers andrew ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster |
| |||
| Patrick Welche <prlw1@newn.cam.ac.uk> writes: > 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? This proposed change puts CFLAGS into CPPFLAGS; maybe the libxml guys have not understood the difference, but we do. Likewise, I would not expect that all of --libs output is really a good idea to put into LDFLAGS. Exactly what items are you hoping to transfer that aren't transferred by the existing coding? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend |
| |||
| 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 |
| |||
| Patrick Welche wrote: > 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? > > Should a library we are using really be able to set the rpath for us? Are there any other libraries that do that? cheers andrew ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster |
| |||
| Patrick Welche <prlw1@newn.cam.ac.uk> 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. What exactly does xml2-config --libs produce on your machine? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly |
| |||
| 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 |
| |||
| On Thu, Jun 28, 2007 at 04:16:37PM -0400, Tom Lane wrote: > Patrick Welche <prlw1@newn.cam.ac.uk> 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 majordomo@postgresql.org so that your message can get through to the mailing list cleanly |
| |||
| Patrick Welche <prlw1@newn.cam.ac.uk> writes: > 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. I've applied this part. Turned out there was a second bug in the same area: autoconf was stripping the []'s out of the sed regexp, causing it to fail to do anything. Apparently passing a string like "3devel" to awk's "%d" format gets you just "3", but I wonder how portable that behavior is either. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings |
| ||||
| Patrick Welche <prlw1@newn.cam.ac.uk> writes: > On Thu, Jun 28, 2007 at 04:16:37PM -0400, Tom Lane wrote: >> 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, Hm. This doesn't seem like a bright way to be forcing an rpath. The problem is that you have no idea what search order will result when this is combined with any -R we ourselves might have included or will later include into our LDFLAGS. As an example of possible breakage, suppose you are trying to install PG into /opt/postgres and there is already an old version of PG in /usr/local. You've got about a fifty-fifty chance whether the produced binaries will search /opt/postgres/lib before or after /usr/local/lib --- and the second way is wrong, because they'd find the old version of libpq.so. Ugly as it sounds, I think you'd be better off setting the entire Postgres rpath by hand by specifying LDFLAGS to configure. 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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq |