On Mon, Aug 13, 2018 at 11:16:23AM -0400, Tom Lane wrote:
> Well, the issue is that new kinds of switches introduce new potential
> for bugs. In the case of -Wl,-R..., I'm not even sure that you can
> write that more than once per link, so absorbing one from xml2-config
> might well break things on some platforms. Or, if you can write more
> than one, we'd need to make sure they end up in a desirable order.
I forgot to address this. You're absolutely right that -Wl,-R options
could break things. E.g., if you have dependency -lA in one location
and -lB in another, but the second location also has a libA.so that
doesn't match the one used at link-edit time.
The problem here is that ELF, the linker-editor, and the RTLD, don't
really have a way of keeping things together that they should keep
together.
In practice this usually doesn't cause serious problems that users
cannot workaround... For NetBSD in particular this should not cause
problems because NetBSD (presumably!) would not put a libA.so in
/usr/lib and in their ports.
Question: why even separate -lxml2 and the -L and -Wl,-R options into
LIBS and LDFLAGS? Why not put all of them into LIBS and not LDFLAGS?
What would break (aside from the runpath confusion issue)?
After all, why should a user's use of LDFLAGS on the ./configure step
all over xml2-config's --libs?
With ./configure just doing:
LIBS="$LIBS `$XML2_CONFIG --libs`"
and a libxml2 built and installed into /tmp/xpg/, with xml2-config
modified to include -Wl,-rpath=/tmp/xpg, this works correctly:
$ ldd ./src/backend/postgres|grep xml2
libxml2.so.2 => /tmp/xpg/lib/libxml2.so.2 (0x00007fc9ebfd1000)
$ readelf -a ./src/backend/postgres|grep xpg
0x000000000000001d (RUNPATH) Library runpath: [/opt/pg/lib:/tmp/xpg/lib]
$
And while we're here, why is configure parsing the output of xml2-config
--cflags?? That too seems to assume that there will never be any C
compiler options to absorb other than -I or -D. That at least seems
like a safer assumption.
The -l/-L/-R mess is... a mess. It's a shortcoming of ELF, and of the
linker-editors, and the run-time linker-loaders.
Solaris/Illumos has something called "direct linking", whereby ELF
objects record for each symbol which dependency should provide it, and
this speeds up run-time linking and loading significantly. But that
seems insufficiently advanced: ELF should also record for each
dependency where to look for it, not just a one-size-fits-all rpath.
And the CLI for the linker-editor should reflect such a state of affairs
somewhow (e.g., ld ... -lxml2:L/opt/foo/lib:R/opt/foo/lib). The linker-
editor projects move awfully slow.
Nico
--