Re: NetBSD vs libxml2 - Mailing list pgsql-hackers

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