1. Forum
  2. Usenet
  3. COMP.OS.MSDOS.DJGPP

  • __STRICT_ANSI__ and excluded definitions

    From DJ Delorie@21:1/5 to All on Mon Nov 30 12:52:56 2020
    Best thing to do is to file a bug with gcc and let them language-lawyer
    it out.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to DJGPP List (E-mail) on Mon Nov 30 19:40:50 2020
    Noticed that I'm failing to build recent GIT version of GCC for DJGPP due to different
    interpretation of presence of macro __STRICT_ANSI__=1 in Linux and DJGPP

    For example sys/type.h from DJGPP excludes definitions in case of __STRICT_ANSI__ defined. For
    Linux I'm seeing:

    Tried versions:  gcc-10.2.0, clang-11.0.0


    Presence of __STRICT_ANSI__:

    [andris@ap gcc]$ echo '#include <sys/types.h>' | gcc -dD -E -x c -ansi - | grep STRICT_ANSI
    #define __STRICT_ANSI__ 1
    [andris@ap gcc]$ echo '#include <sys/types.h>' | clang -dD -E -x c -ansi - | grep STRICT_ANSI
    #define __STRICT_ANSI__ 1


    Examples of definitions excluded for DJGPP (tested with clang for C, one is getting the same with GCC)

    [andris@ap gcc]$ echo '#include <sys/types.h>' | clang -dD -E -x c -ansi - | grep dev_t
    typedef unsigned long int __dev_t;
    typedef __dev_t dev_t;
    #define __dev_t_defined
    [andris@ap gcc]$ echo '#include <sys/types.h>' | clang -dD -E -x c -ansi - | grep ino_t
    typedef unsigned long int __ino_t;
    typedef __ino_t ino_t;
    #define __ino_t_defined


    One question is of course what is correct behavior according to language standard.

    Easiest would be to behave similarly as Linux implementation.

    One could also test other implementations (for example from Microsoft).

    Current absence of these definitions (dev_t and ino_t as the first) breaks building GCC libcpp (GIT
    trunk from 2020-11-28). I do not known whether  there are other definitions excluded for DJGPP that
    would be required. I can only suspect that more are coming with time.


    Andris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Mon Nov 30 20:18:49 2020
    From: "Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com]" <djgpp@delorie.com>
    Date: Mon, 30 Nov 2020 19:40:50 +0200

    Noticed that I'm failing to build recent GIT version of GCC for DJGPP due to different
    interpretation of presence of macro __STRICT_ANSI__=1 in Linux and DJGPP

    Why is __STRICT_ANSI__ important for _building_ GCC? Does the build
    use some compiler switch that forces __STRICT_ANSI__?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to DJ Delorie on Mon Nov 30 20:25:13 2020
    On 11/30/20 7:52 PM, DJ Delorie wrote:
    Best thing to do is to file a bug with gcc and let them language-lawyer
    it out.

    I mentioned as example the behavior in Linux. In this case its glibc implementation stuff not even
    gcc one:

    - gcc or clang only defines __STRICT_ANSI__

    - glibc headers causes definitions of pid_t and ino_t and other stuff not to be excluded

    Another question whether specifying for example -std=c++11 (which implies __STRICT_ANSI__) also
    implies ANSI C  for used C headers.

    We have also disabled excluding some definitions when both __STRICT_ANSI__ and __plusplus are
    defined in some places (for example stdio.h)


    Andris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Mon Nov 30 21:00:42 2020
    From: "Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com]" <djgpp@delorie.com>
    Date: Mon, 30 Nov 2020 20:25:13 +0200

    On 11/30/20 7:52 PM, DJ Delorie wrote:
    Best thing to do is to file a bug with gcc and let them language-lawyer
    it out.

    I mentioned as example the behavior in Linux. In this case its glibc implementation stuff not even
    gcc one:

    - gcc or clang only defines __STRICT_ANSI__

    - glibc headers causes definitions of pid_t and ino_t and other stuff not to be excluded

    Another question whether specifying for example -std=c++11 (which implies __STRICT_ANSI__) also
    implies ANSI C  for used C headers.

    IME, no useful program can be compiled with strict ANSI, so using
    -std=c++11 when building a compiler is counter-productive. I'd
    suggest to try -std=gnu++11 instead.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Mon Nov 30 21:55:58 2020
    On 11/30/20 9:00 PM, Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com] wrote:
    From: "Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com]" <djgpp@delorie.com>
    Date: Mon, 30 Nov 2020 20:25:13 +0200

    On 11/30/20 7:52 PM, DJ Delorie wrote:
    Best thing to do is to file a bug with gcc and let them language-lawyer
    it out.
    I mentioned as example the behavior in Linux. In this case its glibc implementation stuff not even
    gcc one:

    - gcc or clang only defines __STRICT_ANSI__

    - glibc headers causes definitions of pid_t and ino_t and other stuff not to be excluded

    Another question whether specifying for example -std=c++11 (which implies __STRICT_ANSI__) also
    implies ANSI C  for used C headers.
    IME, no useful program can be compiled with strict ANSI, so using
    -std=c++11 when building a compiler is counter-productive. I'd
    suggest to try -std=gnu++11 instead.

    Seems to come from use of

    https://github.com/autoconf-archive/autoconf-archive/blob/master/m4/ax_cxx_compile_stdcxx.m4

    Familiar nuisance: nice C++ standard support detection but result return way is bad: it causes
    -std=... appended directly after compiler path before other options. Even overriding CXX for
    Makefile may break stuff.

    Noticed it in one my own project. Cannot build it for DJGPP for testing (threads, jne). Could
    however try yto check whether I can reasonably easy get it to replace std=c++11 with gnu++11
    (easier with project than builds under 1 minute)


    From the other side Linux do not follow these restrictions. As result developers do not even
    notice a problem. Even my earlier mentioned project builds for Linux without problems when c++17 is
    specified


    Andris


    PS. Checked: Replacing 'AX_CXX_COMPILE_STDCXX_17([noext], [optional])' with 'AX_CXX_COMPILE_STDCXX_17([ext], [optional])'

    causes 'clang++ -std=gnu++17' to be used instead of '-std=c++11'

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)