Re: Preventing abort() and exit() calls in libpq
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Jacob Champion <pchampion@vmware.com>,
"daniel@yesql.se" <daniel@yesql.se>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
"michael@paquier.xyz" <michael@paquier.xyz>
Date: 2021-07-01T18:14:24Z
Lists: pgsql-hackers
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: > On 01.07.21 00:41, Jacob Champion wrote: >> Spitballing -- if you don't like the stamp file, you could add the >> check to the end of the $(shlib) rule, surrounded by an ifeq check. >> Then .DELETE_ON_ERROR should take care of the rest, I think. > 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. regards, tom lane
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