> On MacOS X, when A is dynamically linked with B (that is at build > time), the "install path" of B is recorded into A (more precisely, > into the result of linking A with B), so that at runtime (link before > the executable is run, not dlopen()), B is searched for B's "install > path". > > So they are kind of opposite concepts, and not in the same case: one > for dlopen(), the other for dynamic linking. Runtime vs build time.
IIUC you are referring to a "dependent library", which is linked at build time, but the actual case is a "runtime loaded library".[1] So it works similarly as the linux dlopen, except that there is no working "-rpath" option, and no "$ORIGIN". The solenv/bin/macosx-change-install-names tool is used to handle dependent libraries, using "otool -L" to track dependencies, but in case of a runtime loaded library, the dependency cannot be tracked before runtime, so it doesn't show up for "otool -L", thus this tool cannot be used. It seems, I can use dylib tokens like "@loader_path/libEngine12.dylib" in the string passed to dlopen. It worked in the external, but not after copying to instdir. I don't know yet why. [1] first paragraph: https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/UsingDynamicLibraries.html Tamás _______________________________________________ LibreOffice mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice
