Re: Minor portability issues + fixes

["Daniel Richard G." <skunk@iSKUNK.ORG>]

On Wed, 2020 May 20 00:28-04:00, Jeff King wrote:
>
> > 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.

> 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.

> > 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.

> You should be able to build with:
> 
>   make CC_LD_DYNPATH=-L
> 
> as a workaround

Yep, this works handily as a no-op :)

> 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.