Re: Minor portability issues + fixes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 19, 2020 at 12:22:00AM -0400, Daniel Richard G. wrote:

> > If so, then perhaps it should be added to the AIX defines in
> > config.mak.uname.
> 
> 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).

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.

> > I do wonder, though, if configure.ac could be extended for AIX to
> > support whatever syntax the system linker uses for setting the run-path.
> > I understand that you don't care either way about this feature, but this
> > might be a good opportunity to fix it.
> 
> This could be a bit complicated, I'm afraid.
> 
> 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.

You should be able to build with:

  make CC_LD_DYNPATH=-L

as a workaround, 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).

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux