Re: peripatus build failures....

From: Larry Rosenman <ler(at)lerctr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: peripatus build failures....
Date: 2018-07-07 16:05:00
Message-ID: 20180707160500.6tjsf6dpl56lt5qs@ler-imac.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jul 07, 2018 at 11:24:48AM -0400, Tom Lane wrote:
> Larry Rosenman <ler(at)lerctr(dot)org> writes:
> > On Sat, Jul 07, 2018 at 11:11:24AM -0400, Tom Lane wrote:
> >> Larry Rosenman <ler(at)lerctr(dot)org> writes:
> >>> f044d71e331d77a0039cec0a11859b5a3c72bc95 fixed it.
>
> >> Don't think I believe that conclusion; that patch shouldn't
> >> have affected anything at all for non-ARM architectures.
>
> > Those are the 2 adjacent commits in src/port.
>
> You're assuming something not in evidence, which is that the critical
> change was textually within src/port/. It might have been in configure,
> for instance, or in Makefile.global, or some other upper-level makefile.
> I'd just do a straight bisect run without any assumptions about which part
> of the tree matters.
>
> regards, tom lane

And the winner is:

dddfc4cb2edcfa5497f5d50190a7fb046c51da16 is the first bad commit
commit dddfc4cb2edcfa5497f5d50190a7fb046c51da16
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Tue Apr 3 16:26:05 2018 -0400

Prevent accidental linking of system-supplied copies of libpq.so etc.

We were being careless in some places about the order of -L switches in
link command lines, such that -L switches referring to external directories
could come before those referring to directories within the build tree.
This made it possible to accidentally link a system-supplied library, for
example /usr/lib/libpq.so, in place of the one built in the build tree.
Hilarity ensued, the more so the older the system-supplied library is.

To fix, break LDFLAGS into two parts, a sub-variable LDFLAGS_INTERNAL
and the main LDFLAGS variable, both of which are "recursively expanded"
so that they can be incrementally adjusted by different makefiles.
Establish a policy that -L switches for directories in the build tree
must always be added to LDFLAGS_INTERNAL, while -L switches for external
directories must always be added to LDFLAGS. This is sufficient to
ensure a safe search order. For simplicity, we typically also put -l
switches for the respective libraries into those same variables.
(Traditional make usage would have us put -l switches into LIBS, but
cleaning that up is a project for another day, as there's no clear
need for it.)

This turns out to also require separating SHLIB_LINK into two variables,
SHLIB_LINK and SHLIB_LINK_INTERNAL, with a similar rule about which
switches go into which variable. And likewise for PG_LIBS.

Although this change might appear to affect external users of pgxs.mk,
I think it doesn't; they shouldn't have any need to touch the _INTERNAL
variables.

In passing, tweak src/common/Makefile so that the value of CPPFLAGS
recorded in pg_config lacks "-DFRONTEND" and the recorded value of
LDFLAGS lacks "-L../../../src/common". Both of those things are
mistakes, apparently introduced during prior code rearrangements,
as old versions of pg_config don't print them. In general we don't
want anything that's specific to the src/common subdirectory to
appear in those outputs.

This is certainly a bug fix, but in view of the lack of field
complaints, I'm unsure whether it's worth the risk of back-patching.
In any case it seems wise to see what the buildfarm makes of it first.

Discussion: https://postgr.es/m/25214.1522604295@sss.pgh.pa.us

:040000 040000 49374c1617930b2ff57015188d2f06ff15198fb0 c07d24d934ac3f8e8a60e533953b1ea1a1411824 M contrib
:040000 040000 d00cbb0746730fabc32828a839033fbe6bb1aba8 51f1c15d4802aaae90e527eeca38611b73802f47 M src
borg.lerctr.org /home/ler/Git/postgresql $
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: ler(at)lerctr(dot)org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2018-07-07 17:12:58 Re: How can we submit code patches that implement our (pending) patents?
Previous Message Tom Lane 2018-07-07 15:24:48 Re: peripatus build failures....