From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: find libxml2 using pkg-config |
Date: | 2013-03-20 21:17:11 |
Message-ID: | 514A2757.6000606@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/4/13 1:36 PM, Noah Misch wrote:
> Do you have in mind a target system exhibiting a problem? CentOS 6 ships a
> single xml2-config, but its --cflags --libs output is the same regardless of
> the installed combination of libxml2-dev packages. Ubuntu 13.04 does not ship
> 32-bit libxml2, so it avoids the question.
It does, because you can just install the libxml2 package from the
32-bit distribution. (So there will no longer be packages in the 64-bit
distribution that actually contain 32-bit code, at least in the long run.)
But pack to the main question: Stock systems probably won't exhibit the
problem, because they just dodge the problem by omitting the -L option
from the xml2-config output and rely on the default linker paths to do
the right thing. But if you use a nondefault libxml2 install or a
nondefault compiler, interesting things might start to happen.
I think at this point, the issue is probably too obscure, and the people
affected by it hopefully know what they are doing, so it might not be
important in practice. In light of the other flaws that you have
pointed out, I'd be fine with withdrawing this patch for now. But we
should keep an eye on the situation.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-03-20 21:22:38 | Re: machine-parseable object descriptions |
Previous Message | Tom Lane | 2013-03-20 19:13:02 | Re: Let's invent a function to report lock-wait-blocking PIDs |