On Sat, Aug 11, 2018 at 01:18:26PM -0400, Tom Lane wrote: > In a moment of idle curiosity, I tried to build PG --with-libxml > on NetBSD-current (well, mostly current, from May or so). > The configure script blew up, complaining that it couldn't execute > a test program. Investigation showed that xml2-config reports this: > > $ xml2-config --libs > -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lxml2 -L/usr/lib -lz -L/usr/lib -llzma > -L/usr/lib -lm > > and we're only paying attention to the -L switches out of that. > So we successfully link to /usr/pkg/lib/libxml2.so, but then > execution fails for lack of rpath pointing at /usr/pkg/lib. > > We could fix this by teaching configure to absorb -Wl,-R... switches > into LDFLAGS from xml2-config's output, and that seems to make things > work, but I wonder whether we should or not. This seems like a new height > of unfriendliness to non-default packages on NetBSD's part, and it's a bit > hard to believe the behavior will make it to a formal release. I don't > see any comparable behavior on FreeBSD for instance --- it puts packages' > libraries into /usr/local/lib, but that seems to be searched automatically > without additional switches beyond -L. Don't have an easy way to check > things on OpenBSD. > > Thoughts?
-Wl,-R (and friends, like -Wl,-rpath) is part and parcel of dynamic linking, and are precious. All software should honor these. That non-default packages don't end up in /usr is a perfectly legitimate thing for a distribution to do. More importantly, a site-build that uses a non-system location for e.g. locally-patched open source packages, is a perfectly legitimate thing for _users_ to do. It isn't nice to force them to hack a project's ./configure file or work out precious envvar settings to make that project support non-system locations for dependencies. I guess the problem here is that xml2-config is (like so many *-config programs) broken by not having a way to get ld flags and libs separately... Which would be why ./configure is parsing the output of xml2-config --libs. The better thing to do would be to take all the words from xml2-config --libs that match -l* and put them in LIBS while all others go into LDFLAGS. It's safer to assume that -l* means "link this in" than that there won't be new linker options other than -L or -l. I'll note too that -lxml2 is hardcoded in ./configure.in. That's not right either. IMO this is just a minor bug in PG. I'm willing to write a patch after lunch. In ./configure.in this: for pgac_option in `$XML2_CONFIG --libs`; do case $pgac_option in -L*) LDFLAGS="$LDFLAGS $pgac_option";; esac done should change to: for pgac_option in `$XML2_CONFIG --libs`; do case $pgac_option in -l*) LDLIBS="$LDLIBS $pgac_option";; *) LDFLAGS="$LDFLAGS $pgac_option";; esac done More changes are needed to stop hard-coding -lxml2. I can write a patch if you like. Nico --