Re: Minor portability issues + fixes
- From
Daniel Richard G. <skunk@iskunk.org>
- Date
- May 21, 2020, 04:29 UTC
- Message-ID
- <86f751ac-b7c1-43fd-ada5-a8e2e9c4ebc9@www.fastmail.com>
- In-Reply-To
- <20200520042838.GA102274@coredump.intra.peff.net>
On Wed, 2020 May 20 00:28-04:00, Jeff King wrote:
Show 12 quoted lines
> > > I've confirmed that this works. But would it not be safe to #include > > both inttypes.h and stdint.h explicitly if both are present, rather than > > cater to AIX specifically? I could see this similarly arising in, say, > > an old version of Solaris. > > Yes, as long as we check that both are present, I think that would do > the right thing. And the autoconf check could cover that. I don't think > there's an easy way to have a general Makefile knob that can check which > files are present, though (and we generally consider the Makefile and > its knobs to be the primary mechanism; autoconf to turn those knobs is > generally implemented on top).
Okay, I see, so the whole phalanx of HAVE_BLAH_H symbols from Autoconf isn't available.
Show 16 quoted lines
> So probably we'd want something like (in this order): > > - NEEDS_EXPLICIT_STDINT gets passed from the Makefile into the > compiler via -D, which then triggers stdint.h being included > unconditionally in git-compat-util.h > > - optionally set that in config.mak.uname for AIX (checking uname_R > since it sounds like only old versions need it) > > - add an autoconf rule that sets it, either strictly (when a > test-program decides it's needed) or loosely (when we see that it's > available at all) > > Even just the first one would let you build by setting the knob > manually; the rest is gravy on top, if you or somebody else chooses to > do it.
Hmm... that's a fairly specific knob, which I would think is less than ideal. The rest is reasonable, but would have to be written in terms of the knob.
I can put something together, knowing that this is the approach you'd want to see, but it'll need some more work. Eventually, I'll need to get Git up and running on a few other old systems I have here, so that will undoubtedly figure into it.
Thanks for sketching out how this should work, however; this is helpful to keep in mind.
Show 7 quoted lines
> > The applicable value for CC_LD_DYNPATH on AIX is "-Wl,-blibpath:". > > However, have a look at the description for this option in the > > ld(1) man page: > > OK, gross. :) I agree it's not worth going too far into this rabbit > hole. I do wonder if you could just be using GNU ld along with gcc, but > maybe that's not practical.
Using the GNU linker can help in some cases, and hurt in others. We try to avoid it unless necessary.
Show 5 quoted lines
> You should be able to build with: > > make CC_LD_DYNPATH=-L > > as a workaround
Yep, this works handily as a no-op :)
Show 16 quoted lines
> but it would be nice if the Makefile handled this correctly. It looks > like CC_LD_DYNPATH gets used in a lot of places, so I suspect we'd > want a Makefile function to help out. Something like: > > # usage: $(call linker_lib,PATH) > # Create linker args for looking for libraries in PATH at both link-time > # and run-time. > linker_lib = -L$1 $(if $(CC_LD_DYNPATH),$(CC_LD_DYNPATH)$1) > > which would allow: > > EXTLIBS += $(call linker_lib,$(LIBPCREDIR)/$(lib)) > > etc. This would be our first foray into Makefile functions, but I think > we've determined that most platforms have a recent enough GNU make for > it to be OK (and we already require GNU make).
Why not just a variable to wrap the conditional? Something like
CC_LD_DYNPATH_flag = $(if $(CC_LD_DYNPATH),$(CC_LD_DYNPATH),-L)
...
EXTLIBS += -L$(ZLIB_PATH)/$(lib) $(CC_LD_DYNPATH_flag)$(ZLIB_PATH)/$(lib)
Makefile functions are quite powerful, but they feel like a sledgehammer to this fly. (I've used them in the past to generate Make rules programmatically. It wasn't pretty, but it sure beat writing out makefile fragments and then include-ing them afterward!)
--Daniel
-- Daniel Richard G. || skunk@iSKUNK.ORG My ASCII-art .sig got a bad case of Times New Roman.