Runtime dyld errors when using llvm 15 / Xcode 15 linker macos (PROJECT:dyld-1015.7)

[leorich]

Describe the bug

After macOS was updated, xcode was updated from 14 => 15, I am having runtime linker troubles. I don't understand what is happening behind the scenes from 14=>15 that is causing the new issues, but i have characterized the issue and tried tweaking some flags to get things to work.

setup and build with my project is successful, but dyld runtime linking is not working anymore (worked fine on xcode 14). Note: I am trying to link to a library that is installed to /usr/local/lib which should be on default library search path.

I have tested two cases 1) the example in the 'To reproduce' section below, 2) a larger project that involves cmake and explicitly loading libs with dlopen.

Runtime error looks something like this with case 1:

dyld[74081]: Symbol not found: __ZN8eprosima8fastrtps4rtps6Time_tC1Eij
  Referenced from: <057F7934-49AE-3F0E-8C46-B5D493301747> /Users/<>/devel/c_cpp_examples/meson_linker_issue/build/meson_build/example_exe
  Expected in:     <no uuid> unknown
zsh: abort      ./build/meson_build/example_exe

But with case 2 the error looks more like this:

dlopen(libpip_simple.dylib, 0x0005): Library not loaded: @rpath/libfastrtps.2.11.dylib
  Referenced from: <8BE90F54-7889-3680-9331-BF7F9CA09EA1> libpip_simple.dylib
  Reason: tried: <><><>...libfastrtps.2.11.dylib' ..  (no such file),'

In the simple case 1 - I was able to export DYLD_LIBRARY_PATH=/usr/local/lib and runtime worked fine. However, for case (2) this did not fix the dlopen error.

If I instead set export LDFLAGS="-rpath /usr/local/lib" - that gets rid of the runtime linking issue in both cases.. (and also results in a lot of ld: warning: duplicate -rpath '/usr/local/lib' ignored chatter)

I also messed with OTHER_LDFLAGS=-ld_classic per xcode 15 release notes to no avail.

more info on case 2

I have yet to reproduce the issue just by trying to dlopen a library built by meson that depends on a /usr/local/lib.. the setup where i see the error is a little more complicated by cmake:

libraryA

• depends on libraryB

libraryB

• configured with subproject cmake
• depends on third-party lib in /usr/local/lib

I cant dlopen libraryA because it cant load/dlopen the third-party lib. This may very well be a cmake issue (on the cmake side, -DCMAKE_INSTALL_RPATH_USE_LINK_PATH="ON" has been fixing my pure cmake projects - they broke in this update too)

I will keep working on a minimal example to reproduce this.. and this issue could be on me with a bad cmake file - but it did work before the update.

To Reproduce
install fastrtps (or some third party library) to /usr/local

project('meson_cmake_test', 'c', 'cpp',
  default_options: ['c_std=gnu99',
                    'cpp_std=c++17',
                    ],  
  version : '0.1.0-0.dev',
  meson_version: '>=0.60.0')

fastrtps_dep = dependency('fastrtps',
    required: false,
    disabler: true,
)

example_exe = executable('example_exe', 'main.cpp',
                    dependencies: [fastrtps_dep])

#include <iostream>

#include <fastrtps/qos/ReaderQos.h>

int main()
{
  // Test that we can symbols defd in dep
  eprosima::fastrtps::ReaderQos qos;
  qos.checkQos();

  std::cout << "done." << std::endl;

  return 0;
}

Expected behavior
No runtime errors, as it worked on the same system just before the update from 14 to 15.

Did not expect to need to modify env with export DYLD_LIBRARY_PATH=/usr/local/lib or export LDFLAGS="-rpath /usr/local/lib"

system parameters

• Native build
• MacOS 13.5.2 (22G91), M2 pro chip
• python 3.9.6
• meson version: current master (8d6b474) to include the version check change
• ninja 1.11.1

Some concerning? meson output:

Detecting Apple linker via: `c++ -Wl,-v` -> 1
stderr:
@(#)PROGRAM:ld  PROJECT:dyld-1015.7
BUILD 18:48:48 Aug 22 2023
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k armv7m armv7em
LTO support using: LLVM version 15.0.0 (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12.3)
Library search paths:
	/usr/local/lib
Framework search paths:
ld: Undefined symbols:
  _main, referenced from:
      <initial-undefines>
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[luigifcruz]

I can also replicate this issue.

[pramsey]

Not a meson issue, but more of an undocumented change (bug?) in behaviour with XCode 15. /usr/local/lib is no longer a preferred search location for dyld, so you cannot just dump a lib there and expect the linker to always find it. https://developer.apple.com/forums/thread/737920