Re: Minor portability issues + fixes

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

 



Hi Jeff,

On Mon, 2020 May 18 22:49-04:00, Jeff King wrote:
> 
> All system defines in Git should be pulled in via git-compat-util.h.
> That does include stdint.h, but only if NO_INTTYPES_H is defined
> (otherwise we prefer inttypes.h). And POSIX (2004) says:
> 
>   The <inttypes.h> header shall include the <stdint.h> header.
> 
> But perhaps that is not so on AIX (it wouldn't be the first time we've
> seen a platform that does not strictly follow POSIX).

On AIX 4.3, where I am building, inttypes.h does not #include stdint.h,
and stdint.h is not present under /usr/include/. (This is an old system
used for ABI compatibility-testing purposes.)

This is not general to AIX, however, because on 5.3, both stdint.h and
its #include are there.

That said, my build is using GCC 4.7, which provides a modern stdint.h.
The GCC tree contains a fixincluded version of inttypes.h, but this also
lacks the <stdint.h> #include.

> Does building with:
> 
>   make NO_INTTYPES_H=YesPlease
> 
> work?
>
> 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.

> > Setting that variable to an empty value causes a bare directory to be
> > passed to the linker, which of course then errors out. I would suggest
> > setting it to "-L" instead.
> 
> That would just be redundant with the earlier argument. That might be
> the easiest way to turn it into a noop, but we can probably do better
> with $(if) or similar, which would allow somebody to build with:
> 
>   make CC_LD_DYNPATH=
> 
> even without using the autoconf script.

That is a fair point. CC_LD_DYNPATH is used only a handful of times, so
this wouldn't be much more work.

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

       libpath:Path
            Uses Path as the library path when writing the loader
            section of the output file. Path is neither checked for
            validity nor used when searching for libraries specified by
            the -l flag. Path overrides any library paths generated when
            the -L flag is used.

            If you do not specify any -L flags, or if you specify the
            nolibpath option, the default library path information is
            written in the loader section of the output file. The
            default library path information is the value of the LIBPATH
            environment variable if it is defined, and /usr/lib:/lib,
            otherwise.

(excerpted from an AIX 7.1 system)

That implies that when you use this option, you must specify not only
the path you're interested in, but also /usr/lib:/lib! And when I look
at an existing AIX build of ours, that makes use of Libtool, I see that
it is in fact passing in a rather lengthy path for -Wl,-blibpath:, that
ends with ":/usr/lib:/lib".


--Daniel


-- 
Daniel Richard G. || skunk@xxxxxxxxxx
My ASCII-art .sig got a bad case of Times New Roman.



[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