Mac homebrew failling to install

[robot-army]

OpenEMS_Brew_Install_Fail.txt

Attached is a full console dump of a failure to install under brew on a (fairly) fresh copy of MacOS 10.14.6.

I'd really love to try this out! Anyone got any tips?

It seems to stop around 75% pretty consistently:

==> cmake . -DCMAKE_C_FLAGS_RELEASE=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE=-DNDEBUG 
==> make
Last 15 lines from /Users/robotarmy/Library/Logs/Homebrew/openEMS/02.make:
-- Installing: /usr/local/Cellar/openEMS/HEAD-78e7642/share/openEMS/matlab/ReadHDF5FieldData.m
-- Installing: /usr/local/Cellar/openEMS/HEAD-78e7642/share/openEMS/matlab/ResultsQueue.m
-- Installing: /usr/local/Cellar/openEMS/HEAD-78e7642/bin/nf2ff
-- Installing: /usr/local/Cellar/openEMS/HEAD-78e7642/lib/libnf2ff.0.1.0.dylib
-- Installing: /usr/local/Cellar/openEMS/HEAD-78e7642/lib/libnf2ff.0.dylib
-- Installing: /usr/local/Cellar/openEMS/HEAD-78e7642/lib/libnf2ff.dylib
-- Installing: /usr/local/Cellar/openEMS/HEAD-78e7642/include/openEMS/nf2ff.h
-- Installing: /usr/local/Cellar/openEMS/HEAD-78e7642/include/openEMS/nf2ff_calc.h
cd /tmp/openEMS-20190729-17544-kbgtth/openEMS-prefix/src/openEMS-build && /usr/local/Cellar/cmake/3.15.1/bin/cmake -E touch /tmp/openEMS-20190729-17544-kbgtth/openEMS-prefix/src/openEMS-stamp/openEMS-install
[ 75%] Completed 'openEMS'
/usr/local/Cellar/cmake/3.15.1/bin/cmake -E make_directory /tmp/openEMS-20190729-17544-kbgtth/CMakeFiles
/usr/local/Cellar/cmake/3.15.1/bin/cmake -E touch /tmp/openEMS-20190729-17544-kbgtth/CMakeFiles/openEMS-complete
/usr/local/Cellar/cmake/3.15.1/bin/cmake -E touch /tmp/openEMS-20190729-17544-kbgtth/openEMS-prefix/src/openEMS-stamp/openEMS-done
[ 75%] Built target openEMS
make: *** [all] Error 2

Do not report this issue to Homebrew/brew or Homebrew/core!

[rookie880]

I get the same error. Did you ever find a solution?

[robot-army]

No, and it's been some time since I've tried.

Thinking of looking again, but I've pretty much moved over to Linux exclusively for this type of thing.

Anyone else had any luck?

[thliebig]

Yes supporting Mac is unfortunately difficult for me as I have no Apple hardware... Any help is welcome.

[aWZHY0yQH81uOYvH]

I just messed with this for quite a while and have just gotten openEMS what appears to be fully working on macOS. Here are the steps I took.

# get openEMS
git clone --recurse-submodules https://github.com/thliebig/openEMS-Project.git

Edit openEMS-Project/QCSXCAD/CMakeLists.txt to add set(CMAKE_CXX_STANDARD 17) to the top.

# install dependencies
brew install cmake qt@5 vtk@8.2 tinyxml hdf5 gmp mpfr boost cgal

# need old versions of Qt and VTK, not current ones
brew unlink qt vtk

# tell CMake where the old Qt and VTK versions are
export Qt5_DIR=$(brew --prefix qt@5)
export Qt5Xml_DIR=$(brew --prefix qt@5)
export VTK_DIR=$(brew --prefix vtk@8.2)

# make build dir and configure project
cd openEMS-Project
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=[wherever you want] ..

# build
make -j12

# re-link normal versions of Qt and VTK if you had them installed
brew link qt vtk

You may need to modify bin/AppCSXCAD.sh and bin/openEMS.sh to add the following lines so that the built libraries can be found if you install into a nonstandard path.

# AppCSXCAD.sh
export DYLD_LIBRARY_PATH=$BIN_PATH/../lib

# openEMS.sh
export DYLD_LIBRARY_PATH=$openEMS_PATH/../lib

Not sure how difficult it is to put all of this into a normal brew script. The main problem is getting CMake to ignore the new versions of Qt and VTK.

[thliebig]

The latest version should work with vtk9.1? I have not yet tried Qt6 but it is a bit odd that brew has no easy way to have both qt5 and qt6 available? But this looks like a nice install instructions. Try to make it a nice brew file. Where would that file need to go?

[aWZHY0yQH81uOYvH]

I just tried it with the latest version of VTK brew installs (9.2.2 — it's either that or 8.2) and it fails with a bunch of symbols missing:

Undefined symbols for architecture x86_64:
  "vtkAxesActor::SetTotalLength(double, double, double)", referenced from:
      QVTKStructure::AddAxes() in QVTKStructure.cpp.o
  "vtkAxesActor::New()", referenced from:
      QVTKStructure::AddAxes() in QVTKStructure.cpp.o
  "vtkPLYWriter::New()", referenced from:
      VTKPrimitives::WritePolyData2PLY(char const*, double) in VTKPrimitives.cpp.o
  "vtkPNGWriter::New()", referenced from:
      QVTKStructure::ExportView2Image() in QVTKStructure.cpp.o
  "vtkSTLReader::New()", referenced from:
      VTKPrimitives::AddSTLObject(char const*, double*, double*, double, double const*) in VTKPrimitives.cpp.o
  "vtkSTLWriter::New()", referenced from:
      VTKPrimitives::WritePolyData2STL(char const*, double) in VTKPrimitives.cpp.o
  "vtkVectorText::New()", referenced from:
      VTKPrimitives::AddLabel(char*, double*, double*, double, double, double const*) in VTKPrimitives.cpp.o
  "vtkXMLWriterBase::Write()", referenced from:
      VTKPrimitives::WritePolyData2File(char const*, double) in VTKPrimitives.cpp.o
  "vtkXMLPolyDataWriter::New()", referenced from:
      VTKPrimitives::WritePolyData2File(char const*, double) in VTKPrimitives.cpp.o
  "vtkLinearExtrusionFilter::New()", referenced from:

...

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Brew does allow you to have Qt5 and Qt6 installed, but it only symlinks one of them to /usr/local at a time (otherwise there would be chaos). The way CMake is set up it adds /usr/local to the compiler include paths before the stuff in Qt5_DIR, so it ends up defaulting to Qt6, and sometimes also finds files from Qt5, which causes a bunch of redefinition errors. I figured the easiest way would be to "hide" Qt6 by removing the symlinks to /usr/local and then putting them back afterwards.

To make it work in a brew script, it would probably be easiest to change the order of the include paths given to the compiler for QCSXCAD (in addition to adding the C++17 requirement) in CMakeLists. Then it would properly obey the Qt5_DIR and could probably be installed without unlinking stuff.

[thliebig]

ok, qt5 and vtk8.2 will then do for now.

As for the other recommendations, would you care to create a pull request? It would be easy for me to add (and test) the C++17 requirement, but I'm unsure about the oroder of include paths? In any case you brew file above looks reasonable simple enough?

[aWZHY0yQH81uOYvH]

Well... turns out the Homebrew developers are very smart and know quite a bit about CMake. The only changes required to the script to make it work again are to update the dependencies. The updated script is here. Evidently *std_cmake_args pulls a lot of weight here and automatically forces CMake to only look for the dependencies listed in the depends_on clauses, in addition to fixing the search path order and making it compile with C++17...

Unfortunately though brew is very unhappy with supplying a URL for a random formula on the command line (a change in behavior from before):

$ brew install --HEAD https://raw.github.com/thliebig/openEMS-Project/master/brew/openEMS.rb
Error: Non-checksummed download of openEMS formula file from an arbitrary URL is unsupported! `brew extract` or `brew create` and `brew tap-new` to create a formula file in a tap on GitHub instead.

... and it wants you to have a thliebig/homebrew-openems repository in order for brew tap thliebig/openems to work. I've tried "tapping" my branch in this way, but even if you give it the URL to the openEMS-Project repo, it seems to be unable to find the ruby script in the brew subdirectory when running brew install.

For testing I've found that just giving it a file path works: brew install --HEAD /tmp/openEMS.rb, though it does seem to think it's a cask at first for some reason.

I can open a PR if you want, or you might want to consider making the additional repository according to the normal naming convention like this, for example: https://github.com/ARMmbed/homebrew-formulae

EDIT: You don't necessarily need to make a new repo if you just move the brew file to the root directory of this one. PR #20

Also if any others would like to see if my updated formula works, that would be a good datapoint.

[thliebig]

I have merged it. Do we need additional changes/steps to get this working? One note. Since the openEMS.rb is now in the root, can we make some comments in the file that it belongs to the brew system? Otherwise people may wonder what it is about? But that has to hurry...

[aWZHY0yQH81uOYvH]

I just did another install of it this time from your repo and it seems to be working. I may be able to try it on an M1 Mac soon (curious how speed compares).

Adding some comments would probably be a good idea. Is that something you'd like me to do or...? The BREW-README.md file is also a bit non-obvious, but presumably you could point to that from the website's install instructions?

[thliebig]

Ok sounds good. Feel free to update the comments and readme, you would know best what helps etc.

Maybe you could also edit the doc-src/install.rst (reStructuredText) with a Mac Section? Would be happy to rebuild and update the doc and link to it on the website.

I reopen this until we are happy with the state of things. (It got auto-closed by the merge?)

[aWZHY0yQH81uOYvH]

Just did a test on an M1 Pro MacBook. The CMake file for openEMS isn't correctly identifying the CPU architecture (here) as aarch64 and it just fails saying the architecture isn't supported. After forcing it to use aarch64, it does compile. The other problem is that vtk@8.2 is deprecated and Homebrew doesn't want to install it if it isn't already installed, but for some reason CSXCAD won't compile with the latest vtk 9.2 (missing symbols as mentioned previously). Those two things will need to be fixed before we can close this issue.

Once it does compile, though, it's about 90% as fast as an overclocked 5950X drawing 200W, while the laptop sits there with its fans barely running. Still on both it runs fastest when using only 4 out of the 10 or 16 available CPU cores.

[0xCoto]

On the M2 (#95) this user gets up to 230 MC/s so you should probably be getting almost a 10x improvement (considering the 5950X runs at about 2300 MC/s)? Very interesting considering the difference in CPU cost.

[aWZHY0yQH81uOYvH]

I was getting 164MC/s with the Patch_Antenna.m example on the 5950X and something around 145MC/s on the M1 Pro. I think that 2300MC/s you're quoting was from when I had the extensions removed for testing the CUDA fork.

[0xCoto]

Ah that was without the extensions, ok

[thliebig]

I just pushed a commit to openEMS that increases the number of threads to hopefully find the optimal number automatically. Give it a try if it helps any...

[aWZHY0yQH81uOYvH]

I'm noticing that when you start a run on a cold CPU, the clock speed is automatically increasing at the start because it has more thermal headroom, then slowing down as the CPU heats up. This makes the earlier timestep blocks run faster than they would in steady-state and sometimes throws off the automatic selection, for example making it choose 1 or 2 threads when 4 would be optimal.

Maybe it would help to make it more "cautious" in setting m_opt_speed to false? So that when it thinks it has found a slower configuration, maybe it tries going back to the previous number of threads to check to make sure more threads is in fact slower.

Also, to make the Homebrew thing fully work, the AppCSXCAD submodule in here needs to be updated to the more recent commits. Otherwise Homebrew does seem to be working with the install instructions I put in the doc file.

[thliebig]

Yeah this "find the best number of threads" is very much a first working prototype ;)

Yeah I missed to update the AppCSXCAD module... fixed now...

[thliebig]

BWT, does the python interface work for mac too? There are no install/build instructions for it?

[aWZHY0yQH81uOYvH]

Just checked... while you can compile all the stuff fine using the instructions in the readme, the python bindings are no longer compatible with the latest version of numpy (1.24.1) because .float no longer exists.

Traceback (most recent call last):
  File "/tmp/openEMS-Project/openEMS/python/Tutorials/Simple_Patch_Antenna.py", line 97, in <module>
    port = FDTD.AddLumpedPort(1, feed_R, start, stop, 'z', 1.0, priority=5, edges2grid='xy')
  File "openEMS/openEMS.pyx", line 303, in openEMS.openEMS.openEMS.AddLumpedPort
  File "/usr/local/lib/python3.10/site-packages/openEMS-0.0.33-py3.10-macosx-13-x86_64.egg/openEMS/ports.py", line 152, in __init__
    super(LumpedPort, self).__init__(CSX, port_nr=port_nr, start=start, stop=stop, excite=excite, **kw)
  File "/usr/local/lib/python3.10/site-packages/openEMS-0.0.33-py3.10-macosx-13-x86_64.egg/openEMS/ports.py", line 67, in __init__
    self.start    = np.array(start, np.float)
  File "/usr/local/lib/python3.10/site-packages/numpy/__init__.py", line 284, in __getattr__
    raise AttributeError("module {!r} has no attribute "
AttributeError: module 'numpy' has no attribute 'float'. Did you mean: 'cfloat'?

It also complains about setup.py being deprecated during the install, but it still works.

/usr/local/lib/python3.10/site-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.

I also had a quick look at CTB and hyp2mat. CTB probably won't install because the BSD version of cp doesn't have the -t flag, but that would be trivial to fix if wanted. hyp2mat would probably work (or be relatively easy to get working) since it appears to have worked on macOS in the past (at least in 2015) and looks to be a relatively straightforward C++ project.

Homebrew does have the facility to take install flags to enable/disable certain parts of a formula, so it would be possible to emulate the flags of update_openEMS.sh.

[thliebig]

Well I guess np.float has to be replaced with np.single? I really don't like when packages just like that change their api ...

My python 3.10.x with python setup.py --help-commands just tells me about "install" very much as always... But I will have a look...

[biergaizi]

Well I guess np.float has to be replaced with np.single? I really don't like when packages just like that change their api ...

No, it should be placed with just the plain old float.

DeprecationWarning: np.float is a deprecated alias for the builtin float. To silence this warning, use float by itself. Doing this will not modify any behavior and is safe. If you specifically wanted the numpy scalar type, use np.float64 here.

[biergaizi]

The Python module can be built on macOS, but at runtime, it crashes at assert os.getcwd() == sim_path for some reason. Not sure what happens. Running openEMS on macOS is plagued with path problems.

[biergaizi]

Also, all the speed tests on macOS are likely underestimated. To get a fair result, openEMS must be built with GCC. LLVM/clang cannot generate efficient vectorized code for the SSE/SIMD engine due to an unknown technical problem (this is not a macOS issue, but a LLVM/clang issue, since the problem exists on FreeBSD as well), so we must build openEMS with GCC to get a reasonable comparison.

Unfortunately, using CC="gcc-12" and CXX="g++-12", CSXCAD fails to build due to a linking issue on macOS.

[aWZHY0yQH81uOYvH]

After macOS Ventura was released, it seems like the homebrew method for installing no longer works again. Brew seems to give cmake some flags such that it runs into this issue where it can't compile the system-provided header files. It happens on x64 and arm machines. I've messed with it for a while and can't get it to work because of homebrew's sanitization of environment variables and "smart" checking that prevents you from changing the SDK version.

However, if the prerequisites are all installed with brew, openEMS seems to build and run fine without modification using the normal install procedure (checkout, cmake, make). Therefore, I assume this is an issue that the homebrew devs or Apple would need to address.

Edit: see #115

[biergaizi]

@aWZHY0yQH81uOYvH It seems that you've missed the long and extensive discussion on these problems at here: https://github.com/thliebig/openEMS-Project/discussions/108 Please continue the discussion using that thread.

[biergaizi]

This issue has been used to track too many different macOS build problems. At this point, I believe all the known issues have been fixed and this issue can be safely closed. Please close this issue. Should a new problem appear, one can open a new issue.