On May 7, 2020, at 2:11 PM, Kevan Hashemi hashemi@brandeis.edu wrote:
Dear GPC Collaborators,
PROBLEM: MacOS 10.15 does not run 32-bit binaries. My application uses 30k lines of GPC code. The MacOS GPC is 32-bit only.
MY FAILURE ON MACOS: The current GPC is compatible with the back-end of GCC 3.4.6 only. The procedure on all platforms is to compile gcc3.4.6 with the GPC sources. With a variety of C-compilers on MacOS (CLANG, GCC-4.9, GCC-5, and GCC-8), I can produce the two cross-compiler executables xgcc and xgpc. These are x86_64 executables. They both compile "Hello World", but they produce only 32-bit objects. When I pass "-m64", they say "Sorry: 64-bit not compiled in". I try building GCC 3.4.6 alone with:
config --target=x86_64-apple-darwin make
But I get, "Configuration x86_64-apple-darwin16.7.0 not supported". When I apply the same procedure to the GCC 4.9.4 sources, the build proceeds. The GCC 3.4.6 sources support 64-bit targets on Linux, so I was hoping it could do the same on MacOS. I have examined the GCC literature and the contents of gcc/config, but I still don't know what file should be present to provide x86_64 support on apple-darwin. Unless someone tells me otherwise, I'm going to assume that getting the 64-bit MacOS GPC out of GCC 3.4.6 is impossible.
It has been a long time but IIRC we got a 4.x.x based GPC 64 bit x.86 target working. At the time though we couldn't get a PPC_64 version working so the effort was put on hold pending finding a fix for PPC_64. This was around the 10.5/10.6 days. (Look at Waldek's git repository for 4.x.x based GPC sources and patches.)
I'd have to dig back in mail archives to see if I'm remembering correctly, but I think the issue with a MacOS GCC 3.4.6 base is/was that there didn't exist a 64 bit MacOS runtime until after GCC 4.x.x became the only actively developed/maintained version. (There might also have been a lack of MacOS specific PPC_64 code generation also but that's a mute issue now.) I've got a dim memory that there might have been an issue with multi-lib support that was needed but didn't exist for building a MacOS GCC 3.4.6 base.
Since those days, Apple has switched from a GNU based toolchain to a LLVM based toolchain which wrecks havoc with build processes expecting a GNU compatible toolchain command set. You can work around most of the problems with using a Homebrew or MacPorts GCC but there's no way that I could find to get around using Apple's system supplied linker. For Apple's linker there's three different linker specs required to get GPC/GCC working depending upon the OS version target - 10.6 or earlier, 10.7, and 10.8 or later (I won't rule out changes since I last looked into it). With a 3.4.6 based GPC, there was a separate specs file so you could fix up linker specs issues by modifying that file. That no longer works with 4.x.x and later compilers since the specs gets compiled into the compiler itself. I think the linker specs issue can be solved by back porting the linker spec code from the late 4.x GCC version code to the earlier version GCC code that Waldek's 4.x.x code builds with.
IIRC, I also ran into 10.11/10.12 issues in getting the GPC rts built. I'd have to really do some digging but I think there was problem in a rts build program (or build testing/checking program) that I found a temporary hack workaround for. (There's auto generated files involved and I hadn't yet chased back to the base source a non-hackish fix.) There was also an issue or two with changes C standard library function prototypes in I think the math area. (IIRC, the C math function issues showed up in later GCC 4.5.x/4.6.x ish versions and fixes were found that looked like they might be back portable to earlier GGC 4.x.x versions.) Those IIRC didn't show up until you got to the bootstrapping stage and it was causing autoconfig problems. Before I got very far in solving that issue, I had to put the project on hold for more pressing issues and haven't revisited it since.
Translating all my beautiful, reliable GPC code into another language does not sound like fun. Porting GPC to a newer version of GCC, such as GCC 8, is a possibility, but I understand that the GCC back-end team has a history of being uncooperative with the GPC team. Another solution is to port GPC to LVVM so we can use the CLANG compilers. The LVVM strategy seem like a good one to me: produce platform-independent code that then gets compiled and assembled. If I understand correctly, a CLANG front-end will work on any platform.
I ran into quite a few problems in trying to build GPC with CLANG compilers. I couldn't find a gcc C dialect language option for CLANG that worked to compile the GPC code base. Even newer version gcc's barf on the way older version dialect gcc code used in the GPC sources but at least as far as gcc 5.x (I think was a the latest I tried) there was a language dialect option you could use so the GPC sources would compile without language version issues. Now that I think of it, I think I also ran into assembly language dialect issues with Apple's CLANG based assembler and I changed config options to use GNU gas for assembling into machine code before linking.
I would like to hear your advice. I have to solve this problem. I have allocated one thousand hours of my time to get it done. If there is a way to revive GPC with that amount of labor, I'll do it.
I think porting GPC to LLVM might be a dicey proposition. The project will be pretty much on its own with no help except for an over a decade old Apple GCC front end port example to help in figuring out what might work on an old, outdated LLVM code base.
You might try spending a week or two on Waldek's 4.x.x code base to get a better idea of the magnitude of the work effort involved with that avenue. If practical, make sure you do it on a MacOS 10.15 machine so you get better idea of what issues Apple's every changing system configuration will arise using the relative old GCC/GPC 4.x.x code base. (I seem to recall Apple reorganized the system headers structure in the 10.8/10.10 timeframe that caused a few problems.)
Gale Paeper gpaeper@empirenet.com