Re: Host requirements to build the Tools binaries

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 16 Aug 2024 04:31:37 +0900
    From:        Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
    Message-ID:  <240816043137.M0100237%mirage.ceres.dti.ne.jp@localhost>

  | I'm not sure if there is any definitions or standards for
  | the _XOPEN_SOURCE macro,

As it is something that needs to be defined by applications,
the standard more defines what it is to be defined as, and when,
rather than defining it.

As my long message said, if you were brave (foolish) enough to attempt
to read the whole thing, XBD 2.2.4 bullet point 8 says:

     8. For the C programming language, shall define _XOPEN_SOURCE
        to be 800 before any header is included

That's one of the requirements to become a strictly conforming XSI
application.   (Perhaps a different value than 800 if you only need
an older version).

  | but I had to resolve an issue
  | "how can we use both strptime(3) (XPG4) and timegm(3) (GNU extension)
  |  among all Linux, NetBSD, FreeBSD, and OpenBSD?"

  | Newer GCC14 no longer allows implicit function declarations.

That's fine.

  | Linux requires _XOPEN_SOURCE to pull strptime(3) in <time.h>.

That's OK, it is permitted.

  | NetBSD (and maybe FreeBSD and OpenBSD) hides timegm(3)
  | if _XOPEN_SOURCE is defined.

That's OK too, and arguably the right thing to do.   Otherwise an
application intending to be a strictly conforming XSI application
might call timegm() (and lots of other stuff) without that being
detected.

  | On NetBSD, all declarations are visible by default

That's what the standards treat as an undefined case (not explicitly
defining any of the feature macros), the implementation can do just
about anything - NetBSD has chosen to make life simple for programmers
(for NetBSD applications on NetBSD).

  | (unless _XOPEN_SOURCE, _POSIX_C_SOURCE, or _ANSI_SOURCE is defined).

Unless only one of those is defined.   The preferred way to solve
this issue is

	-D_XOPEN_SOURCE=800 -D_NETBSD_SOURCE

(and if you need it, -D_GNU_SOURCE as well).   Of course, those could
alternatively be #define macro definitions in each .c file (or in a
local include file included before anything else) that appear before
any #include for any of the standard headers.

_NETBSD_SOURCE is unlikely to do anything on Linux systems,
_GNU_SOURCE is (I hope) unlikely to do anything for standard NetBSD
applications on NetBSD (ie: not including packages using glibc, for
which anything is possible) so including both of those, and perhaps
others for other systems, should harm nothing - the one that is needed
for a particular system will make things available, the others should
do nothing.

_XOPEN_SOURCE makes sure the XSI functions (including strptime())
are available if the implementation provides them (you still need to test
for that - defining the symbol cannot add functions to a libc which
does not contain them.)

The order in which these are defined is (kind of obviously) immaterial,
as none depends upon any of the others - and once defined all any later
code can do is test to see if they're defined, or have a particular value,
there's no way to test which order two independent macros were defined.

timegm() is to be (or is already perhaps) in C23 I think, but there is no
POSIX specified way to ask for it - there is not a lot of support for C23 yet,
POSIX 2024 only expects C17 support, so there's no real standard way yet
to ensure new C23 functions are available (or test for one).   Of course
timegm() has been around for decades, and is available almost everywhere.
"almost".

  | Then I wrote "_GNU_SOURCE for glibc might work."
  | That's all.

Apologies if it appeared that I was particularly replying to your mail.
I was really replying to the whole thread - and when I started (composing
that reply took a long time) your message was the most recent in the
thread, and what's more, contained useful information I could use as a
jumping off point.   No criticisms (of anyone) intended (when I do that
it is generally blatant.)

kre