Dear Rony, I have just reinstalled a Mac with a completely clean Mojave Setup (to avoid old file ownerships etc to linger on etc) and am attacking exactly this question. If you can bear with me a couple of days I will report what I have found out. With the latest changes & the daemon-free installation things have gotten much less complex. But I need some time to be completely sure on what I have in mind, ok?
Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 01.01.2019 um 21:39 schrieb Rony G. Flatscher <rony.flatsc...@wu.ac.at>: > > Currently on Unix there are "lib*.5.0.0.dylib" (Apple) or "lib*.so.5.0.0" > (Linux) shared libraries created where "*" stands for "hostemu", > "orxncurses", "rexx", "rexxapi", "rexxutil", "rxmath", "rxregexp", "rxsock", > "rxunixsys". > In addition there are symbolic links created in the form of "lib*.dylib" or > "lib*.so" pointing to the "5.0.0" shared libraries. An example with "hostemu" > shared libraries would be: > > Apple: libhostemu.dylib -> libhostemu.5.0.0.dylib > Linux: libhostemu.so -> libhostemu.so.5.0.0 > If running executables that got linked to earlier versions of ooRexx (e.g. > ooRexx 2, ooRexx 3 or ooRexx 4) then such executables would not be able to > run, unless there are also symbolic links created that carry the version > information "2", "3" or "4", like: > > Apple: libhostemu2.dylib -> libhostemu.so > libhostemu3.dylib -> libhostemu.so > libhostemu4.dylib -> libhostemu.so > > Linux: libhostemu2.so -> libhostemu.so > libhostemu3.so -> libhostemu.so > libhostemu4.so -> libhostemu.so > <https://sourceforge.net/p/oorexx/bugs/1421/> > <https://sourceforge.net/p/oorexx/bugs/1421/> points at this situation. > > --- > > Now, as everyone is quite busy with different tasks I tried to start to > figure out how to change the CMakeList file such that it would create these > symbolic links and install them. Not having knowledge about CMake this has > turned out to be a very time consuming task, where information is missing > that would allow me to conclude the experiment. > > After many hours, I have become able to create the symbolic links in the > ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}, but have not been able to get these newly > added files to copy to the lib-directory at install time ("make install" or > while creating the rpm or deb packages where the shared libraries need to get > copied to the packager's temporary subdirectories). > So any help or advice would be appreciated that would allow me to proceed, > such that in the end I could supply a patch for the project that creates > these symbolic links! > > --- > Here a few questions: > > why are the shared libraries created in the BINARY_DIR as in line # as > set (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/bin) > on Apple there is an individual change to that value, such that a "lib" > directory gets used to place the shared libraries to > > how would one cause all shared files in ${CMAKE_LIBRARY_OUTPUT_DIRECTORY} to > be copied at installation time ("make install") to the installation's target > library directory? > Tried it to no avail with (at build time INSTALL_LIB_DIR points to the > standard installation location like "/usr/lib"): > install(CODE "execute_process(COMMAND ${CMAKE_COMMAND} -E chdir > ${INSTALL_LIB_DIR} create_symlink ${targetName} ${linkName})") > hence looking for alternatives. > is there a means to inform CMake which library files need to be taken from > the CMAKE_LIBRARY_OUTPUT_DIRECTORY and be put into the appropriate library > directory while installing (and uninstalling)? > ---rony > > > _______________________________________________ > 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
