On Wed, 28 Nov 2018 12:47:21 -0500, Brian Callahan wrote:
>
>
> On 11/28/18 6:54 AM, Stuart Henderson wrote:
> > On 2018/11/27 19:36, George Koehler wrote:
> >> On Tue, 27 Nov 2018 16:12:08 -0500
> >> George Koehler <kern...@gmail.com> wrote:
> >>
> >>> NetBSD's packages of gcc5 and gcc7 do contain the headers from float.h
> >>> to stdatomic.h (or most of them). I haven't found the reason why
> >>> NetBSD keeps those headers and OpenBSD doesn't.
> >> Found it!
> >>
> >> $ cat gcc-6.4.0/gcc/config/t-openbsd
> >> # We don't need GCC's own include files.
> >> USER_H = $(EXTRA_HEADERS)
> >>
> >> This t-openbsd gets enabled by gcc-6.4.0/gcc/config.gcc and then
> >> included by build-powerpc/{prev-gcc,gcc}/Makefile so it overrides
> >> USER_H. The effect is to remove gcc's float.h, iso646.h, stdarg.h,
> >> stdbool.h, stddef.h, varargs.h, stdfix.h, stdnoreturn.h, stdalign.h,
> >> stdatomic.h from the compiler.
> >>
> >> The obvious fix (though I haven't tried it) is to remove this USER_H
> >> override, either by commenting it or by patching config.gcc to ignore
> >> t-openbsd. Most platforms don't override USER_H. (The only other
> >> platform to override USER_H is config/mips/t-sdemtk, but its
> >> override looks outdated to me.)
> > This fix seems like the right approach in general to me, I think this
> > is definitely worth trying.
>
> This causes the build to fail rather quickly. Log attached.
> I took the route of commenting out the USER_H line from t-openbsd.
>
> >> Another option is to keep the USER_H override and add only the 4
> >> headers stdfix.h, stdnoreturn.h, stdalign.h, stdatomic.h. This may
> >> become outdated if a future version of gcc adds more headers.
> > That sounds like it's asking for future trouble.
>
> This allows the build to succeed, and seems to uncover some issues with
> our port (like, we have been enabling SSP in configure but not actually
> building or at least installing it?).
We really don't want to install GCC's own libssp and ssp headers. I
have no idea why adding stuff to USER_H would suddenly enable these, but
can you try to add --disable-libssp to CONFIGURE_ARGS?
> Diff attached to do add just those headers that are not in /usr/include
> and the resulting PLIST changes. Yes it is more work keeping an eye out
> to sync this list every time we update gcc, so it may be worth it to fix
> the build with all headers enabled if we can.
>
> ~Brian
>
> >> Another option is to add the 4 headers to base OpenBSD. If there
> >> is some reason why /usr/include has its own float.h, iso646.h, and so
> >> on, then the same reason might be why to add the 4 headers.
> > I'm not sure if it's the same for all of these headers, but stdatomic.h
> > in particular seems much more tightly bound to the compiler than to
> > the OS.
> >
> >> gcc also has its own stdint.h, but doesn't use it on OpenBSD, because
> >> config.gcc defaults to use_gcc_stdint=none and has no code to enable
> >> it on OpenBSD.
> >>
> >> For comparison, ports-clang (pkg_info -L llvm) seems to package its
> >> own float.h, iso646.h, and so on, and its own stdint.h; while
> >> base-clang seems to omit headers that exist in /usr/include.
> > It does for some but not others. diff -wu of iso646.h, for example,
> > differs only in whitespace, copyright/PD notice, and double-inclusion
> > protection macro..
> >
>
>
>>> application/gzip attachment, name=gcc6.log.gz
>>> text/x-patch content
