4

I produce a dynamic library (libfoo.so) requires libcrypto.so. Which works fine in the build platform (I build it in Ubuntu 16.04). However when I move the same library to Debian Stretch 9.3, it start to complaining missing libcrypto.so.1.0.0. The openssl package is install in Debian Stretch, but the libcrypto.so is named as libcrypto.so.1.0.2. After a bit of digging, I found out that although the libcrypto.so on Ubuntu 16.04 is named as libcrypto.so.1.0.0 (its SONAME also libcrypto.so.1.0.0), it is actually version 1.0.2.

Here is the question: I do not want to recompiled a special version for Debian, is there anyway that my library can be use on both Linux distributions? Either link with both .so version at the same time, or other methods?

Forgot to mention that, I used gcc compiler, my library is written in C.

cityzz
  • 301
  • 2
  • 12
  • What librcrypto do you link? Try libcrypto.so.1, which should point to libcrypto 1.0.2 or 1.0.0, depending on system. (However: it is still sane to rebuild for each linux distribution). – dbrank0 Mar 12 '18 at 14:21
  • The simplest thing to do is to ship libcrypto with your software (put it alongside your executable in the same directory) – mnistic Mar 12 '18 at 14:22
  • @dbrank0, Thank you, I will give it a go. Normally I just do gcc -lcrypto, and it will find libcrypto.so which is a symlink to libcrypto.so.1.0.0 in my case. (Or to libcrypto.so.1.0.2 in Debian) – cityzz Mar 12 '18 at 14:43
  • @mnistic I thought of that before, but it sounds a little bit silly in my case, because the function I use in libcrypto.so is not closely linked to a specific version, in theory, it could work with any libcrypto.so. I just need to find a good way of solving (seems to me) the linking issue. – cityzz Mar 12 '18 at 14:47

2 Answers2

2

In my opinion(Although I haven't done this before)... if your not too worried about the size of your shared object libfoo.so, ... I think your best bet here is going to be to statically link libcrypto.a ( the static version of libcrypto for the version you choose)

Although I suspect you might run into other c libraries not playing well between the different distributions ( Debian and Ubuntu ) ... even if you were to get it to work maintance would be a nightmare

(Stuff below might be irrelevant if you are loading your .so object at runtime into a program compiled on the other machine)

Even if you were to fully statically link the binary... It probably wont work

https://unix.stackexchange.com/questions/227910/will-my-linux-binary-work-on-all-distros

For anything that is more complex than a statically linked hello world, the answer is probably no. Without testing it on distribution X, assume the answer is no for X.

Hedge7707
  • 557
  • 1
  • 5
  • 17
  • Thank you, I think currently it might be the only possible option to deal with this problem without recompiling for each supported distro. – cityzz Mar 12 '18 at 16:10
  • 1
    @cityzz I *have* done this before - and when dealing with OpenSSL, portability across Linux distributions pretty much requires statically linking `libcrypto` and `libssl`. There have been significant API changes in OpenSSL in the last few years and there's no guarantee you'll get a working matchon any distribution. – Andrew Henle Mar 12 '18 at 17:54
  • @AndrewHenle Thank you for your advice, it is also my thought and solution to be. – cityzz Mar 13 '18 at 08:00
1

I found a hacky way might solve this problem.

I make a local copy of libcrypto.so.1.0.0 and use patchelf to change its SONAME

patchelf --set-soname libcrypto.so libcrypto.so.1.0.0

Then build my library and link to that local copy instead of system library, it will shown as NEEDED libcrypto.so instead of previously NEEDED libcrypto.so.1.0.0, and it is able to work on both Debian and Ubuntu.

But for other distro, user might need to make sure that libcrypto.so is exists, or they have to create a symlink to the libcrypto.so.1.x.x

cityzz
  • 301
  • 2
  • 12
  • Does it just compile or can you use functions without getting a segfault? – Hedge7707 Mar 12 '18 at 17:01
  • 1
    @Hedge7707 I can use my function correctly without segfault, it might be a special case, because after all, the libcrypto.so.1.0.0 on ubuntu is similar version to libcrypto.so.1.0.2 (one is version 1.0.2h and the other is 1.0.2l). And also I am only use very simple functions in the library, nothing specific to the version 1.0.2. – cityzz Mar 12 '18 at 17:05
  • @Hedge7707 I wrote the answer here is just to provide another thought, and it might not be suitable for production code. I think your answer is better in that sense. – cityzz Mar 12 '18 at 17:09
  • Haha naww your answer is neat! I was just curious because I thought that there could be a conflict between libc and other libraries that are dynamically linked to make libcrypto.so ... but I guess not – Hedge7707 Mar 12 '18 at 17:14
  • *I found a hacky way might solve this problem.* You really don't want to do this. It's not hard to link `libcrypto` statically. It's really hard to recover from a "this product is crap" perception, because even if *it is able to work on both Debian and Ubuntu* **installations that you have access to today**, it won't necessarily work on someone else's installation next year. – Andrew Henle Mar 12 '18 at 18:27
  • @AndrewHenle Agree, totally. – cityzz Mar 13 '18 at 08:01