You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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
. TheMINIXCompat
target depends onMusashi
and there doesn't appear to be a way to build a specific target with buildtoolAfter 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):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:
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 underderived_src
.Rerunning with
PROJECT_DERIVED_FILE_DIR=derived_src CC=clang buildtool
: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
andbuild/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 locatem68kops.h
, one of the files generated by the "Generate 68000 Core" script. While bothderived_src
andMusashi
are included in the includes search path, the file is located inderived_src/Musashi
– seemingly another case where buildtool and XCode disagree on the file layout. Copying the contents ofderived_src/Musashi
to the root ofderived_src/
gets us through this.Finally, the build fails to link with:
The build expects the Products directory (which contains the
libMusashi.a
from theMusashi
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 generatedbuild/script_Generate68000Core_114371174
script.The text was updated successfully, but these errors were encountered: