apple silicon build problem(s?)

Question

apple silicon build problem(s?)

at7heb opened this issue a year ago · 26 comments

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...

Answer 1 · 2023-09-15T13:12:35.000Z

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).

Answer 2 · 2023-09-15T13:49:21.000Z

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...

Answer 3 · 2023-09-16T19:49:34.000Z

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.

Answer 4 · 2023-09-17T16:54:06.000Z

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

Answer 5 · 2023-09-18T17:05:33.000Z

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.

Answer 6 · 2023-09-18T17:08:41.000Z

Never mind on the gentle hint. I saw this:

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

Answer 7 · 2023-11-03T12:23:35.000Z

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.

Answer 8 · 2023-11-03T13:23:17.000Z

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

Answer 9 · 2023-12-04T17:32:47.000Z

@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.

Answer 10 · 2023-12-04T17:38:01.000Z

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.

Answer 11 · 2023-12-04T17:46:51.000Z

@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.

Answer 12 · 2023-12-04T17:59:01.000Z

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.

Answer 13 · 2023-12-04T18:00:15.000Z

@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.

Answer 14 · 2023-12-04T18:07:41.000Z

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.

Answer 15 · 2023-12-04T18:09:32.000Z

@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.)

Answer 16 · 2023-12-04T18:26:47.000Z

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...

Answer 17 · 2023-12-04T18:40:30.000Z

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

Answer 18 · 2023-12-04T18:43:13.000Z

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.

Answer 19 · 2023-12-04T18:47:36.000Z

@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.

Answer 20 · 2023-12-04T18:53:23.000Z

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

Answer 21 · 2023-12-04T19:11:47.000Z

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.

Answer 22 · 2023-12-04T19:51:51.000Z

@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.

Answer 23 · 2023-12-05T18:27:19.000Z

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.

Answer 24 · 2023-12-06T17:44:48.000Z

@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?

Answer 25 · 2023-12-06T20:56:35.000Z

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

Answer 26 · 2023-12-07T00:36:32.000Z

@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?

Context

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