Re: lang/gcc/6: Install missing stdatomic.h header
Reviving this with an updated patch...
On 11/29/18 12:19 PM, Brian Callahan wrote:
On 11/29/18 8:17 AM, Pascal Stumpf wrote:
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 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?
Make sense. Yup, added that flag. Simpler diff overall that way.
Attached.
~Brian
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
New diff is mostly the same, except it adds openbsd-stdint.h to the
tm_file lines in gcc/config.gcc to all archs that were missing it. This
allows the stdatomic.h header to be usable on all archs. Problem
reported and fix from George Koehler, who couldn't use stdatomic.h on
his macppc and now can.
~Brian
Index: Makefile
===
RCS file: /cvs/ports/lang/gcc/6/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile 7 Dec 2018 18:27:35 - 1.14
+++ Makefile 12 Dec 2018 20:02:47 -
@@ -6,7 +6,7 @@ ONLY_FOR_ARCHS = ${GCC49_ARCHS}
DPB_PROPERTIES = parallel
V = 6.4.0
-REVISION = 3
+REVISION = 4
FULL_VERSION = $V
FULL_PKGVERSION = $V
@@ -138,6 +138,7 @@ CONFIGURE_ARGS += \
--with-system-zlib \
--disable-libmudflap \
--disable-libgomp \
+ --disable-libssp \
--disable-tls \
--with-gnu-ld \
--with-gnu-as \
Index: patches/patch-gcc_config_gcc
===
RCS file: /cvs/ports/lang/gcc/6/patches/patch-gcc_config_gcc,v
retrieving revision 1.5
diff -u -p -r1.5 patch-gcc_config_gcc
--- patches/patch-gcc_config_gcc 1 Nov 2018 22:09:30 - 1.5
+++ patches/patch-gcc_config_gcc 12 Dec 2018 20:02:47 -
@@ -32,7 +32,7 @@ Index: gcc/config.gcc
;;
+arm-*-openbsd*)
+ tm_defines="${tm_defines} DEFAULT_FLAG_PIE=1"
-+ tm_file="dbxelf.h elfos.h arm/elf.h arm/aout.h arm/openbsd1.h arm/arm.h openbsd.h openbsd-libpthread.h arm/openbsd.h"
++ tm_file="dbxelf.h elfos.h arm/elf.h arm/aout.h arm/openbsd1.h arm/arm.h openbsd.h openbsd-stdint.h
Re: lang/gcc/6: Install missing stdatomic.h header
On 11/29/18 8:17 AM, Pascal Stumpf wrote:
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 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?
Make sense. Yup, added that flag. Simpler diff overall that way. Attached.
~Brian
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
Index: Makefile
===
RCS file: /cvs/ports/lang/gcc/6/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile 26 Nov 2018 22:21:31 - 1.13
+++ Makefile 29 Nov 2018 17:18:18 -
@@ -6,7 +6,7 @@ ONLY_FOR_ARCHS = ${GCC49_ARCHS}
DPB_PROPERTIES = parallel
V = 6.4.0
-REVISION = 2
+REVISION = 3
FULL_VERSION = $V
FULL_PKGVERSION = $V
@@ -138,6 +138,7 @@ CONFIGURE_ARGS += \
--with-system-zlib \
--disable-libmudflap \
--disable-libgomp \
+ --disable-libssp \
--disable-tls \
--with-gnu-ld \
--with-gnu-as \
Index: patches/patch-gcc_config_t-openbsd
===
RCS file: patches/patch-gcc_config_t-openbsd
diff -N patches/patch-gcc_config_t-openbsd
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-gcc_config_t-openbsd 29 Nov 2018 17:18:18 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Make sure to include standard headers that are tightly bound
+to the compiler, such as stdatomic.h
+
+Index: gcc/config/t-openbsd
+--- gcc/config/t-openbsd.orig
gcc/config/t-openbsd
+@@ -1,2 +1,6 @@
+ # We don't need GCC's own include files.
+-USER_H = $(EXTRA_HEADERS)
++USER_H = $(srcdir)/ginclude/stdfix.h \
++ $(srcdir)/ginclude/stdnoreturn.h \
++ $(srcdir)/ginclude/stdalign.h \
++ $(srcdir)/ginclude/stdatomic.h \
++ $(EXTRA_HEADERS)
Index: pkg/PLIST-c++
===
RCS file: /cvs/ports/lang/gcc/6/pkg/PLIST-c++,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST-c++
--- pkg/PLIST-c++ 4 Sep 2016 16:20:22 - 1.1.1.1
+++ pkg/PLIST-c++ 29 Nov 2018 17:18:18 -
@@ -219,6 +219,7
Re: lang/gcc/6: Install missing stdatomic.h header
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 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
Re: lang/gcc/6: Install missing stdatomic.h header
On 2018/11/27 19:36, George Koehler wrote:
> On Tue, 27 Nov 2018 16:12:08 -0500
> George Koehler 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.
> 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.
> 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..
Re: lang/gcc/6: Install missing stdatomic.h header
On Tue, 27 Nov 2018 16:12:08 -0500
George Koehler 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.)
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.
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.
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.
--
George Koehler
Re: lang/gcc/6: Install missing stdatomic.h header
On Mon, 26 Nov 2018 23:05:45 -0500
Brian Callahan wrote:
> For some reason, the gcc package doesn't install the stdatomic.h header.
> Which doesn't matter, until it matters.
This is 1 of 4 missing headers: stdfix.h, stdnoreturn.h, stdalign.h,
stdatomic.h. These are listed in gcc-6.4.0/gcc/Makefile.in as
USER_H = $(srcdir)/ginclude/float.h \
$(srcdir)/ginclude/iso646.h \
$(srcdir)/ginclude/stdarg.h \
$(srcdir)/ginclude/stdbool.h \
$(srcdir)/ginclude/stddef.h \
$(srcdir)/ginclude/varargs.h \
$(srcdir)/ginclude/stdfix.h \
$(srcdir)/ginclude/stdnoreturn.h \
$(srcdir)/ginclude/stdalign.h \
$(srcdir)/ginclude/stdatomic.h \
$(EXTRA_HEADERS)
EXTRA_HEADERS seems to have arch-dependent headers. My
build-powerpc/{prev-gcc,gcc}/Makefile has headers like ppc-asm.h,
altivec.h (for PowerPC's AltiVec), and tgmath.h (but I dont know why
tgmath.h is arch-dependent).
Makefile seems to copy USER_H to build-powerpc/{prev-gcc,gcc}/include,
but when I look there, I only see the EXTRA_HEADERS. I don't know why
the headers from float.h to stdatomic.h are missing. The absence of
float.h to varargs.h seems harmless because OpenBSD has them in
/usr/include. The absence of stdfix.h, stdnoreturn.h, stdalign.h,
stdatomic.h means that programs can't use those headers.
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.
--
George Koehler
Re: lang/gcc/6: Install missing stdatomic.h header
On 11/27/18 6:20 AM, Pascal Stumpf wrote:
On Mon, 26 Nov 2018 23:05:45 -0500, Brian Callahan wrote:
Hi ports --
For some reason, the gcc package doesn't install the stdatomic.h header.
Which doesn't matter, until it matters.
I believe GCC expects this header to be present on the host system. It
*is* a standard (C11) header, after all.
Discovered when I was building Firefox on amd64 with gcc-6.4.0 (which
works at runtime just fine, but is not a discussion to be had on this
thread because it's way more involved than this simple diff). Firefox
needs stdatomic.h when using gcc, and this diff lets Firefox build
successfully.
I'm kinda guessing with the PFRAG.* stuff outside of PFRAG.X86-main, so
more eyes appreciated.
This is wrong if you install the header on all archs anyway. It could
just be in PLIST-main. But I don't think that's the right solution
anyway. We do currently have a stdatomic.h in base, as an intrinsic
header to clang. I wonder if that is sufficient.
GCC is unable to see the clang header.
Here's a really simple program to demonstrate the problem:
#include
int main(void) { return 0; }
Try to compile it with gcc-6.4.0, you'll get:
test.c:1:23: fatal error: stdatomic.h: No such file or directory
#include
^
compilation terminated.
~Brian
OK? Better solution within the gcc framework itself?
~Brian
text/x-patch content
Re: lang/gcc/6: Install missing stdatomic.h header
On Mon, 26 Nov 2018 23:05:45 -0500, Brian Callahan wrote: > Hi ports -- > > For some reason, the gcc package doesn't install the stdatomic.h header. > Which doesn't matter, until it matters. I believe GCC expects this header to be present on the host system. It *is* a standard (C11) header, after all. > Discovered when I was building Firefox on amd64 with gcc-6.4.0 (which > works at runtime just fine, but is not a discussion to be had on this > thread because it's way more involved than this simple diff). Firefox > needs stdatomic.h when using gcc, and this diff lets Firefox build > successfully. > > I'm kinda guessing with the PFRAG.* stuff outside of PFRAG.X86-main, so > more eyes appreciated. This is wrong if you install the header on all archs anyway. It could just be in PLIST-main. But I don't think that's the right solution anyway. We do currently have a stdatomic.h in base, as an intrinsic header to clang. I wonder if that is sufficient. > OK? Better solution within the gcc framework itself? > > ~Brian > > >>> text/x-patch content
Re: lang/gcc/6: Install missing stdatomic.h header
On Mon, Nov 26, 2018 at 11:05:45PM -0500, Brian Callahan wrote: > Hi ports -- > > For some reason, the gcc package doesn't install the stdatomic.h header. > Which doesn't matter, until it matters. > > Discovered when I was building Firefox on amd64 with gcc-6.4.0 (which works > at runtime just fine, but is not a discussion to be had on this thread > because it's way more involved than this simple diff). Firefox needs > stdatomic.h when using gcc, and this diff lets Firefox build successfully. I'm not sure why (since you dont show the failure log :), https://dxr.mozilla.org/mozilla-release/source/media/ffvpx/config_unix64.h#233 is one of the few occurences. Note the comment in the libvpx header here: https://dxr.mozilla.org/mozilla-release/source/media/libvpx/libvpx/vpx_util/vpx_atomics.h#22 > OK? Better solution within the gcc framework itself? As for the gcc diff itself, i think there's a reason it's not installed, be it on purpose upstream (installing it only on supported platforms ?) or because some configure check fails for some reason on OpenBSD and then it's not installed. Side-installing it this way feels awkward.. Maybe looking at other oses might give a clue, per https://www.freshports.org/devel/amd64-gcc/ it is installed/shipped on FreeBSD, but i dunno if it's an upstream choice or a packaging choice. Landry
lang/gcc/6: Install missing stdatomic.h header
Hi ports --
For some reason, the gcc package doesn't install the stdatomic.h header.
Which doesn't matter, until it matters.
Discovered when I was building Firefox on amd64 with gcc-6.4.0 (which
works at runtime just fine, but is not a discussion to be had on this
thread because it's way more involved than this simple diff). Firefox
needs stdatomic.h when using gcc, and this diff lets Firefox build
successfully.
I'm kinda guessing with the PFRAG.* stuff outside of PFRAG.X86-main, so
more eyes appreciated.
OK? Better solution within the gcc framework itself?
~Brian
Index: Makefile
===
RCS file: /cvs/ports/lang/gcc/6/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile 26 Nov 2018 22:21:31 - 1.13
+++ Makefile 27 Nov 2018 04:00:45 -
@@ -6,7 +6,7 @@ ONLY_FOR_ARCHS = ${GCC49_ARCHS}
DPB_PROPERTIES = parallel
V = 6.4.0
-REVISION = 2
+REVISION = 3
FULL_VERSION = $V
FULL_PKGVERSION = $V
@@ -250,7 +250,10 @@ post-extract:
${WRKDIR}/bootstrap/include/c++/*/*/bits/c++config.h
.endif
+# Upstream doesn't install stdatomic.h???
post-install:
+ ${INSTALL_DATA} ${WRKSRC}/gcc/ginclude/stdatomic.h \
+ ${PREFIX}/lib/gcc/${CONFIG}/${V}/include
.if ${BUILD_PACKAGES:M-ada}
chown -R ${SHAREOWN}:${SHAREGRP} ${PREFIX}/lib/gcc/*/$V/adainclude
chown -R ${SHAREOWN}:${SHAREGRP} ${PREFIX}/lib/gcc/*/$V/adalib
Index: pkg/PFRAG.X86-main
===
RCS file: /cvs/ports/lang/gcc/6/pkg/PFRAG.X86-main,v
retrieving revision 1.2
diff -u -p -r1.2 PFRAG.X86-main
--- pkg/PFRAG.X86-main 28 Dec 2016 21:48:21 - 1.2
+++ pkg/PFRAG.X86-main 27 Nov 2018 04:00:46 -
@@ -48,6 +48,7 @@ lib/gcc/${CONFIG}/${V}/include/rdseedint
lib/gcc/${CONFIG}/${V}/include/rtmintrin.h
lib/gcc/${CONFIG}/${V}/include/shaintrin.h
lib/gcc/${CONFIG}/${V}/include/smmintrin.h
+lib/gcc/${CONFIG}/${V}/include/stdatomic.h
lib/gcc/${CONFIG}/${V}/include/tbmintrin.h
lib/gcc/${CONFIG}/${V}/include/tgmath.h
lib/gcc/${CONFIG}/${V}/include/tmmintrin.h
Index: pkg/PFRAG.alpha-main
===
RCS file: /cvs/ports/lang/gcc/6/pkg/PFRAG.alpha-main,v
retrieving revision 1.1
diff -u -p -r1.1 PFRAG.alpha-main
--- pkg/PFRAG.alpha-main 1 Nov 2018 22:09:30 - 1.1
+++ pkg/PFRAG.alpha-main 27 Nov 2018 04:00:46 -
@@ -1,4 +1,5 @@
@comment $OpenBSD: PFRAG.alpha-main,v 1.1 2018/11/01 22:09:30 sthen Exp $
+lib/gcc/${CONFIG}/${V}/include/stdatomic.h
lib/gcc/${CONFIG}/${V}/include/tgmath.h
lib/gcc/${CONFIG}/${V}/include/unwind.h
lib/gcc/${CONFIG}/${V}/plugin/include/config/alpha/
Index: pkg/PFRAG.arm-main
===
RCS file: /cvs/ports/lang/gcc/6/pkg/PFRAG.arm-main,v
retrieving revision 1.2
diff -u -p -r1.2 PFRAG.arm-main
--- pkg/PFRAG.arm-main 9 Sep 2016 20:51:03 - 1.2
+++ pkg/PFRAG.arm-main 27 Nov 2018 04:00:46 -
@@ -2,6 +2,7 @@
lib/gcc/${CONFIG}/${V}/include/arm_acle.h
lib/gcc/${CONFIG}/${V}/include/arm_neon.h
lib/gcc/${CONFIG}/${V}/include/mmintrin.h
+lib/gcc/${CONFIG}/${V}/include/stdatomic.h
lib/gcc/${CONFIG}/${V}/include/tgmath.h
lib/gcc/${CONFIG}/${V}/include/unwind-arm-common.h
lib/gcc/${CONFIG}/${V}/include/unwind.h
Index: pkg/PFRAG.mips64-main
===
RCS file: /cvs/ports/lang/gcc/6/pkg/PFRAG.mips64-main,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PFRAG.mips64-main
--- pkg/PFRAG.mips64-main 4 Sep 2016 16:20:22 - 1.1.1.1
+++ pkg/PFRAG.mips64-main 27 Nov 2018 04:00:46 -
@@ -1,5 +1,6 @@
@comment $OpenBSD: PFRAG.mips64-main,v 1.1.1.1 2016/09/04 16:20:22 pascal Exp $
lib/gcc/${CONFIG}/${V}/include/loongson.h
+lib/gcc/${CONFIG}/${V}/include/stdatomic.h
lib/gcc/${CONFIG}/${V}/include/tgmath.h
lib/gcc/${CONFIG}/${V}/include/unwind.h
lib/gcc/${CONFIG}/${V}/plugin/include/config/dbxelf.h
Index: pkg/PFRAG.mips64el-main
===
RCS file: /cvs/ports/lang/gcc/6/pkg/PFRAG.mips64el-main,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PFRAG.mips64el-main
--- pkg/PFRAG.mips64el-main 4 Sep 2016 16:20:22 - 1.1.1.1
+++ pkg/PFRAG.mips64el-main 27 Nov 2018 04:00:46 -
@@ -1,5 +1,6 @@
@comment $OpenBSD: PFRAG.mips64el-main,v 1.1.1.1 2016/09/04 16:20:22 pascal Exp $
lib/gcc/${CONFIG}/${V}/include/loongson.h
+lib/gcc/${CONFIG}/${V}/include/stdatomic.h
lib/gcc/${CONFIG}/${V}/include/tgmath.h
lib/gcc/${CONFIG}/${V}/include/unwind.h
lib/gcc/${CONFIG}/${V}/plugin/include/config/dbxelf.h
Index: pkg/PFRAG.powerpc-main
===
RCS file: /cvs/ports/lang/gcc/6/pkg/PFRAG.powerpc-main,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PFRAG.powerpc-main
--- pkg/PFRAG.powerpc-main 4 Sep 2016 16:20:20 - 1.1.1.1
+++ pkg/PFRAG.powerpc-main 27 Nov 2018 04:00:46 -
@@ -8,6 +8,7 @@
