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
-
Further restrict the scope of no-exit()-in-libpq test.
- 792259591c0f 15.0 landed
-
Improve build-time check that libpq doesn't call exit().
- 2f7bae2f924d 15.0 landed
-
Fix portability fallout from commit dc227eb82.
- e45b0dfa1f10 15.0 landed
-
Add a build-time check that libpq doesn't call exit() or abort().
- dc227eb82ea8 15.0 landed