Hello,
I maintain MacPort’s packaging for Audacity; my port currently ships either v2.4.2 (“audacity-legacy”) and v3.0.2 via so-called subports. By default the port build process will grab a copy of the custom wxWidgets sources and build them via the CMake build system.
It has come to my attention that the wxWidgets build ends up with shared libraries that have an id/install_name that references the build directory. This is corrected partly during the creation of the appbundle, but not completely. Only install_name_tool -change is used to correct dependencies in the wx libraries, but not install_name_tool -id; also, the mod-script-pipe.so plugin is not fixed at all. Both subports use the same custom wxWidgets version (commit #07e7d83) so it is not surprising that both are affected by this issue.
Interestingly, I observe a comparable situation with the rpath information on Linux. I use essentially the same build recipe there as on Mac, and find that the wx libraries (in /opt/local/lib/audacity) have rpath entries pointing into the build directory; the mod-script-pipe.so plugin even has 2 different locations under the build.dir (and NOT to /opt/local/lib/audacity!).
I’ve done a bit of tinkering in cmake-proxies/wxWidgets/CMakeLists.txt (setting CMAKE_INSTALL_NAME_DIR and CMAKE_INSTALL_PREFIX to the desired locations) but this seems to have no effect whatsoever.
Am I doing something wrong and has this come up before?
FWIW, if the wxWidgets libraries can only be corrected post-hoc (by invoking CopyLibs.cmake), then it should be done in the proxy CMake file - directly after being built, in the directory where the wx build left them and before any dependent can link to them.