[Bug go/113143] Remove usage of ucontext.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143 --- Comment #11 from Alexander von Gluck --- Hm.. Could you point me to where Linux is using the (get/set/swap)context calls? I still haven't found them in the codebase. I don't want to miss any edge cases if I work up a patch.
[Bug go/113143] Remove usage of ucontext.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143 --- Comment #9 from Alexander von Gluck --- Doing a little research, it looks like complaints of ucontext.h have come up before multiple times: Similar issue on OpenBSD a long time ago: https://gcc-help.gcc.gnu.narkive.com/Xx1bResV/can-t-build-go-support-in-gcc-4-8-1-on-openbsd muslc not supporting ucontext.h: https://wiki.musl-libc.org/open-issues (and a long list of google results) I guess the root questions of this bug are: 1. Should any and all references to ucontext.h be wrapped with a HAVE macro? (this seems to be what most folks do). Since (get/set/swap)context don't seem to be called on non-BSD platforms, this seems possible? 2. Should libgo double down and implement processor-specific calls for each architecture as called out by Ian in the above thread in 2013? "It's possible to fix this by writing processor-dependent functions that would serve the same purpose as the *context functions, and in fact that would be more efficient. But I have not actually done this." 3. Is the expectation that all platforms which libgo targets include ucontext.h compatibility libraries for calls no-longer standard in the posix specifications since 2008. (muslc pushed against this... i'd be interested if libgo compiles under musl systems)
[Bug go/113143] Remove usage of ucontext.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143 --- Comment #8 from Alexander von Gluck --- Not at all a dumb question :-) I'm working through compiling libgo / gccgo on Haiku.We have our own lovely libc which tests posix compliant. Some historic consideration behind us not having ucontext.h is here: https://dev.haiku-os.org/ticket/5324 We have around 3000 ports (including an old (c)go 1.4, rust, gcc, ruby, etc) none of which have complained about a missing ucontext.h. This is kinda why I feel like it's an anti-pattern to require it in libgo. Even Google's go doesn't consider ucontext.h a requirement on non-bsd platforms. Here's the guys of our libc for context: https://cgit.haiku-os.org/haiku/tree/headers/posix
[Bug go/113143] Remove usage of ucontext.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143
--- Comment #6 from Alexander von Gluck ---
For added clairity. Searching the upstream go sources:
```
grep -R getcontext
src/cmd/vendor/golang.org/x/sys/unix/syscall_netbsd.go:// getcontext
src/cmd/vendor/golang.org/x/sys/unix/zsysnum_freebsd_386.go:SYS_GETCONTEXT
= 421 // { int getcontext(struct __ucontext *ucp); }
src/cmd/vendor/golang.org/x/sys/unix/zsysnum_freebsd_amd64.go: SYS_GETCONTEXT
= 421 // { int getcontext(struct __ucontext *ucp); }
src/cmd/vendor/golang.org/x/sys/unix/zsysnum_freebsd_arm.go:SYS_GETCONTEXT
= 421 // { int getcontext(struct __ucontext *ucp); }
src/cmd/vendor/golang.org/x/sys/unix/zsysnum_freebsd_arm64.go: SYS_GETCONTEXT
= 421 // { int getcontext(struct __ucontext *ucp); }
src/cmd/vendor/golang.org/x/sys/unix/zsysnum_netbsd_386.go: SYS_GETCONTEXT
= 307 // { int|sys||getcontext(struct __ucontext *ucp); }
src/cmd/vendor/golang.org/x/sys/unix/zsysnum_netbsd_amd64.go: SYS_GETCONTEXT
= 307 // { int|sys||getcontext(struct __ucontext *ucp); }
src/cmd/vendor/golang.org/x/sys/unix/zsysnum_netbsd_arm.go: SYS_GETCONTEXT
= 307 // { int|sys||getcontext(struct __ucontext *ucp); }
src/cmd/vendor/golang.org/x/sys/unix/zsysnum_netbsd_arm64.go: SYS_GETCONTEXT
= 307 // { int|sys||getcontext(struct __ucontext *ucp); }
src/runtime/cgo/gcc_solaris_amd64.c:if (getcontext() != 0)
src/runtime/cgo/gcc_solaris_amd64.c:perror("runtime/cgo: getcontext
failed");
src/runtime/os3_solaris.go://go:cgo_import_dynamic libc_getcontext getcontext
"libc.so"
src/runtime/os3_solaris.go://go:linkname libc_getcontext libc_getcontext
src/runtime/os3_solaris.go: libc_getcontext,
src/runtime/os3_solaris.go:func getcontext(context *ucontext) /* int32 */ {
src/runtime/os3_solaris.go: sysvicall1(_getcontext,
uintptr(unsafe.Pointer(context)))
src/runtime/os_netbsd.go:func getcontext(ctxt unsafe.Pointer)
src/runtime/os_netbsd.go: getcontext(unsafe.Pointer())
src/runtime/sys_netbsd_386.s:#define SYS_getcontext 307
src/runtime/sys_netbsd_386.s:TEXT runtime·getcontext(SB),NOSPLIT,$-4
src/runtime/sys_netbsd_386.s: MOVL$SYS_getcontext, AX
src/runtime/sys_netbsd_amd64.s:#define SYS_getcontext 307
src/runtime/sys_netbsd_amd64.s:TEXT runtime·getcontext(SB),NOSPLIT,$-8
src/runtime/sys_netbsd_amd64.s: MOVL$SYS_getcontext, AX
src/runtime/sys_netbsd_arm.s:#define SYS_getcontext
SWI_OS_NETBSD | 307
src/runtime/sys_netbsd_arm.s:TEXT runtime·getcontext(SB),NOSPLIT|NOFRAME,$0
src/runtime/sys_netbsd_arm.s: SWI $SYS_getcontext
src/runtime/sys_netbsd_arm64.s:#define SYS_getcontext 307
src/runtime/sys_netbsd_arm64.s:TEXT runtime·getcontext(SB),NOSPLIT,$-8
src/runtime/sys_netbsd_arm64.s: SVC $SYS_getcontext
src/syscall/zsysnum_freebsd_386.go: SYS_GETCONTEXT = 421 // {
int getcontext(struct __ucontext *ucp); }
src/syscall/zsysnum_freebsd_amd64.go: SYS_GETCONTEXT = 421 // {
int getcontext(struct __ucontext *ucp); }
src/syscall/zsysnum_freebsd_arm.go: SYS_GETCONTEXT = 421 // {
int getcontext(struct __ucontext *ucp); }
src/syscall/zsysnum_freebsd_arm64.go: SYS_GETCONTEXT = 421 // {
int getcontext(struct __ucontext *ucp); }
src/syscall/zsysnum_netbsd_386.go: SYS_GETCONTEXT = 307 // {
int|sys||getcontext(struct __ucontext *ucp); }
src/syscall/zsysnum_netbsd_amd64.go:SYS_GETCONTEXT = 307 // {
int|sys||getcontext(struct __ucontext *ucp); }
src/syscall/zsysnum_netbsd_arm.go: SYS_GETCONTEXT = 307 // {
int|sys||getcontext(struct __ucontext *ucp); }
src/syscall/zsysnum_netbsd_arm64.go:SYS_GETCONTEXT = 307 // {
int|sys||getcontext(struct __ucontext *ucp); }
```
Those all appear to be BSD-specific references, unless i'm missing an
invocation of (get|set|swap)context somewhere?
[Bug go/113143] Remove usage of ucontext.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143 --- Comment #5 from Alexander von Gluck --- > I understand that makecontext/getcontext/setcontext were removed from POSIX. > However, there is no adequate replacement. Their functionality is absolutely > required for what libgo does. No Linux-specific code calls these in gccgo, or upstream go. Only FreeBSD, Solaris, and OpenBSD. Thus my question, why is ucontext.h referenced in cross-platform code when signal.h will suffice?
[Bug go/113143] Remove usage of ucontext.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143 --- Comment #3 from Alexander von Gluck --- Good call out. It looks like in 2004 these functions were flagged as obsolescent though: https://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html Here's the note on it in the linux man page for getcontext: " glibc 2.1. SUSv2, POSIX.1-2001. Removed in POSIX.1-2008, citing portability issues, and recommending that applications be rewritten to use POSIX threads instead. " upstream go usage: * makecontext: no code matches as of go 1.22 (main) * getcontext: netbsd,solaris,freebsd code usage as of go 1.22 (main) * setcontext: netbsd,freebsd code usages as of go 1.22 (main) * swapcontext: freebsd code usages as of go 1.22 (main) Per the 2004 spec: "The obsolescent functions getcontext(), makecontext(), and swapcontext() can be replaced using POSIX threads functions." Essentially, for quite some time, (get|make|set)context are only used on the BSD's and Solaris... thus invocation of include should be guarded / masked off on all other platforms.
[Bug go/113143] Remove usage of ucontext.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143 --- Comment #1 from Alexander von Gluck --- $ grep -R ucontext.h gcc/libgo gcc/libgo/configure:#include gcc/libgo/configure.ac:#include gcc/libgo/go/runtime/runtime2.go:// _sizeof_ucontext_t is defined by mkrsysinfo.sh from . gcc/libgo/misc/cgo/testsanitizers/testdata/tsan_shared.go:#include gcc/libgo/runtime/go-signal.c:#include gcc/libgo/runtime/runtime.h:#include gcc/libgo/sysinfo.c:#include gcc/libgo/sysinfo.c:// From sys/ucontext.h pretty much all of these references can be replaced with a signal.h include... (or wrapped with HAVE_U_CONTEXT_H or whatever if concerned about backwards compatibility to posix 2004.
[Bug go/113143] New: Remove usage of ucontext.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143 Bug ID: 113143 Summary: Remove usage of ucontext.h Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: kallisti5 at unixzen dot com Target Milestone: --- libgo/sysinfo.c references #include which breaks the libgo build on strict POSIX compliance platforms. ucontext.h was removed in issue 7, and types were migrated to signal.h. Old 2004 spec: https://pubs.opengroup.org/onlinepubs/009695399/basedefs/ucontext.h.html Pretty much any recent spec: (ucontext.h is gone) https://pubs.opengroup.org/onlinepubs/9699919799/
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #67 from Alexander von Gluck --- (In reply to cqwrteur from comment #65) > > Difficult? hmmm. Even middle school kids could... Uh uh. Yeah i'm just tuning you out at this point. *anyway* for the adults left in the thread. Jonathan, let me know if theres anything I can test out to help you. Thanks! -- Alex
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #64 from Alexander von Gluck --- (In reply to cqwrteur from comment #61) > TBH, I failed to see how cross-compile in llvm is simple compared to GCC. I mean... bootstrap. Compiling Canadian toolchains to compile non-Canadian toolchains is a pretty difficult task. It's a big reason the BSD's went clang. *ANYWAY* wasn't looking to start a holy war.. just point out that Canadian builds in gcc are important and should likely have a few base tests. (In reply to Jonathan Wakely from comment #62) > But that's off topic for GCC's bugzilla, please try to focus. Indeed. Back on topic, the patchset listed definitely does solve the issue for us. I didn't commit it to our gcc fork (that we plan on working to upstream for Haiku support) though since a final iteration wasn't decided / committed yet here.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #56 from Alexander von Gluck --- Canadian builds are pretty important in GCC. clang doesn't really need Canadian builds since they support all targets out of the box on every platform, but we don't have that luxury with gcc. With that said, the proposed patch solved the issue for us and we applied it to our toolchains here: https://github.com/haikuports/haikuports.cross/blob/master/sys-devel/gcc_bootstrap/patches/gcc-11.2.0_2021_07_28.patchset
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 Alexander von Gluck changed: What|Removed |Added CC||kallisti5 at unixzen dot com --- Comment #51 from Alexander von Gluck --- Just saw this one bootstrapping Haiku riscv64 with gcc 11.1 under Linux. We're quite Canadian. Adding some error spam for others searching for this issue. ``` /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:58:11: error: 'fenv_t' has not been declared in '::' 58 | using ::fenv_t; | ^~ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:59:11: error: 'fexcept_t' has not been declared in '::' 59 | using ::fexcept_t; | ^ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:62:11: error: 'feclearexcept' has not been declared in '::' 62 | using ::feclearexcept; | ^ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:63:11: error: 'fegetexceptflag' has not been declared in '::' 63 | using ::fegetexceptflag; | ^~~ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:64:11: error: 'feraiseexcept' has not been declared in '::' 64 | using ::feraiseexcept; | ^ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:65:11: error: 'fesetexceptflag' has not been declared in '::' 65 | using ::fesetexceptflag; | ^~~ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:66:11: error: 'fetestexcept' has not been declared in '::' 66 | using ::fetestexcept; | ^~~~ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:68:11: error: 'fegetround' has not been declared in '::' 68 | using ::fegetround; | ^~ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:69:11: error: 'fesetround' has not been declared in '::' 69 | using ::fesetround; | ^~ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:71:11: error: 'fegetenv' has not been declared in '::' 71 | using ::fegetenv; | ^~~~ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:72:11: error: 'feholdexcept' has not been declared in '::' 72 | using ::feholdexcept; | ^~~~ /home/kallisti5/Code/haiku/generated.riscv64-bootstrap/objects/haiku/riscv64/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-11.1.0_2021_04_27/sources/gcc_bootstrap-11.1.0_2021_04_27-obj/riscv64-unknown-haiku/libstdc++-v3/include/fenv.h:73:11: error: 'fesetenv
[Bug target/89955] riscv.h improperly defines STARTFILE_PREFIX_SPEC spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955 --- Comment #8 from Alexander von Gluck --- Looks good to me. Now also matches other architectures. Thanks! (viva riscv)
[Bug bootstrap/90653] --with-build-sysroot= not honored for ./configure C compiler checks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90653 Alexander von Gluck changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Alexander von Gluck --- This one is 100% on us. Pretty much we have a variable which gets potentially injected into library search paths (secondary architectures) It's templated out in makefile.in as @SECONDARY_ARCH@. Well, lo-and-behold, we forgot to update configure.ac with the code which templates it out when porting our patches to gcc 8. Thus SECONDARY_ARCH = "@SECONDARY_ARCH@" is defined and gets injected into our library search paths as literally /boot/system/develop/lib/@SECONDARY_ARCH@/... Doh! It was pretty hard to spot since it didn't show up in the specs until I was playing around with injecting the STANDARD_STARTFILE_PREFIX_1 into specs. Sorry for the spam. I wish we could get this stuff upstream to avoid silly issues like that, but we don't have the man-power to write tests at the moment.
[Bug c/90653] --with-build-sysroot= not honored for ./configure C compiler checks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90653 --- Comment #6 from Alexander von Gluck --- Created attachment 46424 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46424=edit gcc8-verbose.txt
[Bug c/90653] --with-build-sysroot= not honored for ./configure C compiler checks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90653 --- Comment #5 from Alexander von Gluck --- Created attachment 46423 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46423=edit gcc7-verbose.txt
[Bug c/90653] --with-build-sysroot= not honored for ./configure C compiler checks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90653 --- Comment #4 from Alexander von Gluck --- ok, this one got kinda long. I've discovered the "how". gcc7 calling the linker using a --sysroot: /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/lib/crtn.o gcc8 calling the linker using a --sysroot: crtn.o What would remove the sysroot prefix from the STARTFILES?
[Bug c/90653] --with-build-sysroot= not honored for ./configure C compiler checks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90653 --- Comment #3 from Alexander von Gluck --- I ran an strace on it, and it's almost like ld isn't aware of the correct library directory for our libraries after gcc8... 8838 openat(AT_FDCWD, "/work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/libroot.so", O_RDONLY) = -1 ENOENT (No such file or directory) 8838 openat(AT_FDCWD, "/work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/libroot.a", O_RDONLY) = -1 ENOENT (No such file or directory) 8838 openat(AT_FDCWD, "/work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/../../../../powerpc-apple-haiku/lib/libroot.so", O_RDONLY) = -1 ENOENT (No such file or directory) 8838 openat(AT_FDCWD, "/work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/../../../../powerpc-apple-haiku/lib/libroot.a", O_RDONLY) = -1 ENOENT (No such file or directory) 8838 openat(AT_FDCWD, "/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/work/generated.ppc/cross-tools-ppc/powerpc-apple-haiku/lib/libroot.so", O_RDONLY) = -1 ENOENT (No such file or directory) 8838 openat(AT_FDCWD, "/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/work/generated.ppc/cross-tools-ppc/powerpc-apple-haiku/lib/libroot.a", O_RDONLY) = -1 ENOENT (No such file or directory) 8838 openat(AT_FDCWD, "/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/usr/local/lib/libroot.so", O_RDONLY) = -1 ENOENT (No such file or directory) 8838 openat(AT_FDCWD, "/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/usr/local/lib/libroot.a", O_RDONLY) = -1 ENOENT (No such file or directory) 8838 openat(AT_FDCWD, "/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/lib/libroot.so", O_RDONLY) = -1 ENOENT (No such file or directory) 8838 openat(AT_FDCWD, "/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/lib/libroot.a", O_RDONLY) = -1 ENOENT (No such file or directory) 8838 openat(AT_FDCWD, "/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/usr/lib/libroot.so", O_RDONLY) = -1 ENOENT (No such file or directory) 8838 openat(AT_FDCWD, "/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/usr/lib/libroot.a", O_RDONLY) = -1 ENOENT (No such file or directory) 8838 write(2, "/work/generated.ppc/cross-tools-"..., 108) = 108 8838 write(2, ": cannot find ", 14)= 14 8838 write(2, "-lroot", 6) = 6 ld is searching at: /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/usr/lib/libroot.so" But our libroot.so is at: /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/lib/libroot.so We didn't touch binutils, so this is all *really* confusing. Did something change about how gcc calls ld between 7 and 8?
[Bug c/90653] --with-build-sysroot= not honored for ./configure C compiler checks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90653 --- Comment #2 from Alexander von Gluck --- I was wrong about the autotools aspect... it *is* passing the sysroot to gcc during the C compiler test. I reproduced the test configure is running and enabled verbosity... root@9e90f9304b75:/work/generated.ppc/cross-tools-ppc/bin# ./powerpc-apple-haiku-gcc -O2 -U_FORTIFY_SOURCE --sysroot=/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc test.c -v Using built-in specs. COLLECT_GCC=./powerpc-apple-haiku-gcc COLLECT_LTO_WRAPPER=/work/generated.ppc/cross-tools-ppc/libexec/gcc/powerpc-apple-haiku/8.3.0/lto-wrapper Target: powerpc-apple-haiku Configured with: /work/src/buildtools/gcc/configure --prefix=/work/generated.ppc/cross-tools-ppc --target=powerpc-apple-haiku --disable-nls --disable-shared --with-system-zlib --enable-languages=c,c++ --enable-lto --enable-frame-pointer --enable-__cxa-atexit --enable-threads=posix --with-default-libstdcxx-abi=gcc4-compatible --with-sysroot=/work/generated.ppc/cross-tools-ppc/sysroot --disable-maintainer-mode --disable-multilib --disable-tls Thread model: posix gcc version 8.3.0 (GCC) COLLECT_GCC_OPTIONS='-O2' '-U' '_FORTIFY_SOURCE' '-v' /work/generated.ppc/cross-tools-ppc/libexec/gcc/powerpc-apple-haiku/8.3.0/cc1 -quiet -v -isysroot /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc -U _FORTIFY_SOURCE test.c -fPIC -Wno-multichar -quiet -dumpbase test.c -auxbase test -O2 -version -o /tmp/ccIVtwgr.s GNU C17 (GCC) version 8.3.0 (powerpc-apple-haiku) compiled by GNU C version 6.3.0 20170516, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/non-packaged/develop/headers/@HYBRID_SECONDARY@" ignoring nonexistent directory "/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/os/opengl" ignoring nonexistent directory "/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/os/be_apps/Deskbar" ignoring nonexistent directory "/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/3rdparty" ignoring nonexistent directory "/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/@HYBRID_SECONDARY@" ignoring nonexistent directory "/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/@HYBRID_SECONDARY@/os" ignoring nonexistent directory "/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/@HYBRID_SECONDARY@/os/opengl" #include "..." search starts here: #include <...> search starts here: /work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/include /work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/include-fixed /work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/../../../../powerpc-apple-haiku/include /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/os /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/os/app /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/os/device /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/os/drivers /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/os/game
[Bug c/90653] --with-build-sysroot= not honored for ./configure C compiler checks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90653 --- Comment #1 from Alexander von Gluck --- Created attachment 46421 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46421=edit config.loh attached is the config.log from gcc. I should mention we see the same error across all of our architecture builds (ppc, x86_64, sparc64, arm, etc) Notice that the provided with-build-sysroot doesn't seem to be passed to gcc
[Bug c/90653] New: --with-build-sysroot= not honored for ./configure C compiler checks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90653 Bug ID: 90653 Summary: --with-build-sysroot= not honored for ./configure C compiler checks. Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kallisti5 at unixzen dot com Target Milestone: --- After updating from gcc 7.3.x to 8.3.x, the early stage of our bootstrap is no longer finding our provided sysroot. Build flags: CFLAGS="-O2 -U_FORTIFY_SOURCE" CXXFLAGS="-O2" ./configure \ --build=$buildMachineTriple --host=$effectiveTargetMachineTriple \ --target=$effectiveTargetMachineTriple --prefix=$installDir \ --libexecdir=$installDir/lib --mandir=$manDir --docdir=$docDir \ --disable-nls --enable-shared --disable-plugin \ --enable-version-specific-runtime-libs \ --enable-languages=c,c++ --enable-lto --enable-frame-pointer \ --enable-threads=posix --enable-tls \ --with-pkgversion=$(echo $portVersion | cut -c 7-) \ --with-sysroot=/ \ --with-build-sysroot=$sysrootLocation \ --with-threads=posix \ --with-default-libstdcxx-abi=gcc4-compatible \ --disable-libstdcxx-pch \ $sysrootLocation is: /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc With this, we get: "error: C compiler cannot create executables" Our startfile specs are valid... #define STANDARD_STARTFILE_PREFIX_1 "/boot/system/non-packaged/develop/lib/" #define STANDARD_STARTFILE_PREFIX_2 "/boot/system/develop/lib/" ...and we have a valid early build sysroot: root@9e90f9304b75:/work/generated.ppc# find /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc | grep develop/lib /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/lib /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/lib/crti.o /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/lib/crtn.o /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/lib/init_term_dyn.o /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/lib/start_dyn.o /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/lib/haiku_version_glue.o /work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/lib/libroot.so However, we get gcc executed during the configure stage and receive: /work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/../../../../powerpc-apple-haiku/bin/ld: cannot find crti.o: No such file or directory /work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/../../../../powerpc-apple-haiku/bin/ld: cannot find start_dyn.o: No such file or directory /work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/../../../../powerpc-apple-haiku/bin/ld: cannot find init_term_dyn.o: No such file or directory /work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/../../../../powerpc-apple-haiku/bin/ld: cannot find -lroot /work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/../../../../powerpc-apple-haiku/bin/ld: cannot find crtn.o: No such file or directory I'm not sure if this is a autoconf bug, or a gcc bug. I think *maybe* autoconf handles the "generate valid executables with C compiler" phase?
[Bug target/89955] riscv.h improperly defines STARTFILE_PREFIX_SPEC spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955 --- Comment #4 from Alexander von Gluck --- oh.. also some context I missed. Our libraries aren't at /lib,/usr/lib,etc. (which is also reflected in our os config headers) Am I wrong to think making that assumption in the architecture level seems misplaced. (if there was a higher level linux.h... 64-bit? /lib64, etc, that seems like a "more better" way of doing it (and how 'the rest of the architectures' seem to do it) The fundamental question here is, "should architecture headers override the location of os library prefix paths in a non-generic way". It's an edge case for sure (there aren't too many unicorn posix operating systems that put their library paths at somewhere not /lib* (we're /boot/system/lib))
[Bug target/89955] riscv.h improperly defines STARTFILE_PREFIX_SPEC spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955 --- Comment #3 from Alexander von Gluck --- The issue here is RISC-V is the only one that does this. We do override the STARTFILE_PREFIX_SPEC for our OS, however the architecture headers come later and undo our undef. root@b36eea373140:/work/src/buildtools/gcc/gcc# grep -R STARTFILE_PREFIX_SPEC config/haiku.h:#undef STARTFILE_PREFIX_SPEC config/mips/mti-linux.h:#undef STARTFILE_PREFIX_SPEC config/mips/mti-linux.h:#define STARTFILE_PREFIX_SPEC \ config/mips/st.h:#undef STARTFILE_PREFIX_SPEC config/mips/st.h:#define STARTFILE_PREFIX_SPEC \ config/riscv/haiku.h:#undef STARTFILE_PREFIX_SPEC config/riscv/riscv.h:#define STARTFILE_PREFIX_SPEC \ I mean... shouldn't the STARTFILE_PREFIX be up to the OS and not the architecture? (any lib32 vs lib64 or whatever would be done by generics, not architecture specific code)
[Bug target/89955] New: riscv.h improperly defines STARTFILE_PREFIX_SPEC spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955 Bug ID: 89955 Summary: riscv.h improperly defines STARTFILE_PREFIX_SPEC spec Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kallisti5 at unixzen dot com Target Milestone: --- https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/riscv/riscv.h?view=markup#l885 gcc/config/riscv.h defines STARTFILE_PREFIX_SPEC which breaks sysroot's. Under a new platform (Haiku), our bootstrap was failing missing core existing cross-compiled system libraries which were present and accounted for. Eventually I figured out to #undef STARTFILE_PREFIX_SPEC in our gcc/config/riscv/haiku.h header and things magically began working. Since we're cross compiling with a sysroot (which is *not*) at /usr/lib,/lib,etc, it breaks the sysroot functionality. Likely I think STARTFILE_PREFIX_SPEC needs moved to config/riscv/linux.h ?
[Bug target/81283] Quirks around 32-bit PowerPC built-in Atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81283 Alexander von Gluck changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Alexander von Gluck --- Sorry for the late reply on this one. I'm pretty sure I did this and it worked :-)
[Bug middle-end/81283] Quirks around 32-bit PowerPC built-in Atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81283 --- Comment #4 from Alexander von Gluck --- I mean... I know we have 32-bit x86 builds using that exact same code :-)
[Bug middle-end/81283] Quirks around 32-bit PowerPC built-in Atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81283 --- Comment #3 from Alexander von Gluck --- I may be misguided, but wouldn't it be possible to handle these in software with some sync's and some wrapper code?
[Bug plugins/81283] Quirks around 32-bit PowerPC built-in Atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81283
--- Comment #1 from Alexander von Gluck ---
Here is some context on our wrapper for the atomic call generating the
__atomic_fetch_add_8 references.
static __inline__ void
atomic_set64(int64* value, int64 newValue)
{
__atomic_store_n(value, newValue, __ATOMIC_RELEASE);
}
[Bug plugins/81283] New: Quirks around 32-bit PowerPC built-in Atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81283 Bug ID: 81283 Summary: Quirks around 32-bit PowerPC built-in Atomics Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: kallisti5 at unixzen dot com Target Milestone: --- Context: /home/kallisti5/Code/haiku/generated.ppc/cross-tools-ppc/bin/powerpc-apple-haiku-gcc -fno-strict-aliasing -fno-tree-vrp -Wno-array-bounds -Xlinker --no-undefined -Xlinker -soname=_APP_ -nostdlib -Xlinker --no-undefined Compiler: $ /home/kallisti5/Code/haiku/generated.ppc/cross-tools-ppc/bin/powerpc-apple-haiku-gcc -v Using built-in specs. COLLECT_GCC=/home/kallisti5/Code/haiku/generated.ppc/cross-tools-ppc/bin/powerpc-apple-haiku-gcc COLLECT_LTO_WRAPPER=/home/kallisti5/Code/haiku/generated.ppc/cross-tools-ppc/libexec/gcc/powerpc-apple-haiku/5.4.0/lto-wrapper Target: powerpc-apple-haiku Configured with: /home/kallisti5/Code/buildtools/gcc/configure --prefix=/home/kallisti5/Code/haiku/generated.ppc/cross-tools-ppc --target=powerpc-apple-haiku --disable-nls --disable-shared --with-system-zlib --enable-languages=c,c++ --enable-lto --enable-frame-pointer --with-sysroot=/home/kallisti5/Code/haiku/generated.ppc/cross-tools-ppc/sysroot --disable-threads --disable-tls --disable-libatomic --disable-multilib Thread model: single gcc version 5.4.0 (GCC) We started to leverage the built-in atomics a year or two ago. When our target is powerpc, functions using 64-bit atomics result in gcc generating __atomic_fetch_add_8 calls. The GCC documention for __atomic_* doesn't mention this behaviour (https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html), however the older __sync_* built-ins does (https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html): "Not all operations are supported by all target processors. If a particular operation cannot be implemented on the target processor, a warning will be generated and a call an external function will be generated. The external function will carry the same name as the builtin, with an additional suffix `_n' where n is the size of the data type." Is there a reason for the 64-bit atomic built-ins not working on powerpc? (Even if inefficently stubbed out) Is there a way to detect maximum built-in atomic width without needing a long list of architectures or gcc-centric code? Thanks! -- Alex
[Bug driver/60358] New: [patch] ARM support broken for Haiku
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60358 Bug ID: 60358 Summary: [patch] ARM support broken for Haiku Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: kallisti5 at unixzen dot com Created attachment 32224 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32224action=edit fix revision 1 host_detect_local_cpu only works on Linux platforms and should be disable on Haiku (due to the lack of /proc/cpuinfo) A more complete fix may be to implement host_detect_local_cpu for Haiku ARM, however that change could be messy (esp as the ARM Haiku port is extremely early)
[Bug driver/60358] [patch] ARM support broken for Haiku
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60358 --- Comment #1 from Alexander von Gluck kallisti5 at unixzen dot com --- Created attachment 32225 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32225action=edit rev2 an additional resolution path. This one may be better, however driver-arm.c would need additional changes to be Haiku-aware.
[Bug libgcc/56938] New: Compiling GCC 4.6.3 with GCC 4.8.0 results in internal build errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56938 Bug #: 56938 Summary: Compiling GCC 4.6.3 with GCC 4.8.0 results in internal build errors. Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc AssignedTo: unassig...@gcc.gnu.org ReportedBy: kallis...@unixzen.com Checking multilib configuration for libgcc... mkdir -p -- i586-pc-haiku/libgcc Configuring in i586-pc-haiku/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... gawk checking build system type... x86_64-unknown-linux-gnu checking host system type... i586-pc-haiku checking for i586-pc-haiku-ar... /home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/bin/ar checking for i586-pc-haiku-lipo... i586-pc-haiku-lipo checking for i586-pc-haiku-nm... /home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/./gcc/nm checking for i586-pc-haiku-ranlib... /home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/bin/ranlib checking for i586-pc-haiku-strip... /home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/bin/strip checking whether ln -s works... yes checking for i586-pc-haiku-gcc... /home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/./gcc/xgcc -B/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/./gcc/ -B/home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/bin/ -B/home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/lib/ -isystem /home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/include -isystem /home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/sys-include checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/./gcc/xgcc -B/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/./gcc/ -B/home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/bin/ -B/home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/lib/ -isystem /home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/include -isystem /home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/sys-include accepts -g... yes checking for /home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/./gcc/xgcc -B/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/./gcc/ -B/home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/bin/ -B/home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/lib/ -isystem /home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/include -isystem /home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/sys-include option to accept ISO C89... none needed checking how to run the C preprocessor... /home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/./gcc/xgcc -B/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/./gcc/ -B/home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/bin/ -B/home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/lib/ -isystem /home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/include -isystem /home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/sys-include -E checking whether decimal floating point is supported... no configure: WARNING: decimal float is not supported for this target, ignored checking whether fixed-point is supported... no checking whether assembler supports CFI directives... yes checking for __attribute__((visibility(hidden)))... yes checking whether the target assembler supports thread-local storage... yes checking whether the thread-local storage support is from emutls... no configure: updating cache ./config.cache configure: creating ./config.status config.status: creating Makefile config.status: executing default commands make[2]: Entering directory `/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/i586-pc-haiku/libgcc' # If this is the top-level multilib, build all the other /home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/./gcc/xgcc -B/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/./gcc/ -B/home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/bin/ -B/home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/lib/ -isystem /home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/include -isystem /home/kallisti5/Projects/haiku/generated/cross-tools/i586-pc-haiku/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
[Bug c/52986] New: x86_64 GCC 4.7.0 can't compile x86 GCC 4.6.2; gtype-desc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52986 Bug #: 52986 Summary: x86_64 GCC 4.7.0 can't compile x86 GCC 4.6.2; gtype-desc.c Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: kallis...@unixzen.com Original bug report: http://dev.haiku-os.org/ticket/8470 Failure: gcc -c -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I/home/kallisti5/Projects/buildtools/gcc/gcc -I/home/kallisti5/Projects/buildtools/gcc/gcc/. -I/home/kallisti5/Projects/buildtools/gcc/gcc/../include -I/home/kallisti5/Projects/buildtools/gcc/gcc/../libcpp/include -I/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/./gmp -I/home/kallisti5/Projects/buildtools/gcc/gmp -I/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/./mpfr -I/home/kallisti5/Projects/buildtools/gcc/mpfr -I/home/kallisti5/Projects/buildtools/gcc/mpc/src -I/home/kallisti5/Projects/buildtools/gcc/gcc/../libdecnumber -I/home/kallisti5/Projects/buildtools/gcc/gcc/../libdecnumber/dpd -I../libdecnumber/home/kallisti5/Projects/buildtools/gcc/gcc/haifa-sched.c -o haifa-sched.o gtype-desc.c:8868:18: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:8987:36: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:9071:31: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:9092:31: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:9099:31: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:9106:31: error: subscripted value is neither array nor pointer nor vector make[2]: *** [gtype-desc.o] Error 1 make[2]: *** Waiting for unfinished jobs rm cpp.pod gcc.pod fsf-funding.pod make[2]: Leaving directory `/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc' make: *** [all] Error 2 ERROR: Building gcc failed. Environment: kallisti5@eris ~ :) $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/src/gcc-4.7-20120407/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id --with-ppl --enable-cloog-backend=isl --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-multilib --disable-libssp --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-checking=release Thread model: posix gcc version 4.7.0 20120407 (prerelease) (GCC)
