I have a BunsenLabs Linux VM that I have previously successfully built LLVM on and am using OSXCross on to build a native PCC that runs on and targets macOS x86_64. The impetus for this is of course planned obsolescence, as even the open source world has joined Apple in abandoning the pretence of taking care of what you own as long as it works and decided by committee that macOS Mojave is too old to be worth ‘supporting’ and therefore must be deliberately broken so I’m not allowed to run Homebrew or Xcode or anything really. Tremendously stupid of them but I’m here to persevere.
To get out of this jam I’m taking a page from the elders in a way and bootstrapping an environment that at least has a working native ANSI C compiler, and your PCC here is the current candidate. Unfortunately, it is not building and I’m reasonably sure I’m invoking the ./configure script properly though you can inspect that for yourself:
./configure --prefix=$HOME --host=x86_64-apple-darwin --disable-pcc-debug --enable-native --disable-gcc-compat CC=/mnt/hgfs/x86_64-linux-gnu/bin/clang CFLAGS='-O2 -pipe -fPIC -ansi' LDFLAGS='-pie' CPPFLAGS='-I/mnt/hgfs/x86_64-linux-gnu/include'
make gets run without parallel -job control for safety. CC builds A-OK but CPP fails early on with the following errors:
./cpp.c:693:11: error: incompatible pointer types passing 'usch *'
(aka 'unsigned char *') to parameter of type 'FILE *'
(aka 'struct _IO_FILE *') [-Wincompatible-pointer-types]
693 | pushfile(nm, fn, SYSINC, NULL);
| ^~
./cpp.h:225:21: note: passing argument to parameter 'fp' here
225 | void pushfile(FILE *fp, const usch *fn, int idx, void *incs);
| ^
./cpp.c:736:12: error: incompatible integer to pointer conversion returning
'int' from a function with result type 'char *' [-Wint-conversion]
736 | return 1;
| ^
./cpp.c:741:11: error: incompatible integer to pointer conversion returning
'int' from a function with result type 'char *' [-Wint-conversion]
741 | return 1;
| ^
./cpp.c:745:11: error: incompatible integer to pointer conversion returning
'int' from a function with result type 'char *' [-Wint-conversion]
745 | return 1;
| ^
4 errors generated.
I have tried changing up the dialect to use -std=c99 (which causes some implicit function declaration errors, disturbingly), and -std=gnu99 (which behaves similarly to -ansi used above), but no dice. The cross-compiler built famously without issue using the default methods according to the README therein.
I have a BunsenLabs Linux VM that I have previously successfully built LLVM on and am using OSXCross on to build a native PCC that runs on and targets macOS x86_64. The impetus for this is of course planned obsolescence, as even the open source world has joined Apple in abandoning the pretence of taking care of what you own as long as it works and decided by committee that macOS Mojave is too old to be worth ‘supporting’ and therefore must be deliberately broken so I’m not allowed to run Homebrew or Xcode or anything really. Tremendously stupid of them but I’m here to persevere.
To get out of this jam I’m taking a page from the elders in a way and bootstrapping an environment that at least has a working native ANSI C compiler, and your PCC here is the current candidate. Unfortunately, it is not building and I’m reasonably sure I’m invoking the
./configurescript properly though you can inspect that for yourself:makegets run without parallel-job control for safety.CCbuilds A-OK butCPPfails early on with the following errors:I have tried changing up the dialect to use
-std=c99(which causes some implicit function declaration errors, disturbingly), and-std=gnu99(which behaves similarly to-ansiused above), but no dice. The cross-compiler built famously without issue using the default methods according to the README therein.