apple silicon build problem(s?)

[at7heb]

• Context

I'm trying to build simh on a MacBook Pro with the M1 chip, Ventura 13.5.2. I use home-brew. There are build problems.

• how you built the simulator or that you're using prebuilt binaries

First problem is accessing the GNU getopt. I get the following output (I've not included the output from the brew installations and updates; gnu-getopt is installed)

heb@howards-mbp simh % cmake/cmake-builder.sh
cmake/cmake-builder.sh: GNU getopt needed for this script to function properly.
cmake/cmake-builder.sh: Specifically, a 'getopt' that supports the '-T' flag (enhanced getopt)

That is an easy fix in cmake/cmake-builder.sh -- add this line

[[ -d /opt/homebrew/opt/gnu-getopt/bin ]] && PATH="/opt/homebrew/opt/gnu-getopt/bin:$PATH"

The next problem is

heb@howards-mbp simh % cmake/cmake-builder.sh
** cmake version 3.27.5

CMake suite maintained and supported by Kitware (kitware.com/cmake).
realpath: /Users/heb/Documents/dev/simh/cmake/build-unix: No such file or directory
cmake/cmake-builder.sh: SIMH top-evel directory: /Users/heb/Documents/dev/simh
cmake/cmake-builder.sh: Build directory:
usage: mkdir [-pv] [-m mode] directory_name ...
/opt/homebrew/bin/cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release -S /Users/heb/Documents/dev/simh -B
CMake Error: No build directory specified for -B
CMake Error: Run 'cmake --help' for all supported options.
*** cmake/cmake-builder.sh: Errors detected during environment generation. Exiting.
heb@howards-mbp simh %

after running make with --help, I tried building with the --flavor xcode and ran into the next problem

heb@howards-mbp simh % cmake/cmake-builder.sh --flavor xcode
** cmake version 3.27.5

CMake suite maintained and supported by Kitware (kitware.com/cmake).
realpath: /Users/heb/Documents/dev/simh/cmake/build-xcode: No such file or directory
cmake/cmake-builder.sh: SIMH top-evel directory: /Users/heb/Documents/dev/simh
cmake/cmake-builder.sh: Build directory:
usage: mkdir [-pv] [-m mode] directory_name ...
/opt/homebrew/bin/cmake -G "Xcode" -DCMAKE_BUILD_TYPE=Release -S /Users/heb/Documents/dev/simh -B
CMake Error:
Xcode 1.5 not supported.

CMake Error: Could not create named generator Xcode

These may be the tip of the iceberg...

[pkoning2]

I've used this stuff before on my M1 Macbook, without trouble. So I checked again.
Apparently I tinkered with my Homebrew setup because some of the builds are now failing in a way to that imply it isn't finding the PNG support. I thought it was supposed to be optional but if so the cmake files don't seem to handle that.

In any case, trying --target lgp just for a quick test shows that flavors unix, ninja, and xcode all work. I have Mac OS 12.6.8, Cmake 3.26.4, Xcode 14.2, Clang 14.0.0.

Do you have the xcode command line utilities installed? A quick test is "gcc --version", that should work and will tell you the Clang version number (masquerading as gcc, which of course it isn't).

[at7heb]

MacOS (Ventura) 13.5.2 -- one difference
Xcode command line utilities installed:

heb@howards-mbp cmake % gcc --version
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: arm64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
heb@howards-mbp cmake %

Reading the output, the mkdir usage message stands out; I added

echo "will mkdir ${buildSubdir}"
before the mkdir --
mkdir ${buildSubdir}

With that debug output, it looks like the buildSubdir shell variable is not set.

I've created a branch so it is easy to create the pull request, but my progress may be slow...

[at7heb]

The errors running cmake-builder.sh were because I didn't have the proper configuration for the Xcode command line tools. I ran

sudo xcode-select -s /Applications/Xcode.app/Contents/Developer

and all the simulators built and passed all tests.

The hint for this came from looking at cmake/build-xcode/CMakeFiles/CMakeConfigureLog.yaml.

[pkoning2]

Thanks, that might make a good addition to the build documentation.

[at7heb]

Should I do so? If so, I'll assume the same issue & pull request. A gentle hint on how I do that with GitHub would be appreciated. I'm a cooperative development neophyte.

[at7heb]

Never mind on the gentle hint. I saw this:

Add more commits by pushing to the apple-silicon0 branch on at7heb/simh.

[juiceghost]

Not sure if they are related but i ran into issues trying to build opensimh commit b23cde9 on my M1 mac running Sonoma. I had a string of linker issues which in the end i solved with the following command
make LDFLAGS="-lz -ledit -lpcre -lpng" pdp11

Could very well be PEBCAK but i thought i'd throw this in here just in case. Also Sonoma.

[pkoning2]

@juiceghost were you using cmake or the makefile? It's hard to comment on your report without seeing the full build log.

[bscottm]

@pkoning2: -lpng is necessary when compiling with simulator video support for screen captures. I don't think there's an option in the code to turn that feature off (maybe there ought to be one?)

@juiceghost: -lz should appear at the end of the LDFLAGS string, i.e., -ledit -lpcre -lpng -lz.

[pkoning2]

I thought the build script would recognize the presence or absence of libpng and supply a defined symbol accordingly. At least I did that on a (not yet published) simulator and I'm pretty sure it wasn't something new I added.

[bscottm]

@pkoning2: I think I found the issue. -DHAVE_LIBPNG should be present on the compile command line if libpng16 was detected. I'll go see what happens when libpng16 isn't found and diagnose accordingly.

[pkoning2]

Yes, and similarly there's supposed to be a Make symbol so files depending on that library can be conditionally included in the inputs for a given simulator.

[bscottm]

@juiceghost: One issue with how you're invoking cmake/cmake-builder.sh: cmake-builder.sh does not try to detect the platform or developer environment. cmake-builder.sh needs to know the build's "flavor", which is what determines the build subdirectory. For example, my development environment is Win32 and MinGW64, which have separated build subdirectories.

This is how you ought to invoke it:

heb@howards-mbp simh % cmake/cmake-builder.sh -f xcode

I'll add a sanity check to ensure buildSubdir is set before proceeding further with the build.

[pkoning2]

But why would you have to say -f Xocde if that's an optional switch, defaulting to "use make"? It should do the right thing for any flavor.

[bscottm]

@pkoning2: It's not an optional switch, there just isn't a default (ok, need to fix that to default to Unix Makefiles.) There also isn't a check for an unset buildSubdir -- -f flavor is what sets buildSubdir (need to fix that too.)

[pkoning2]

Hm, I thought Unix was the default, but you're right, it doesn't say that. So either it should be the default or omitting -f should be an error, but doing the wrong thing isn't desirable...

[bscottm]

"Unix Makefiles" is a reasonable default? Could also probe for ninja or xcodebuild and prefer them to make if present? Thoughts?

[pkoning2]

Perhaps I was thinking of other projects that use Cmake (like Wireshark). But actually, the cmake command is documented as defaulting to the Makefile generator. And that makes some sense; it's hard to imagine a Unix system without make, while build tools like Ninja are certainly readily available but not necessarily present by default.

[bscottm]

@pkoning2: And you're correct that CMake defaults to the Makefile generator if not otherwise specified. The "nasty" that @juiceghost tripped on is the build subdirectory not being set if the -f flag is missing. Easy fix.

[bscottm]

@pkoning2: Just how loudly should cmake-builder.sh complain if -f is missing?

[pkoning2]

If you don't want to make -f unix (or some other flavor) the default, then the script should abort (do nothing) if -f is missing.

[bscottm]

@pkoning2: I suspect @juiceghost might not be at the most current version of cmake-builder.sh. The line:

[[ -d /opt/homebrew/opt/gnu-getopt/bin ]] && PATH="/opt/homebrew/opt/gnu-getopt/bin:$PATH"

is in the most current version. However, earlier in the thread, he said he needed to add that line, unless I'm misreading the thread.

[juiceghost]

I think i might have had some intermittent issues, i compiled a later commit just fine with only
make pdp11

If i can reproduce it again on my end i will make sure to save the build log.

Thanks for looking into it.

[bscottm]

@juiceghost: Couple of extra questions.

• Is there a cmake/build-unix or cmake/build-ninja subdirectory?
• Can you try the following from the top-level SIMH directory:

$ rm -rf cmake/build-unix
$ cmake/cmake-builder.sh -f unix --generate
$ (cd cmake/build-unix; make pdp11)

Does this result in a broken make?

[juiceghost]

I'll try it, but note that i did not use cmake (at least not knowingly), i do not have any build-* subfolders inside cmake/. I think that the original poster used it and i could've been more clearer when i jumped in, i've always just cloned the repo, cd into it and written make pdp11

[bscottm]

@juiceghost: My bad...

@at7heb: Couple of extra questions.

Is there a cmake/build-unix or cmake/build-ninja subdirectory?
Can you try the following from the top-level SIMH directory:

$ rm -rf cmake/build-unix
$ cmake/cmake-builder.sh -f unix --generate
$ (cd cmake/build-unix; make pdp11)

Does this result in a broken make?