A small remark: Erich has found out that the dyld stuff will not work since it is not inherited. A rexx program calling another rexx program (example: test cases) fail. He can put it in more technical terms I am sure, but my take on it is that this is a dead end on Darwin/macOS
Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 02.01.2019 um 22:29 schrieb Rick McGuire <object.r...@gmail.com>: > > > > On Wed, Jan 2, 2019 at 4:15 PM René Jansen <rvjan...@xs4all.nl > <mailto: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 > <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 >> <mailto: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 <mailto:Oorexx-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > <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
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
