Re: NetBSD vs libxml2

[Quoting out of order.]

On Mon, Aug 13, 2018 at 11:16:23AM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>
> I'm not, personally, eager to do that work for a requirement which
> somehow hasn't surfaced on any other platform, nor on any previous
> NetBSD release. I think NetBSD is way out in left field here.

It's not just about the distros. It's also about sites that build and
install alternate versions of things that PG might depend on. I've seen
that many times. It is PG that is being hostile to them, not NetBSD
that is being hostile to PG.

Building PG outside a distro, with libxml2 outside a distro, ought to be
possible, but currently isn't without hacking on PG. That's not good.

In any case, the patch I posted is trivial and small and should do the
job.

> > I kind of agree with Nico: why do we think we get to tell operating
> > system distributions which switches they're allowed to need to make
> > things work? The point of things like pg_config and xmlconfig is to
> > reveal what is needed. If we editorialize on that, we do so at our
> > own risk.
>
> 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.
> (cf commit dddfc4cb2 which fixed similar issues for -L switches;
> it looks to me like the current coding would in fact fail to order
> our $(rpath) correctly against one absorbed from xml2, and it would
> not be trivial to fix that.)

I believe no new options have _ever_ been added to linker-editors for
specifying dependencies, but lots of options for other purposes have
been added over the last several decades.

The link-editors are free to add new linker options. There is nothing
we can do about that.

The fundamental problem here is that *-config programs should have had
separate --libs and --ldflags options, but don't, obligating us (and
others too) to parse the output of the --libs option.

What we need is an approach to parsing the output of the --libs option
that is likely to be more stable. I believe looking for words that
start with -l is better than looking for words that start with -L,
because there haven't been new ways to specify dependencies ever, but
there have been tons of new linker-editor options for other things. It
follows that this approach should be more stable.

And yes, I understand that if the linker-editors ever add new options
for specifying dependencies then we'll be here again. It just seems a)
unlikely, b) not that burdensome if it does ever happen.

Aside: It is truly shocking that in a world where, for better or worse,
autoconf is so prevalent, *-config programs still fail to
separate --libs and --ldflags. After all, the separation of
LIBS (not precious) and LDFLAGS (precious), is very much a
tradition in autoconf'ed projects, and autoconf very much
supports it.

Nico
--