On Wed, Jan 2, 2019 at 4:15 PM René Jansen <rvjan...@xs4all.nl> wrote:
> I finally took the time to read up on the dynamic linker on macOS. Linking > the dylibs into /usr/local/lib is not the solution. (And it requires > sudo/root, which we should not need for a local, portable installation.) > This https://matthew-brett.github.io/docosx/mac_runtime_link.html is a > good and short introduction. @Rick, there is a question for you at the > bottom of this mail. > > DYLD_FALLBACK_LIBRARY_PATH > This is a colon separated list of directories that contain > libraries. It is used as the default > location for libraries not found in their > install path. By default, it is set to > $(HOME)/lib:/usr/local/lib:/lib:/usr/lib. > > macOS does not require an DYLD_LIBRARY path. If we compare the generated > binaries and libraries in oorexx-code0/bin (with an in-place cmake), with > the installed ones, we see this difference: > > oorexx-code-0/bin: > > ➜ bin otool -L rexx > rexx: > /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version > 400.17.0) > /Users/rvjansen/apps/oorexx-code-0/bin/librexx.5.0.0.dylib (compatibility > version 0.0.0, current version 5.0.0) > /Users/rvjansen/apps/oorexx-code-0/bin/librexxapi.5.0.0.dylib > (compatibility version 0.0.0, current version 5.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1252.200.5) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version > 400.9.4) > > /Applications/ooRexx /bin > > ➜ bin otool -L ~/Applications/ooRexx5.0.0/bin/rexx > /Users/rvjansen/Applications/ooRexx5.0.0/bin/rexx: > /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version > 400.17.0) > librexx.5.0.0.dylib (compatibility version 0.0.0, current version 5.0.0) > librexxapi.5.0.0.dylib (compatibility version 0.0.0, current version 5.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1252.200.5) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version > 400.9.4) > > and for the libraries: > > librexx.dylib: > /Users/rvjansen/apps/oorexx-code-0/bin/librexx.5.0.0.dylib (compatibility > version 0.0.0, current version 5.0.0) > /Users/rvjansen/apps/oorexx-code-0/bin/librexxapi.5.0.0.dylib > (compatibility version 0.0.0, current version 5.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1252.200.5) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version > 400.9.4) > > versus, for the installed version: > > ➜ bin otool -L ~/Applications/ooRexx5.0.0/lib/librexx.dylib > /Users/rvjansen/Applications/ooRexx5.0.0/lib/librexx.dylib: > librexx.5.0.0.dylib (compatibility version 0.0.0, current version 5.0.0) > librexxapi.5.0.0.dylib (compatibility version 0.0.0, current version 5.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1252.200.5) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version > 400.9.4) > > This shows why the installed version needs a DYLD_LIBRARY_PATH, which we > know from what Erich found, will not be propagated to subshells. > It is true that @rpath is set in the executable and the libraries, but > this appears not to work for the installed version. To be precise, it works > when executing from the /lib directory with the executable in the path, but > only from there; it is not relocatable over the filesystem as it should be. > > The version in oorexx-code-0/bin is *almost* relocatable: when executed > in-place, it is fine. When on the PATH and executed from another place in > the filesystem, it fails with 'Failure loading required base library’; > this, however is from the ooRexx interpreter itself. When I then > > ln -s ~/apps/oorexx-code-0/bin/librexxutil.5.0.0.dylib librexxutil.dylib > > to the current dir, I can execute from it. This goes for every location on > the filesystem. > > A dyld trace shows that the rexx executable loads the librexx.5.0.0.dylib > and the librexxapi.5.0.0.dylib using dyld (the dynamic loader) from the > path specified in the executable, but not librexxutil. The message comes > from interpreter/package/LibraryPackage.cpp. > > This is from a successful run: > > ➜ oorexx-code-0 rexx -e 'x=1; say x/2' > dyld: loaded: /Users/rvjansen/apps/oorexx-code-0/bin/rexx > dyld: loaded: /usr/lib/libc++abi.dylib > dyld: loaded: /Users/rvjansen/apps/oorexx-code-0/bin/librexx.5.0.0.dylib > dyld: loaded: /Users/rvjansen/apps/oorexx-code-0/bin/librexxapi.5.0.0.dylib > dyld: loaded: /usr/lib/libSystem.B.dylib > dyld: loaded: /usr/lib/libc++.1.dylib > dyld: loaded: /usr/lib/system/libcache.dylib > dyld: loaded: /usr/lib/system/libcommonCrypto.dylib > /* snip */ > dyld: loaded: /usr/lib/system/libsystem_trace.dylib > dyld: loaded: /usr/lib/system/libunwind.dylib > dyld: loaded: /usr/lib/system/libxpc.dylib > dyld: loaded: /usr/lib/libobjc.A.dylib > dyld: loaded: librexxutil.dylib > 0.5 > > Without the symbolic link, it ends with: > > dyld: loaded: /usr/lib/system/libunwind.dylib > dyld: loaded: /usr/lib/system/libxpc.dylib > dyld: loaded: /usr/lib/libobjc.A.dylib > Logic error: Failure loading required base library > [1] 29286 illegal hardware instruction rexx -e 'x=1; say x/2’ > > So it seems that for an installation on macOS we have two problems: the > locations of the libraries in the installed version (as opposed to the > version built in oorexx-code-0/bin) are wrong - or should have a working > @rpath. LibraryPackage.cpp seems to find the library in another way than > dyld does, but does succeed when it is in the current directory. > > I am tempted to relink e.g. librexx.dylib and put the librexxutil methods > in there so that dyld can find them, but seeing the source of LibraryPage > it seems to reconstruct a functiontable on the load of the image, and I do > not oversee the consequences at the moment. Is there something we can do so > LibraryPackage finds the librexxutils.dylib where the other ones are? I > think we are very close then to solving the failing testcases on the mac > (due to the DYLD_LIBRARY_PATH issue mentioned) and also to a portable, > non-admin installer for the mac. > Just relinking them together won't work. None of those routines are loaded directly but rather through the table loader mechanism. rexxutil is maintained as a separate library because of all of the old programs that still had rxfuncadd() calls to manually load the routines for the way it used to work. I think with the way loader is working it probably would be possible to eliminate the separate dll altogether, but then you would still have the same problem with all the rest of the extensions (rxsock, rxmath, etc.). Rick > > best regards, > > René. > > > On 1 Jan 2019, at 17:50, Rony G. Flatscher <rony.flatsc...@wu.ac.at> > wrote: > > Found another way to get it to install by issuing a: > > install(FILES ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/${linkName} COMPONENT > Core DESTINATION ${INSTALL_LIB_DIR}) > > Originally I tried to run "install(CODE...)" that would create the > symbolic links. Given that I had arrived at many, many variations I might > not have done that right and will try tomorrow. > > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
