Re: Preventing abort() and exit() calls in libpq

Jacob Champion <pchampion@vmware.com>

From: Jacob Champion <pchampion@vmware.com>
To: "peter.eisentraut@enterprisedb.com" <peter.eisentraut@enterprisedb.com>, "tgl@sss.pgh.pa.us" <tgl@sss.pgh.pa.us>
Cc: "daniel@yesql.se" <daniel@yesql.se>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "michael@paquier.xyz" <michael@paquier.xyz>
Date: 2021-07-01T18:21:04Z
Lists: pgsql-hackers
On Thu, 2021-07-01 at 14:14 -0400, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> > Somewhere in the $(shlib) rule would seem most appropriate.  But I don't 
> > understand the rest: What ifeq, and why .DELETE_ON_ERROR?
> 
> The variant of this I'd been thinking of was
> 
>  $(shlib): $(OBJS) | $(SHLIB_PREREQS)
>  	$(LINK.shared) -o $@ $(OBJS) $(LDFLAGS) $(LDFLAGS_SL) $(SHLIB_LINK)
> +ifneq (,$(SHLIB_EXTRA_ACTION))
> +	$(SHLIB_EXTRA_ACTION)
> +endif
> 
> (and similarly in several other places); then libpq's Makefile
> could set SHLIB_EXTRA_ACTION to the desired thing.
> 
> The problem then is, what happens when the extra action fails?
> Without .DELETE_ON_ERROR, the shlib is still there and the next
> make run will think everything's good.

Yep, that was pretty much what was in my head. ifeq (or ifneq in your
example) to gate the extra nm check, and .DELETE_ON_ERROR to make the
failure stick for future make invocations.

--Jacob

Commits

  1. Further restrict the scope of no-exit()-in-libpq test.

  2. Improve build-time check that libpq doesn't call exit().

  3. Fix portability fallout from commit dc227eb82.

  4. Add a build-time check that libpq doesn't call exit() or abort().