1

In my project, I am trying to use two libraries those are already compiled and generated. Let us say liba.so(our own library created sometime back) and libssl.so.10.(It is available in the Linux).

Now liba.so is having dependency libcurl.so.3 & libssl.so.10 is having dependency libcurl.so.4 (latest)

Both libcurl.so.3 and libcurl.so.4 are available in the system.

Hence When I try to use both of them in my project, I am getting version conflict. Is it expected? If yes, how do I solve this problem?

Is there any way to modify liba.so dependency with latest libcurl.so.4 without building this library again? Or do I need to build liba.so again with latest libcurl.so.4?

Thanks for your help

Jegan
  • 188
  • 3
  • 15

1 Answers1

1

Hence When I try to use both of them in my project, I am getting version conflict. Is it expected? If yes, how do I solve this problem?

There are two solutions.

First, you would carry around the versions of libcurl.so & libssl.so you want to use. You would then use the linker's rpath or LD_LIBRARY_PATH to ensure you load the shared objects you included.

Second, you would build your liba.so to statically link against libcurl and libssl.

If you are working on Android, then number two is your choice. That's because OpenSSL is included on Android, zygote loads it, and you always get the downlevel version 0.9.8 after the fork from zygote.

On Android, you would even need to build a wrapper shared object if all you wanted was a modern OpenSSL like 1.0.1 (that looks a lot like what you are experiencing with libcurl.so.3 and libcurl.so.4).

jww
  • 97,681
  • 90
  • 411
  • 885
  • In the first solution, I have both libraries (libcurl.so.3 & libcurl.so.4) in the same directory. Hence if I specify the directory location in rpath or LD_LIBRARY_PATH, by default it would end up in conflict. So do you mean to say that I need to specify version explicitly? In second solution, can I statically link with old libcurl.so.3 with liba.so and use latest libcurl.so.4 dynamically with libssl.so.10 in my project? – Jegan Feb 26 '14 at 05:36
  • For your information, this is not Android. This is RedHat development server. – Jegan Feb 26 '14 at 05:51
  • libcurl.so.3 and libcurl.so.4 are probably not binary compatible (hence the reason for the version bump). You're going to need to compile everything against the same versions, or perform static linking to remove the issue with incompatible ABIs. If the dynamic linker loads libcurl.so.3 first, then the libcurl.so.4 dependent is going to suffer (and vice-versa). – jww Feb 26 '14 at 05:53