git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Daniel Richard G." <skunk@iSKUNK.ORG>
To: "Jeff King" <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: Minor portability issues + fixes
Date: Tue, 19 May 2020 00:22:00 -0400	[thread overview]
Message-ID: <40a42f1d-61bd-46fb-8946-5588df7b044b@www.fastmail.com> (raw)
In-Reply-To: <20200519024945.GB70483@coredump.intra.peff.net>

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@iSKUNK.ORG
My ASCII-art .sig got a bad case of Times New Roman.

  reply	other threads:[~2020-05-19  4:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19  1:15 Minor portability issues + fixes Daniel Richard G.
2020-05-19  2:49 ` Jeff King
2020-05-19  4:22   ` Daniel Richard G. [this message]
2020-05-20  4:28     ` Jeff King
2020-05-21  4:29       ` Daniel Richard G.
2020-05-22 20:03         ` Jeff King
2020-05-19  3:04 ` Carlo Marcelo Arenas Belón
2020-05-19  4:26   ` Daniel Richard G.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40a42f1d-61bd-46fb-8946-5588df7b044b@www.fastmail.com \
    --to=skunk@iskunk.org \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).