Greetings Rony, Historically this area has been a sharp spot for Object Rexx / Open Object Rexx on Linux. Back in the v3 time period, I was having difficulty running a Rexx library compiled against the old Object Rexx v2 IBM released. I contributed a patch so that the same old library would load on newer versions of ooRexx.
With ooRexx v4.2 on my system, I have: mdlueck@jacob:/usr/lib$ ls -al | grep librx -rw-r--r-- 1 root root 26726 Dec 29 2013 librxmath.a -rw-r--r-- 1 root root 962 Dec 29 2013 librxmath.la lrwxrwxrwx 1 root root 18 Dec 29 2013 librxmath.so -> librxmath.so.4.0.6 lrwxrwxrwx 1 root root 21 Feb 24 2014 librxmath.so.4 -> /usr/lib/librxmath.so -rw-r--r-- 1 root root 23408 Dec 29 2013 librxmath.so.4.0.6 -rw-r--r-- 1 root root 23088 Dec 29 2013 librxregexp.a -rw-r--r-- 1 root root 976 Dec 29 2013 librxregexp.la lrwxrwxrwx 1 root root 20 Dec 29 2013 librxregexp.so -> librxregexp.so.4.0.6 lrwxrwxrwx 1 root root 23 Feb 24 2014 librxregexp.so.2 -> /usr/lib/librxregexp.so lrwxrwxrwx 1 root root 23 Feb 24 2014 librxregexp.so.3 -> /usr/lib/librxregexp.so lrwxrwxrwx 1 root root 23 Feb 24 2014 librxregexp.so.4 -> /usr/lib/librxregexp.so -rw-r--r-- 1 root root 19024 Dec 29 2013 librxregexp.so.4.0.6 -rw-r--r-- 1 root root 56192 Dec 29 2013 librxsock.a -rw-r--r-- 1 root root 962 Dec 29 2013 librxsock.la lrwxrwxrwx 1 root root 18 Dec 29 2013 librxsock.so -> librxsock.so.4.0.6 lrwxrwxrwx 1 root root 21 Feb 24 2014 librxsock.so.2 -> /usr/lib/librxsock.so lrwxrwxrwx 1 root root 21 Feb 24 2014 librxsock.so.3 -> /usr/lib/librxsock.so lrwxrwxrwx 1 root root 21 Feb 24 2014 librxsock.so.4 -> /usr/lib/librxsock.so -rw-r--r-- 1 root root 40704 Dec 29 2013 librxsock.so.4.0.6 -rw-r--r-- 1 root root 48066 Dec 29 2013 librxunixsys.a -rw-r--r-- 1 root root 983 Dec 29 2013 librxunixsys.la lrwxrwxrwx 1 root root 21 Dec 29 2013 librxunixsys.so -> librxunixsys.so.4.0.6 lrwxrwxrwx 1 root root 24 Feb 24 2014 librxunixsys.so.4 -> /usr/lib/librxunixsys.so -rw-r--r-- 1 root root 45664 Dec 29 2013 librxunixsys.so.4.0.6 lrwxrwxrwx 1 root root 21 Feb 24 2014 libxmath.so.2 -> /usr/lib/librxmath.so lrwxrwxrwx 1 root root 21 Feb 24 2014 libxmath.so.3 -> /usr/lib/librxmath.so mdlueck@jacob:/usr/lib$ ls -al | grep librexx -rw-r--r-- 1 root root 4649516 Dec 29 2013 librexx.a -rw-r--r-- 1 root root 212328 Dec 29 2013 librexxapi.a -rw-r--r-- 1 root root 969 Dec 29 2013 librexxapi.la lrwxrwxrwx 1 root root 19 Dec 29 2013 librexxapi.so -> librexxapi.so.4.0.6 lrwxrwxrwx 1 root root 22 Feb 24 2014 librexxapi.so.2 -> /usr/lib/librexxapi.so lrwxrwxrwx 1 root root 22 Feb 24 2014 librexxapi.so.3 -> /usr/lib/librexxapi.so lrwxrwxrwx 1 root root 22 Feb 24 2014 librexxapi.so.4 -> /usr/lib/librexxapi.so -rw-r--r-- 1 root root 102296 Dec 29 2013 librexxapi.so.4.0.6 -rw-r--r-- 1 root root 948 Dec 29 2013 librexx.la lrwxrwxrwx 1 root root 16 Dec 29 2013 librexx.so -> librexx.so.4.0.6 lrwxrwxrwx 1 root root 19 Feb 24 2014 librexx.so.2 -> /usr/lib/librexx.so lrwxrwxrwx 1 root root 19 Feb 24 2014 librexx.so.3 -> /usr/lib/librexx.so lrwxrwxrwx 1 root root 19 Feb 24 2014 librexx.so.4 -> /usr/lib/librexx.so -rw-r--r-- 1 root root 1657784 Dec 29 2013 librexx.so.4.0.6 -rw-r--r-- 1 root root 82650 Dec 29 2013 librexxutil.a -rw-r--r-- 1 root root 976 Dec 29 2013 librexxutil.la lrwxrwxrwx 1 root root 20 Dec 29 2013 librexxutil.so -> librexxutil.so.4.0.6 lrwxrwxrwx 1 root root 23 Feb 24 2014 librexxutil.so.2 -> /usr/lib/librexxutil.so lrwxrwxrwx 1 root root 23 Feb 24 2014 librexxutil.so.3 -> /usr/lib/librexxutil.so lrwxrwxrwx 1 root root 23 Feb 24 2014 librexxutil.so.4 -> /usr/lib/librexxutil.so -rw-r--r-- 1 root root 66576 Dec 29 2013 librexxutil.so.4.0.6 So yes I see the symlinks to symlinks. Ex: ibrexxapi.so.2 -> /usr/lib/librexxapi.so + librexxapi.so -> librexxapi.so.4.0.6 I believe that was the needed one to get the library to load in my case. Rony G. Flatscher wrote: > The current ooRexx 5.0.0 beta only creates a "/usr/lib/librexx.so.5". That would be a problem indeed! We need to maintain the links for backward compatibility. Good find, Rony. Has a defect been logged yet? I am thankful, -- Michael Lueck Lueck Data Systems http://www.lueckdatasystems.com/ Rony G. Flatscher wrote: > After a little bit of research, I think I found a solution to my problem. > However, there is a general problem to be discussed with respect to > versioning of librexx.so* and its companions > librexxapi.so* and librexxutil.so*. > > ooRexx 4.2.0 creates versioned shared objects (so) on Linux for "librexx.so", > "librexxapi.so" and "librexxutil.so". E.g. for "librexx.so": > > * librexx.so.4.0.6 (the actual shared object) > * librexx.la (interesting information about the shared object) > * /usr/lib/librexx.so -> librexx.so.4.0.6 (link) > * /usr/lib/librexx.so.2 -> /usr/lib/librexx.so (link) > * /usr/lib/librexx.so.3 -> /usr/lib/librexx.so (link) > * /usr/lib/librexx.so.4 -> /usr/lib/librexx.so (link) > > Actually, the numbering scheme of the links is wrong: the first number should > only increas, if the API got changed such, that it became incompatible with > older versions. If the new version of a > library still includes the old APIs (but adds new APIs), then the first > number should remain unchanged. > > The current ooRexx 5.0.0 beta only creates a "/usr/lib/librexx.so.5". This > has the effect, that when running a program that was linked with older > versions of ooRexx (like 4.2.0) the appropriate > librexx.so.4 cannot be found, such that the program needs to be linked to > ooRexx 5.0.0. This problem can be solved, if ooRexx 5.0.0 would also create > at least a link for /usr/lib/librexx.so.4 (but > could probably also create /usr/lib/librexx.so.2 and /usr/lib/librexx.so3). > > Helpful information on so-version numbers can be found e.g. at > <http://stackoverflow.com/questions/12637841/what-is-the-soname-option-for-building-shared-libraries-for>. > > ---rony > > > On 23.01.2017 15:48, Rony G. Flatscher wrote: >> >> While working on a new version of BSF4ooRexx library there is a need to link >> against ooRexx 4.2 and ooRexx 5.0 beta. >> >> On Linux and MacOSX I have been linking *without* any version numbers, i.e. >> with the flags >> >> Linux (g++): -lrexx -lrexxapi -lrexxutil >> >> MacOSX (gcc-alias for Clang): $(ORX_LIBPATH)/librexx.dylib >> $(ORX_LIBPATH)/librexxapi.dylib >> >> Linking against ooRexx 4.2 libraries will cause e.g. >> >> * Linux: >> o librexx.so.4 to be stored in the produced libBSF4ooRexx.so (using >> ldd), which cannot be found by the linker, if ooRexx 5.0.0beta ist installed >> >> * MacOSX (interestingly the linker uses a now prohibited path on MacOSX >> instead of /usr/local/lib): >> o /usr/lib/ooRexx/librexx.4.dylibto be stored in the produced >> libBSF4ooRexx.dylib (using otool -L), which cannot be found by the linker, >> if ooRexx 5.0.0beta is installed >> o the other way around the link: @rpath/librexx.5.0.0.dylib gets >> stored, which cannot be found by the linker, if ooRexx 4.2.0 is installed >> >> My question probably is: how would one have to link to librexx.{so|dylib}, >> librexxapi.{so|dylib} such that only a single libBSF4ooRexx.{so|dylib} needs >> to be created? >> >> Currently, the ooRexx APIs being used by libBSF4ooRexx.so are present in >> both versions of ooRexx. >> >> ---rony ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
