-
Notifications
You must be signed in to change notification settings - Fork 15
Description
I attempted to build MINIXCompat using CC=clang buildtool on Debian. Even with changes to have the code build on Linux, the build runs into a few problems:
Firstly, it builds the targets in the order m68kmake, MINIXCompat, Musashi. The MINIXCompat target depends on Musashi and there doesn't appear to be a way to build a specific target with buildtool
After temporarily commenting out the MINIXCompat target to get it to build (line 323), I get an error executing the shell script build phase "Generate 68000 Core" (line 331):
=== Executing Script Build Phase... Generate 68000 Core
=== Command: /bin/sh build/script_Generate68000Core_114371174 using shell /bin/sh
*** script output
build/script_Generate68000Core_114371174: 5: shopt: not found
*** script completed
This is presumably because Debian uses the dash shell instead of bash, which does not implement the shopt builtin.
Hacking around this by adding a dummy binary called shopt into my $PATH, I get a different error:
=== Executing Script Build Phase... Generate 68000 Core
=== Command: /bin/sh build/script_Generate68000Core_114371174 using shell /bin/sh
*** script output
mkdir: cannot create directory '/Musashi': Permission denied
*** script completed
This appears to be because the environment variable PROJECT_DERIVED_FILE_DIR is not defined. The same error surfaces later in the sources build phase: * Building Musashi/m68kcpu.c (1 / 1) - ( 100.00% )... sh: 1: PROJECT_DERIVED_FILE_DIR: not found. I presume this is an oversight in buildtool, since the headers build phase does create a derived sources folder under derived_src.
Rerunning with PROJECT_DERIVED_FILE_DIR=derived_src CC=clang buildtool:
=== Command: /bin/sh build/script_Generate68000Core_114371174 using shell /bin/sh
*** script output
build/script_Generate68000Core_114371174: 29: ./build/Musashi/Products/m68kmake: not found
*** script completed
It appears that the project expects a shared Products directory for all targets, instead of per-target directories. I'm unsure if this is a safe expectation on macOS – it could very well be that the script is buggy even with some versions of XCode tooling as well. In any case, it can be worked around by making build/Musashi/Products and build/MINIXCompat/Products into symbolic links to ../m68kmake/Products.
With these changes, the Musashi target completes succesfully.
Reënabling the MINIXCompat target and running buildtool again, MINIXCompat/MINIXCompat_EmulationOps.c fails to build since it can't locate m68kops.h, one of the files generated by the "Generate 68000 Core" script. While both derived_src and Musashi are included in the includes search path, the file is located in derived_src/Musashi – seemingly another case where buildtool and XCode disagree on the file layout. Copying the contents of derived_src/Musashi to the root of derived_src/ gets us through this.
Finally, the build fails to link with:
=== Executing Frameworks / Linking Build Phase (Tool)
* Linking: -lMusashi
/usr/bin/ld: cannot find -lMusashi: No such file or directory
collect2: error: ld returned 1 exit status
2024-12-06 17:44:32.130 buildtool[581696:581696] Return Value: 256
2024-12-06 17:44:32.131 buildtool[581696:581696] Command: `gnustep-config --variable=CC` -rdynamic -shared-libgcc -fgnu-runtime -o "./build/MINIXCompat/Products/MINIXCompat" './build/MINIXCompat/MINIXCompat_Errors.c.o' './build/MINIXCompat/MINIXCompat_Emulation.c.o' './build/MINIXCompat/MINIXCompat_Executable.c.o' './build/MINIXCompat/MINIXCompat.c.o' './build/MINIXCompat/MINIXCompat_Filesystem.c.o' './build/MINIXCompat/MINIXCompat_Messages.c.o' './build/MINIXCompat/MINIXCompat_EmulationOps.c.o' './build/MINIXCompat/MINIXCompat_SysCalls.c.o' './build/MINIXCompat/MINIXCompat_Processes.c.o' -L/usr/local/lib -L/opt/local/lib -L`gnustep-config --variable=GNUSTEP_USER_LIBRARIES` -L`gnustep-config --variable=GNUSTEP_LOCAL_LIBRARIES` -L`gnustep-config --variable=GNUSTEP_SYSTEM_LIBRARIES` -lMusashi -lobjc `gnustep-config --base-libs` `gnustep-config --variable=LDFLAGS` -lgnustep-base
=== Frameworks / Linking Build Phase Completed
The build expects the Products directory (which contains the libMusashi.a from the Musashi target) to be included in the linker search path. At this point I decided to just run the linking command manually with an adjusted linker search path, which produced an executable.
Thanks for the work on libs-xcode, and I hope I'm not creating too much headache for you by bringing up all these problems I'm having compiling something that doesn't even use Objective-C or OpenStep APIs.
PS: buildtool clean doesn't remove the generated build/script_Generate68000Core_114371174 script.