gcc: vxworks: fix providing stdint.h header

  Commit bbbc05957e (Arrange to preinclude yvals.h ahead of stdint on
VxWorks 7) breaks the build of libstdc++ for our VxWorks 5 platform.

In file included from .../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/memory:72,
                 from .../gcc-src/libstdc++-v3/include/precompiled/stdc++.h:82:
.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/bits/align.h:36:10: fatal error: stdint.h: No such file or directory
   36 | #include <stdint.h>     // uintptr_t
      |          ^~~~~~~~~~
compilation terminated.
Makefile:1861: recipe for target 'powerpc-wrs-vxworks/bits/stdc++.h.gch/O2ggnu++0x.gch' failed
make[5]: *** [powerpc-wrs-vxworks/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1

The problem is that the stdint.h header does not exist (in the
gcc/include/ directory) during the build, but is only added at "make
install" time.

For the approach with an extra makefile fragment to work, that rule
would have to fire after stmp-int-hdrs as it does now (i.e., after the
common logic has removed stdint.h), but it must also run before we
actually start building target libraries that depend on having a
stdint.h - and I can't find something reasonable to make the rule a
dependency of.

I agree with the intent of avoiding "altering the common stdint-gcc.h
with unpleasant vxworks specific bits". The best approach I could come
up with is adding another variant of "use_gcc_stdint", "preserve",
meaning "leave whatever the target's extra_headers settings put inside
gcc/include/ alone". There's no change in behaviour for any of the
existing values "none", "wrap" or "provide".

gcc/ChangeLog:

	* Makefile.in (stmp-int-hdrs): Only remove include/stdint.h when
	$(USE_GCC_STDINT) != "preserve".
	* config.gcc: Document new possible value of use_gcc_stdint:
	"preserve".
	* config.gcc (vxworks): Add ../vxworks/stdint.h to
	extra_headers and set use_gcc_stdint=preserve.
	* config/t-vxworks: Remove install-stdint.h rule.
---

I have previously sent something similar to Olivier privately, hoping
I could come up with a better/cleaner fix. But I have failed, so now
I've taken what I had and added the necesary documentation and
changelog bits.

Better ideas are of course welcome. I thought of using "custom"
instead of "preserve", but chose the latter since "wrap" and "provide"
are verbs.

 gcc/Makefile.in      |  4 +++-
 gcc/config.gcc       | 11 ++++++-----
 gcc/config/t-vxworks | 12 ------------
 3 files changed, 9 insertions(+), 18 deletions(-)
  

Hi Rasmus,

We have had to use for stdbool a similar trick as we had
for stdint (need to preinclude yyvals.h), which we will need to
propagate somehow. I'm not yet sure how to reconcile that with
your observations.

Olivier

> On 12 Nov 2021, at 11:15, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
> 
> Commit bbbc05957e (Arrange to preinclude yvals.h ahead of stdint on
> VxWorks 7) breaks the build of libstdc++ for our VxWorks 5 platform.
> 
> In file included from .../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/memory:72,
>                 from .../gcc-src/libstdc++-v3/include/precompiled/stdc++.h:82:
> .../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/bits/align.h:36:10: fatal error: stdint.h: No such file or directory
>   36 | #include <stdint.h>     // uintptr_t
>      |          ^~~~~~~~~~
> compilation terminated.
> Makefile:1861: recipe for target 'powerpc-wrs-vxworks/bits/stdc++.h.gch/O2ggnu++0x.gch' failed
> make[5]: *** [powerpc-wrs-vxworks/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1
> 
> The problem is that the stdint.h header does not exist (in the
> gcc/include/ directory) during the build, but is only added at "make
> install" time.
> 
> For the approach with an extra makefile fragment to work, that rule
> would have to fire after stmp-int-hdrs as it does now (i.e., after the
> common logic has removed stdint.h), but it must also run before we
> actually start building target libraries that depend on having a
> stdint.h - and I can't find something reasonable to make the rule a
> dependency of.
> 
> I agree with the intent of avoiding "altering the common stdint-gcc.h
> with unpleasant vxworks specific bits". The best approach I could come
> up with is adding another variant of "use_gcc_stdint", "preserve",
> meaning "leave whatever the target's extra_headers settings put inside
> gcc/include/ alone". There's no change in behaviour for any of the
> existing values "none", "wrap" or "provide".
> 
> gcc/ChangeLog:
> 
> 	* Makefile.in (stmp-int-hdrs): Only remove include/stdint.h when
> 	$(USE_GCC_STDINT) != "preserve".
> 	* config.gcc: Document new possible value of use_gcc_stdint:
> 	"preserve".
> 	* config.gcc (vxworks): Add ../vxworks/stdint.h to
> 	extra_headers and set use_gcc_stdint=preserve.
> 	* config/t-vxworks: Remove install-stdint.h rule.
> ---
> 
> I have previously sent something similar to Olivier privately, hoping
> I could come up with a better/cleaner fix. But I have failed, so now
> I've taken what I had and added the necesary documentation and
> changelog bits.
> 
> Better ideas are of course welcome. I thought of using "custom"
> instead of "preserve", but chose the latter since "wrap" and "provide"
> are verbs.
> 
> gcc/Makefile.in      |  4 +++-
> gcc/config.gcc       | 11 ++++++-----
> gcc/config/t-vxworks | 12 ------------
> 3 files changed, 9 insertions(+), 18 deletions(-)
> 
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 571e9c28e29..759982f1d7d 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -3132,7 +3132,9 @@ stmp-int-hdrs: $(STMP_FIXINC) $(T_GLIMITS_H) $(USER_H) fixinc_list
> 	    chmod a+r include/$$file; \
> 	  fi; \
> 	done
> -	rm -f include/stdint.h
> +	if [ $(USE_GCC_STDINT) != preserve ]; then \
> +	  rm -f include/stdint.h; \
> +	fi
> 	if [ $(USE_GCC_STDINT) = wrap ]; then \
> 	  rm -f include/stdint-gcc.h; \
> 	  cp $(srcdir)/ginclude/stdint-gcc.h include/stdint-gcc.h; \
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index edd12655c4a..7a236e1a967 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -129,8 +129,9 @@
> #  use_gcc_stdint	If "wrap", install a version of stdint.h that
> #			wraps the system's copy for hosted compilations;
> #			if "provide", provide a version of systems without
> -#			such a system header; otherwise "none", do not
> -#			provide such a header at all.
> +#			such a system header; if "preserve", keep the copy
> +#			installed via the target's extra_headers; otherwise
> +#			"none", do not provide such a header at all.
> #
> #  extra_programs	List of extra executables compiled for this target
> #			machine, used when linking.
> @@ -1024,11 +1025,11 @@ case ${target} in
>   tm_file="${tm_file} vxworks-stdint.h"
> 
>   # .. only through the yvals conditional wrapping mentioned above
> -  # to abide by the VxWorks 7 expectations.  The final copy is performed
> -  # explicitly by a t-vxworks Makefile rule.
> +  # to abide by the VxWorks 7 expectations.
> 
> -  use_gcc_stdint=none
> +  use_gcc_stdint=preserve
>   extra_headers="${extra_headers} ../../ginclude/stdint-gcc.h"
> +  extra_headers="${extra_headers} ../vxworks/stdint.h"
> 
>   case ${enable_threads} in
>     no) ;;
> diff --git a/gcc/config/t-vxworks b/gcc/config/t-vxworks
> index 5a06ebe1b87..a544bedf634 100644
> --- a/gcc/config/t-vxworks
> +++ b/gcc/config/t-vxworks
> @@ -24,18 +24,6 @@ vxworks-c.o: $(srcdir)/config/vxworks-c.c
> 	$(COMPILE) $<
> 	$(POSTCOMPILE)
> 
> -# Arrange to install our stdint.h wrapper, by copying it in the
> -# build-time include dir before this include dir is installed and after
> -# stmp-int-hdrs removes it (because it was told we don't provide it).
> -
> -INSTALL_HEADERS += install-stdint.h
> -
> -install-stdint.h: stmp-int-hdrs
> -	cp -p $(srcdir)/config/vxworks/stdint.h include/stdint.h
> -	chmod a+r include/stdint.h
> -
> -$(INSTALL_HEADERS_DIR): install-stdint.h
> -
> # Both the kernel and RTP headers provide limits.h.  They embed VxWorks
> # specificities and are dated on some configurations so we both need to
> # provide our own version and make sure the system one gets exposed.
> -- 
> 2.31.1
>
  

Hi Rasmus,

> On 12 Nov 2021, at 17:35, Olivier Hainque <hainque@adacore.com> wrote:

> We have had to use for stdbool a similar trick as we had
> for stdint (need to preinclude yyvals.h), which we will need to
> propagate somehow. I'm not yet sure how to reconcile that with
> your observations.

>> In file included from .../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/memory:72,
>>                from .../gcc-src/libstdc++-v3/include/precompiled/stdc++.h:82:
>> .../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/bits/align.h:36:10: fatal error: stdint.h: No such file or directory
>>  36 | #include <stdint.h>     // uintptr_t
>>     |          ^~~~~~~~~~
>> compilation terminated.
>> Makefile:1861: recipe for target 'powerpc-wrs-vxworks/bits/stdc++.h.gch/O2ggnu++0x.gch' failed
>> make[5]: *** [powerpc-wrs-vxworks/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1

>> For the approach with an extra makefile fragment to work, that rule
>> would have to fire after stmp-int-hdrs as it does now (i.e., after the
>> common logic has removed stdint.h), but it must also run before we
>> actually start building target libraries that depend on having a
>> stdint.h - and I can't find something reasonable to make the rule a
>> dependency of.

I was just able to get complete build of a gcc-11 based compiler
with only a couple of minor additions on top of what we already have,
part of which I was planning to propagate, including the stdbool trick
similar to the one for stdint.

I didn't hit the error you have and we have never hit it before,
which suggests there might be some significant difference between our
ways to build that could help.

Your error triggers on O2ggnu++0x.gch and we configure with
--disable-libstdcxx-pch.

Can you see if adding this to your configuration options helps
on your end?

Thanks in advance,

Olivier
  

On 19/11/2021 19.11, Olivier Hainque wrote:
> Hi Rasmus,
> 
>> On 12 Nov 2021, at 17:35, Olivier Hainque <hainque@adacore.com> wrote:
> 
> Your error triggers on O2ggnu++0x.gch and we configure with
> --disable-libstdcxx-pch.
> 
> Can you see if adding this to your configuration options helps
> on your end?

ISTR I already tried that, but just for good measure I did it again, and
no luck:

/bin/sh ../libtool --tag CXX --tag disable-shared   --mode=compile
.../gcc-build/./gcc/xgcc -shared-libgcc -B.../gcc-build/./gcc
-nostdinc++ -L.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/src
-L.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/src/.libs
-L.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/libsupc++/.libs
-B/usr/powerpc-wrs-vxworks/bin/ -B/usr/powerpc-wrs-vxworks/lib/ -isystem
/usr/powerpc-wrs-vxworks/include -isystem
/usr/powerpc-wrs-vxworks/sys-include
--sysroot=/usr/powerpc-wrs-vxworks/sys-root
-fdebug-prefix-map=.../gcc-build/= -fdebug-prefix-map=.../gcc-src/=
-I.../gcc-src/libstdc++-v3/../libgcc
-I.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/powerpc-wrs-vxworks
-I.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include
-I.../gcc-src/libstdc++-v3/libsupc++     -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once    -ffunction-sections -fdata-sections
 -frandom-seed=del_opant.lo  -g -O2 -mstrict-align -mmultiple
-fvisibility=hidden  -c -o del_opant.lo
.../gcc-src/libstdc++-v3/libsupc++/del_opant.cc
.../gcc-src/libstdc++-v3/libsupc++/new_opa.cc:28:10: fatal error:
stdint.h: No such file or directory
   28 | #include <stdint.h>
      |          ^~~~~~~~~~
compilation terminated.

Rasmus
  

> On 19 Nov 2021, at 21:47, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
>> 
>> Your error triggers on O2ggnu++0x.gch and we configure with
>> --disable-libstdcxx-pch.
>> 
> 
> ISTR I already tried that, but just for good measure I did it again, and
> no luck:
> 
> /bin/sh ../libtool --tag CXX --tag disable-shared   --mode=compile
> .../gcc-build/./gcc/xgcc -shared-libgcc -B.../gcc-build/./gcc
> -nostdinc++ -L.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/src
> -L.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/src/.libs
> -L.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/libsupc++/.libs
> -B/usr/powerpc-wrs-vxworks/bin/ -B/usr/powerpc-wrs-vxworks/lib/ -isystem
> /usr/powerpc-wrs-vxworks/include -isystem
> /usr/powerpc-wrs-vxworks/sys-include
> --sysroot=/usr/powerpc-wrs-vxworks/sys-root
> -fdebug-prefix-map=.../gcc-build/= -fdebug-prefix-map=.../gcc-src/=
> -I.../gcc-src/libstdc++-v3/../libgcc
> -I.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/powerpc-wrs-vxworks
> -I.../gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include
> -I.../gcc-src/libstdc++-v3/libsupc++     -fno-implicit-templates -Wall
> -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
> -fdiagnostics-show-location=once    -ffunction-sections -fdata-sections
> -frandom-seed=del_opant.lo  -g -O2 -mstrict-align -mmultiple
> -fvisibility=hidden  -c -o del_opant.lo
> .../gcc-src/libstdc++-v3/libsupc++/del_opant.cc
> .../gcc-src/libstdc++-v3/libsupc++/new_opa.cc:28:10: fatal error:
> stdint.h: No such file or directory
>   28 | #include <stdint.h>
>      |          ^~~~~~~~~~

Ok, thanks. Another diff is we're using fixincludes for vx6
(not 7), and have a local patch setting sysroot_headers_dir in
a particular fashion to handle kernel vs rtp (part of what I was
intending to propagate as well). We're not using --sysroot directly.

I'll check how our build sequence proceeds.
  

Hi Rasmus,

Some new on this.

> On 20 Nov 2021, at 09:07, Olivier Hainque <hainque@adacore.com> wrote:
> 
> I'll check how our build sequence proceeds.

Turns out our build succeeds thanks to the presence
of a vendor version of stdint.h in the VxWorks6/7 header dirs
and we're lucky that the need to pre-include yvals.h isn't
showing up during the libraries' build.

It is of course not good to use one version during the build
of libraries then install an alternate version that will be
used by programs afterwards.

The attached patch achieves the same kind of thing you
initiated, only reusing a method previously introduced
for glimits.h instead of adding a new use_gcc_stdint value,
which seems a bit less intrusive to me.

This introduces an indirect dependency on the VxWorks version.h
for vxcrtstuff objects, for which we then need to apply the same
tricks as for libgcc2 regarding include paths (to select the system
header instead of the gcc one).

I have had a few succesful builds and tests with this,
for both VxWorks 6 and VxWorks 7 configurations.

Bootstrap and regtest on x86°64-linux in progress.

cc'ed Alex who proposed the T_GLIMITS_H change.

Olivier


2021-02-12  Olivier Hainque  <hainque@adacore.com>
            Rasmus Villemoes <rv@rasmusvillemoes.dk>

gcc/
        * Makefile.in (T_STDINT_GCC_H): New variable, path to
        stdint-gcc.h that a target configuration may override when
        use_gcc_stdint is "provide".
        (stmp-int-hdrs): Depend on it and copy that for
        USE_GCC_INT=provide.
        * config.gcc (vxworks): Revert to use_gcc_stdint=provide.
        * config/t-vxworks (T_STDINT_GCC_H): Define, as vxw-stdint-gcc.h.
        (vxw-stdint-gcc.h): New target, produced from the original
        stdint-gcc.h.
        (vxw-glimits.h): Use an automatic variable to designate the
        first and only prerequisite.
        * config/vxworks/stdint.h: Remove.

libgcc/
        * config/t-vxworks: Set CRTSTUFF_T_CFLAGS to
        $(LIBGCC2_INCLUDES).
        * config/t-vxworks7: Likewise.
  

On 02/12/2021 16.29, Olivier Hainque wrote:
> Hi Rasmus,
> 
> Some new on this.
> 
>> On 20 Nov 2021, at 09:07, Olivier Hainque <hainque@adacore.com> wrote:
>>
>> I'll check how our build sequence proceeds.
> 
> Turns out our build succeeds thanks to the presence
> of a vendor version of stdint.h in the VxWorks6/7 header dirs
> and we're lucky that the need to pre-include yvals.h isn't
> showing up during the libraries' build.
> 
> It is of course not good to use one version during the build
> of libraries then install an alternate version that will be
> used by programs afterwards.
> 
> The attached patch achieves the same kind of thing you
> initiated, only reusing a method previously introduced
> for glimits.h instead of adding a new use_gcc_stdint value,
> which seems a bit less intrusive to me.
> 
> This introduces an indirect dependency on the VxWorks version.h
> for vxcrtstuff objects, for which we then need to apply the same
> tricks as for libgcc2 regarding include paths (to select the system
> header instead of the gcc one).
> 
> I have had a few succesful builds and tests with this,
> for both VxWorks 6 and VxWorks 7 configurations.

Reverting my fix and applying this on top of my gcc-11.2 based branch
seems to work. I haven't used the compiler for building or running any
modules (don't have the hardware handy), but I've done an 'objdump -d'
comparison on all the generated host binaries and target libraries with
no diff.

So OK by me.

Thanks,
Rasmus
  

> On 3 Dec 2021, at 11:27, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
> 
> Reverting my fix and applying this on top of my gcc-11.2 based branch
> seems to work. I haven't used the compiler for building or running any
> modules (don't have the hardware handy), but I've done an 'objdump -d'
> comparison on all the generated host binaries and target libraries with
> no diff.
> 
> So OK by me.


Thanks for checking. Bootstrap and regression tests passed
on a native x86_64-linux host.

Alex, how does that look to you?

Thanks in advance!
  

On Dec  3, 2021, Olivier Hainque <hainque@adacore.com> wrote:

> Alex, how does that look to you?

LGTM, thanks,
  

> On 6 Dec 2021, at 04:05, Alexandre Oliva <oliva@adacore.com> wrote:
> 
> On Dec  3, 2021, Olivier Hainque <hainque@adacore.com> wrote:
> 
>> Alex, how does that look to you?
> 
> LGTM, thanks,

Great, thanks. I'll commit shortly and will soon start
proposing the batch of other changes I have been mentioning.

Some of this might not be stage 3 amenable, so maybe
commits will have to wait for the next stage 1. We'll see.

It will give Rasmus an opportunity to see what's coming, still.

Olivier