Thread: 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

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

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

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

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

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

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

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

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

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

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

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.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e@gmx.net> 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.

            regards, tom lane

On Fri, Jul 20, 2007 at 09:37:15AM -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> 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

Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> Also, what was the danger with linking pthread?

Basically, the worry with code that wants thread support is that it
might actually try to use that support, and the backend in general will
not survive that (no threading protections).  Also, depending on your
platform, linking in thread support might incur some generalized
overhead costs even when it's not being used; for instance the malloc
functions might start using mutexes.

            regards, tom lane