[Bug target/90835] Incompatibilities with macOS 10.15 headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835 a.h.jaffe at gmail dot com changed: What|Removed |Added CC||a.h.jaffe at gmail dot com --- Comment #17 from a.h.jaffe at gmail dot com --- Jeremy, any information on the ETA of the __OSX_AVAILABLE_STARTING fix? I've got quite a few things I can't compile right now!
[Bug target/60821] gcc 4.8 on MacOS fails depending on -arch order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60821 --- Comment #6 from a.h.jaffe at gmail dot com --- Thanks for the comprehensive info. It would certainly be nice to get the driverdriver into the main code-base. However, one thing still puzzles me: 5. We do accept -arch on x86: -arch i386 gets mapped = -m32 and -arch x86_64 - -m64. The last one you place on the c/l will be in force (and there's NO support for the ppc equivalent at present). This doesn't quite make sense given my experience: I have a 64-bit Mavericks machine, and compiled using MacPorts with +universal. All of -arch i386, -arch x86_64 and -arch x86_64 -arch i386 seem to succeed, but -arch i386 -arch x86_64 fails. According to the above, the latter should have the same behaviour as -arch x86_64
[Bug target/60821] gcc 4.8 on MacOS fails depending on -arch order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60821 --- Comment #4 from a.h.jaffe at gmail dot com --- (In reply to Marek Polacek from comment #3) Whoops, sorry. I better let Darwin folks look at it. Ah, but in fact *I* misunderstood. There's a difference between the FSF and Apple versions: FSF GCC on Darwin does not create “fat” object files; it creates an object file for the single architecture that GCC was built to target So I still think there's at least a misfeature in the sense that there should be a more graceful failure here, but in some sense the docs are right. However, a more general question: WHY doesn't FSF gcc have this capability?
[Bug c/60821] New: gcc 4.8 on MacOS fails depending on -arch order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60821
Bug ID: 60821
Summary: gcc 4.8 on MacOS fails depending on -arch order
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: a.h.jaffe at gmail dot com
I am trying to get a recent version of gcc 4.8.2 up on my machine (OSX 10.9.2).
I have tried installs that come from MacPorts as well as the one that gets
installed alongside a binary install of gfortran.
For a minimal source file, I get errors depending on the order of the -arch
flags.
Specifically, `-arch x86_64 -arch i386` (or either of them alone) works:
% /opt/local/bin/gcc-mp-4.8 -arch x86_64 -arch i386 conftest.c
% /opt/local/bin/gcc-mp-4.8 -arch x86_64 -arch i386 -O3 conftest.c
But `-arch i386 -arch x86_64` fails:
% /opt/local/bin/gcc-mp-4.8 -arch i386 -arch x86_64 conftest.c
/var/folders/6l/7gzvw1zs42sbhj7_hlrpykfmgv/T//cc6JCBdP.s:5:bad register
name `%rbp'
/var/folders/6l/7gzvw1zs42sbhj7_hlrpykfmgv/T//cc6JCBdP.s:7:bad register
name `%rsp'
/var/folders/6l/7gzvw1zs42sbhj7_hlrpykfmgv/T//cc6JCBdP.s:10:bad
register name `%rbp'
% /opt/local/bin/gcc-mp-4.8 -arch i386 -arch x86_64 -O3 conftest.c
/var/folders/6l/7gzvw1zs42sbhj7_hlrpykfmgv/T//ccs67E0q.s:34:FATAL:Bad
fx_size (0x8) in fix_to_relocation_info()
Help!
The minimal source:
int main ()
{
return 0;
}
For info:
% /opt/local/bin/gcc-mp-4.8 --version
gcc-mp-4.8 (MacPorts gcc48 4.8.2_0+universal) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c/60821] gcc 4.8 on MacOS fails depending on -arch order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60821 a.h.jaffe at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from a.h.jaffe at gmail dot com --- @Marek I don't think that's right, or at least the behaviour doesn't make sense: http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Darwin-Options.html#Darwin-Options Apple's GCC on Darwin does create “fat” files if multiple -arch options are used; it does so by running the compiler or linker multiple times and joining the results together with lipo. And in any event, note that either -arch i386 or -arch x86_64 work *separately*!
