#1421 Symbolic links to shared objects on Linux should carry the ooRexx 4.2.0 main versions

[Rony G. Flatscher]

The current beta of ooRexx 5.0.0 installed on Linux systems does not allow libraries to successfully link to librexx.so and librexxapi.so. The reason being that the symbolic links are missing for the major version 4 (librexx.so.4). ooRexx 4.2.0 has even more symbolic linkds to its shared objects with major version numbers 3 and 2.

Or with other words: please add also all symbolic links to librexx*.so that ooRexx 4.2.0 does.

[Rony G. Flatscher]

Yesterday, I noticed that the ooRexx 5.0 libraries (like librexxapi.so) get a link with a trailing "5.0.0" (like librexxapi.so.5.0.0) but no "5" (like librexxapi.so.5), no "4" (like librexxapi.so.4), no "3" (like librexxapi.so.3) and no "2" (like librexxapi.so.2), which seems to not be correct, because breaking existing programs that got linked with pre-5 versions of ooRexx.

So Cmake for Linux should create the symlinks to 4, 3 and 2 versions of all libraries to allow programs compiled to those versions of ooRexx to keep running. Otherwise at load time a missing file error will be raised and the program would not be started anymore.

---

This bug report does not carry the full information, so I copy the e-mail from 2017-01-26, 14:12 (oorexx developer list), which gives some more explanations:

Hi Michael,

On 26.01.2017 12:55, Michael Lueck wrote:

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?
No, I just wanted to wait first to see the point of views of Linux experts, short of having deep
Linux knowledge.

Maybe I should file a bug/RFE (also for the security manager issue).

---rony

[Alexander Adolf]

So what you want is:

librexx.so.5.0.0
librexx.so.5 -> librexx.so.5.0.0
librexx.so.4 -> librexx.so.5
librexx.so.3 -> librexx.so.5
librexx.so.2 -> librexx.so.5

Correct?

Similarly for the other libs, I presume?

[Rony G. Flatscher]

Hi Alexander,

it seems that from earlier installations the pattern was:

librexx.so -> librexx.so.5.0.0
librexx.so.5 -> librexx.so
librexx.so.4 -> librexx.so
librexx.so.3 -> librexx.so
librexx.so.2 -> librexx.so

Not sure why the Linux version I looked at (listed in the initial bug description above) would include the path into the symbolic link (not really knowing such Linux/MacOSX details).

Yes, it should also pertain to all the other libs.

Thank you very much for looking into this!

Best regards,

---rony

[Alexander Adolf]

(I'm typing this for the 3rd time over now; many thanks SF for the brand new web interface with no local storage at all...)

I have researched and experimented a bit, and it turns out this is non-trivial with cmake.

cmake uses the follwoing scheme to create symlinks under a generic name:

libfoo.so.version
libfoo.so -> libfoo.so.version

Search the cmake docs for NAMELINK_ONLY and NAMELINK_SKIP.

To get the symlinks you are lookimg for, we would need the inverse scheme, however.

To me, it would seem that creating such compatibility symilnks would best fit as a postinstall script for an installer package. There may be ways to get this with cpack, but with which I have zero experience.

I hence afraid that I will have to leave this to the cpack, and deb/rpm experts out there. Sorry for not havig better news!

[Rony G. Flatscher]

Thank you very much for looking into this! (Had hoped that a pure CMake solution would be possible.)

[Rony G. Flatscher]

The enclosed patch creates symbolic links on Unix systems. Tested with MacOS, Linux and Windows.

[Rony G. Flatscher]

The enclosed patch is basically the same as "patch-sym-links.txt" as of two days ago with the following changes:
to turn down verbosity a message() statement got commented and an unneeded comment got removed
the library and archive output directory got changed from "bin" to "lib" as per recommendation of Enrico Sorchetti
* the logic for naming the 64-bit rpm (Fedora) installation package got changed to correctly includ the string "x86_64" in its name; test follows the deb logic

The enclosed patch was successfully used in creating ooRexx for Windows, Linux and MacOSX r11661 today.

[Erich]

I assume this patch was committed with [r11670] Additional Mac changes plus addition of symbolic links.

The links created now look suspicious to me (see below ...so.nnn vs. ...n.so)

Would a 2.x native library be looking for /usr/lib/librexx.so.2 (or whatever the correct name was)?
Do we really need to provide for Rexx 2.x backwards compatibility?

-- Installing: /usr/lib/librexx.so.5.0.0
-- Up-to-date: /usr/lib/librexx.so
-- Up-to-date: /usr/lib/librexx.2.so
-- Up-to-date: /usr/lib/librexx.3.so
-- Up-to-date: /usr/lib/librexx.4.so

[Rick McGuire]

I don't think we should claim complete compatibility with anything before the first ooRexx release, which would have been 3.0.0. And I agree, those links look dodgy.

[Rony G. Flatscher]

Indeed, the non-Apple links need to have the version number after the so name. The enclosed patch adjusts the CMakeList.txt file accordingly and starts the symbol link generation with version 3, instead of 2.

Tested on Apple and Linux.

[Erich]

Committed patch wih revision [r11680]