Crash on launch on macOS 15.4 Beta

[R6A8kJOk]

uv (Nightly Built 2025-03-13T08:34+00:00) crashes on launch in macOS Beta 15.4 Beta (24E5228e) on ARM (Tested on M1 and M4 Pro)

% ./uv
dyld[1208]: Library not loaded: @executable_path/../libs/libopenblasp-r0.3.29.dylib
  Referenced from: <F64DD98E-E485-3375-AD4C-4F77854B8B9C> /Users/user/Desktop/uv-qt.app/Contents/libs/libopencv_core.4.11.0.dylib
  Reason: tried: '/Users/user/Desktop/uv-qt.app/Contents/libs/libopenblasp-r0.3.29.dylib' (duplicate LC_RPATH '@executable_path/../libs/')
zsh: abort      ./uv

Also crashes instantly when using uv-qt, displays error message: "UltraGrid has crashes when invoked without arguments".

Going back through releases, this affects all ARM builds back to 1.9.0.

The 1.8.0 Intel version in Rosetta at least appears to launch correctly.

% ./uv-qt\ 1.8.app/Contents/MacOS/uv
UltraGrid 1.8 (tags/v1.8 rev 38c3c19 built Dec  9 2022 14:45:42)

Don't know what Apple has changed, but I suspect some SIP shenanigans.

[MartinPulec]

Hi, thanks for reporting. Can you give me more information on that?

uv (Nightly Built 2025-03-13T08:34+00:00)

can you point me to the actual build? continuous, 1.9.8 or a custom build from the sources?

crashes on launch in macOS Beta 15.4 Beta (24E5228e)

unfortunately we don't have that beta installed - if you can try, does it crash on 15.3.2 as well?

The 1.8.0 Intel version in Rosetta at least appears to launch correctly.

we still build both architectures so can you try some Intel build newer than 1.8, eg. 1.9.8?

Unfortunately I currently cannot identify what triggers the problem - if this is the beta version of macOS or something else? If this affects 15.4 version of macOS, I believe that it will be released soon so I'll be able to test there.

[R6A8kJOk]

OK, on 15.3.2 I think all those build run fine. Starting in the 15.4 beta, many of the newer ones crash.

I tried these versions from the Releases page, all on the 15.4 Beta, running on ARM hardware, or Intel code running in Rosetta on that ARM hardware.

Nightlies
ARM Continuous: Crash
Intel Continuous: Crash

1.9.8
ARM: Crash
Intel: Crash

1.9.0
ARM: Crash
Intel: Crash

1.9.5
ARM: Crash
Intel: Crash

1.8.7
Intel: Crash

1.8.5
Intel: Crash

1.8.4
Intel: ok

1.8.3
Intel: ok

1.8.0
Intel: ok

So looks like the problem was introduced in 1.8.5 and now triggers in the macOS 15.4 betas.

Tried disabling SIP, same errors.

[R6A8kJOk]

Digging some more:

If the error
duplicate LC_RPATH '@executable_path/../libs/'
really is the issue, then this is a intentional deprecation that Xcode has been announcing for a year now and is scheduled to be a hard error since Fall 2024.

https://github.com/apple-oss-distributions/dyld/

Filed a feedback with Apple to clarify, but don't have any hopes for a reasonable reply.

Looking at the library, it really has multiples of RPATHs

 otool -l uv-qt.app/Contents/libs/libopenblasp-r0.3.28.dylib
...
Load command 16
          cmd LC_RPATH
      cmdsize 40
         path @executable_path/../libs/ (offset 12)
Load command 17
          cmd LC_RPATH
      cmdsize 40
         path @executable_path/../libs/ (offset 12)
Load command 18
          cmd LC_RPATH
      cmdsize 40
         path @executable_path/../libs/ (offset 12)
Load command 19
          cmd LC_RPATH
      cmdsize 40
         path @executable_path/../libs/ (offset 12)

Looked at the dylibbundler, maybe this loop is an issue?

Found some more related discussion here.

[R6A8kJOk]

Found a workaround with some help:

for i in {1..3}; do
  install_name_tool -delete_rpath '@executable_path/../libs/' uv-qt-nightly.app/Contents/libs/libopenblasp-r0.3.29.dylib
done

sudo codesign --remove-signature uv-qt-nightly.app
codesign --force --deep --sign - uv-qt-nightly.app

sudo xattr -rd com.apple.quarantine uv-qt-nightly.app

Remove the faulty RPATH three times, then resign the build. Don't know where the fault is introduced, but this works for me for now.

[MartinPulec]

If the error
duplicate LC_RPATH '@executable_path/../libs/'
really is the issue, then this is a intentional deprecation that Xcode has been announcing for a year now and is scheduled to be a hard error since Fall 2024.

Thank you very much for the investigation, this is very helpful. I've looked at that library as it comes from Homebrew and it seems that the original library has four times LC_RPATH:

$ otool -l /opt/homebrew/Cellar/openblas/0.3.29/lib/libopenblasp-r0.3.29.dylib  | grep -B 1 -A 2 LC_RPATH
Load command 16
          cmd LC_RPATH
      cmdsize 32
         path @loader_path (offset 12)
Load command 17
          cmd LC_RPATH
      cmdsize 80
         path /opt/homebrew/opt/gcc/lib/gcc/current/gcc/aarch64-apple-darwin24/14 (offset 12)
Load command 18
          cmd LC_RPATH
      cmdsize 56
         path /opt/homebrew/opt/gcc/lib/gcc/current/gcc (offset 12)
Load command 19
          cmd LC_RPATH
      cmdsize 56
         path /opt/homebrew/opt/gcc/lib/gcc/current (offset 12)

where there are distinct LC_RPATH values but something is obviously replacing all instances with that @executable_path/../libs/.

Looked at the dylibbundler, maybe this loop is an issue?

possibly. I'll try to take a look.

[MartinPulec]

seems like dylibbundler2 really replaces all instances of RPATH by that same string (@executable_path/../libs/) as can be seen by:

$ echo 'int main() {}' | clang -xc - -L /opt/homebrew/Cellar/openblas/0.3.29/lib/ -l openblas
$ dylibbundler -of -cd -b -d bundle/Contents/libs -p @executable_path/../libs/ -x a.out
$ otool -l bundle/Contents/libs/libopenblasp-r0.3.29.dylib |
     grep -B 1 -A 2 LC_RPATH | grep -c '@executable_path/../libs/'
4

I've tried to create a workaround that could fix it. Would it be possible for you to try it out? The build can be downloaded from the GH Action (GitHub AFAIK requires login for the download, so alternatively it can be downloaded here),

[R6A8kJOk]

Awesome!

Can confirm the fix works on the 15.4 beta and still works on 15.3 release version.

% export DYLD_PRINT_LIBRARIES=1       
% ./uv-qt-rpathfix.app/Contents/MacOS/uv
...
dyld[5527]: <F64DD98E-E485-3375-AD4C-4F77854B8B9C> /Users/user/Desktop/uv-qt-rpathfix.app/Contents/libs/libopencv_core.4.11.0.dylib
dyld[5527]: <A026A1E0-B5A1-3945-94F9-03BE8BCC173C> /Users/user/Desktop/uv-qt-rpathfix.app/Contents/libs/libopencv_imgproc.4.11.0.dylib
..
dyld[5527]: <31552F5E-E50A-314D-8073-6FE3DBFA7DF2> /Users/user/Desktop/uv-qt-rpathfix.app/Contents/libs/libopenblasp-r0.3.29.dylib
..

MasterPortDestroyer is armed
UltraGrid 1.9+ (master rev 6670a26 built Mar 18 2025 09:38:43)
...

Now not entirely sure if this deprecation in Xcode should really be a breaking change in dyld in macOS, but anyways this is working now and Apple might fix dyld or not.

Thank you very much for the fix, learned a lot along the way as well.

[MartinPulec]

Thanks a lot for your assistance, it was very helpful.

I've just pushed the workaround to the master branch - personally I think it will be best if dylibbundler handles that by itself, because if the input has multiple (but distinct) LC_RPATHs, the tool actually makes it wrong by replacing all instances with the argument of -p. But we will see.

[R6A8kJOk]

macOS 15.4 RC2 likely will be published to customers this coming week and still exhibits the crash without this workaround.

Also looked at the dyld binary - the error message was added only in 15.4, maybe it is intentional after all.

[MartinPulec]

I can confirm that I am able to reproduce it in just-released macOS 15.4 (arm). So we will back-port the fix in next stable dot release.

Also looked at the dyld binary - the error message was added only in 15.4, maybe it is intentional after all.

From the policy name Policy::enforceNoDuplicateRPaths in your linked code, I would suppose that it is intentional, indeed. No idea, why the duplicates are considered harmful but certainly it is slightly better if those rpaths aren't multiplied.