Set SONAME on created libraries

[incaseoftrouble]

After some debugging (I'm trying to load prism's libraries without messing with LD_LIBRARY_PATH through System.load), I noticed that prism's shared libraries are created without SONAME, which causes issues on linux.

To fix this problem, one would need to add -Wl,-soname,$(LIBPREFIX)dd$(LIBSUFFIX) to $(LDFLAGS) when building for linux. I'm currently hacking this issue by running patchelf.

I'm not an expert on anything C / C++ related, so this might be a bad idea, but as far as I understood, doing so is recommended.

[davexparker]

Hi @incaseoftrouble. Thanks for investigating. I know some people have had at least partial success with System.load over the years, although I've never found a solution that works reliably across all our platforms (especially Mac) without using (DY)LD_LIBRARY+PATH. In principle I have no problem with adding this to the Linux build process, if it doesn't break anything else. Two questions: How does Java find the directory containing the libraries? Via the classpath? And are additional System.load calls needed for this to work?

[incaseoftrouble]

Well, here's the problem, I have no idea how it works exactly. Even after patching with patchelf I managed to load all libraries but prism then later on still failed with an unsatisfied link error (or maybe I did something wrong). Neither do I know whether this would break anything, unfortunately. Maybe some other contributor knows more about these things?

[davexparker]

Something to do with shared libraries depending on each other? The reason for my second question was that I found this, which (I think) worked for someone else previously: davexparker@5280e78.

[incaseoftrouble]

Yes, let me try to explain what I think I understood:

If loading via System.loadLibrary, the .so files need to be on LD_LIBRARY_PATH (java.library.path seems to not be sufficient if the .so files depend on others)

Loading via System.load works if done in the correct order if the libraries have SONAME set. Basically, as I understand it, I e.g. load libdd.so (which works) but loading libodd.so fails because it can't find libdd.so - in this case the lookup is not done based on the loaded library file name but on its SONAME. So the libdd I loaded previously is sort of stored as an "unnamed" library and loading libodd.so fails because there is no library loaded with name libdd.so.

So I added the SONAME via the patch, but prism loads via System.loadLibrary which somehow didn't work for reasons I don't understand. At this point I gave up and customized my startup script to set LD_LIBRARY_PATH (I'm using prism as a library, so I cannot directly use prism's scripts).

I just openend this issue, since I think it might be the "proper" way to do it (lpsolve for example has SONAME set).

[lituzou]

I think this is the issue of shared library dependencies. Usually when a shared library is built, you are expected to move these shared libraries to designated system library folders like /usr/local/lib. Whenever a library or executable wish to run a dependent library, it only search from these library. However, PRISM is designed to be portable, these shared libraries cannot find each other even though they reside in the same folder.

This is usually solved by assigning rpath (library runpath) in the linking step, which provides extra search path for these libraries to search for their dependencies. In Linux, we can assign $ORIGIN to rpath to tell the library to search the directory of the current library or executable. In GCC, this is done by adding linker argument -Wl,-rpath,'$ORIGIN' during compilation.

Take liblpsolve55j.so as an example, if we run without assigning rpath, here is the result:

~/prism-4.9-src/prism$ readelf -d lib/liblpsolve55j.so | head -20

Dynamic section at offset 0x1fcf0 contains 28 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [liblpsolve55.so]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-aarch64.so.1]
 0x000000000000000e (SONAME)             Library soname: [liblpsolve55j.so]
 0x000000000000000c (INIT)               0x9268
 0x000000000000000d (FINI)               0x13e04
 0x0000000000000019 (INIT_ARRAY)         0x2fce0
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x2fce8
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x1f0
 0x0000000000000005 (STRTAB)             0x3e28
 0x0000000000000006 (SYMTAB)             0xbd0
 0x000000000000000a (STRSZ)              13089 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x2ffe8

~/prism-4.9-src/prism$ ldd lib/liblpsolve55j.so
	linux-vdso.so.1 (0x0000ffffbe24c000)
	liblpsolve55.so => not found
	libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000ffffbdf40000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffffbdd80000)
	/lib/ld-linux-aarch64.so.1 (0x0000ffffbe210000)
	libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffffbdcd0000)
	libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000ffffbdc90000)

You can see the library does not know where liblpsolve55.so is.
However, by adding rpath argument $c $CFLAGS -shared -Wl,-soname,liblpsolve55j.so -o $PLATFORM/liblpsolve55j.so lpsolve5j.o -L$LPSOLVE_LIB_DIR -lc -llpsolve55 -Wl,-rpath,'$ORIGIN' in the build script, we get

~/prism-4.9-src/prism$ readelf -d lib/liblpsolve55j.so | head -20

Dynamic section at offset 0x1fce0 contains 29 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [liblpsolve55.so]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-aarch64.so.1]
 0x000000000000000e (SONAME)             Library soname: [liblpsolve55j.so]
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN]
 0x000000000000000c (INIT)               0x9270
 0x000000000000000d (FINI)               0x13e14
 0x0000000000000019 (INIT_ARRAY)         0x2fcd0
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x2fcd8
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x1f0
 0x0000000000000005 (STRTAB)             0x3e28
 0x0000000000000006 (SYMTAB)             0xbd0
 0x000000000000000a (STRSZ)              13097 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)

~/prism-4.9-src/prism$ ldd lib/liblpsolve55j.so
	linux-vdso.so.1 (0x0000ffffb284c000)
	liblpsolve55.so => /home/user/prism-4.9-src/prism/lib/liblpsolve55.so (0x0000ffffb2710000)
	libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000ffffb2480000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffffb22c0000)
	/lib/ld-linux-aarch64.so.1 (0x0000ffffb2810000)
	libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffffb2210000)
	libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000ffffb21d0000)

You can see the library can now locateliblpsolve55.so.

In MacOS, $ORIGIN is replaced by @loader_path.
In Windows, there is no analogous one.

I hope this clarifies. If you need me to implement changes to all applicable build scripts, I am happy to do so.

[davexparker]

Thanks @lituzou! This is now done in #272, which I will hopefully merge shortly.