ld: file not found: @rpath/libquadmath.0.dylib for architecture arm64 on MacBook Air M1

[volkov-maxim]

Hi!
I get an error ld: file not found: @rpath/libquadmath.0.dylib for architecture arm64 on MacBook Air M1 when do the make command to build the Python wrapper for aruco library.

I find libquadmath.0.dylib at two location:

• /opt/homebrew/Cellar/gcc/12.2.0/lib/gcc/current/libquadmath.0.dylib
• /opt/homebrew/Cellar/gcc/12.2.0/lib/gcc/12/libquadmath.0.dylib

When I check for arch shows arm64 as need.
lipo /opt/homebrew/Cellar/gcc/12.2.0/lib/gcc/current/libquadmath.0.dylib -archs
lipo /opt/homebrew/Cellar/gcc/12.2.0/lib/gcc/12/libquadmath.0.dylib -archs

What I'm doing wrong?

[fehlfarbe]

Hey,

unfortunately I have never worked with Apple computers so my knowledge here is very limited.

Some suggestions:

• libquadmath seems to be part of gcc. Is the gcc 12.2.0 your default compiler or are there other versions installed at it's getting mixed up?
• Is there a newer version off gcc available? Maybe it's a bug in the compiler

If you only want to detect some aruco markers/boards I can recommend to use the built in aruco detector of OpenCV's contrib module which works out of the box (but doesn't support special features like fractal markers).

[volkov-maxim]

Hi!
Thank you for your answer.

• which gcc and where gcc answered me same location is /usr/bin/gcc. I don't know about another locations;
• 12.2.0 is actual version (check brew and gcc oficial site);

Your suggestion about using OpenCV is good, but it can't be capable to detect a single marker in my case. At the same time compiled aruco utils are capable to detect a single marker. That is why I want to compile wrapper.

[sethrj]

I've been seeing this issue since Homebrew upgraded to GCC 12 and trying to build codes that link against libgfortran. For some reason the RPATH entries don't seem to work when linked against downstream libraries:

$ otool -l /opt/homebrew/opt/gcc/lib/gcc/current/libgfortran.5.dylib | grep -i -A2 RPATH
         name @rpath/libquadmath.0.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 1.0.0
--
         name @rpath/libgcc_s.1.1.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 1.1.0
--
          cmd LC_RPATH
      cmdsize 32
         path @loader_path (offset 12)

The workaround I found was to run:

$ install_name_tool -add_rpath /opt/homebrew/opt/gcc/lib/gcc/current /opt/homebrew/opt/gcc/lib/gcc/current/libgfortran.5.dylib

Unfortunately, the install tool change invalidates the code signature, which means that sometimes (I'm not sure exactly when) fortran-based applications mysteriously crash with signal 9 during dyld load: the crash log shows EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)). Restoring the shared library fixes this issue. The mysterious crash showed up for me when rebuilding openmpi during the configure stage, and building openblas during the test stage.

I'm not sure what the correct answer is, but it's definitely not an issue with python-aruco.

[jhaiduce]

The workaround I found was to run:

$ install_name_tool -add_rpath /opt/homebrew/opt/gcc/lib/gcc/current /opt/homebrew/opt/gcc/lib/gcc/current/libgfortran.5.dylib

Unfortunately, the install tool change invalidates the code signature, which means that sometimes (I'm not sure exactly when) fortran-based applications mysteriously crash with signal 9 during dyld load: the crash log shows EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)). Restoring the shared library fixes this issue. The mysterious crash showed up for me when rebuilding openmpi during the configure stage, and building openblas during the test stage.

I tried the above workaround and was seeing the signal 9 crash for every execution of any Fortran-based program. They all crashed with Killed: 9. The fix for me was to run codesign -f -s - /opt/homebrew/opt/gcc/lib/gcc/current/libgfortran.5.dylib after running the above install_name_tool command.

[sethrj]

Oh yeah, I found that out the hard way myself. I also got around it with codesigning.