Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

libraries and versions

2008-09-17
2013-04-18
  • I have installed amd64 linux version 1.7. However, in order to get the programs (such as pregap4) to run I had to fiddle with libraries. The precompiled staden version needs libcurl.so.3, libssl.so.0.9.7, and libcrypto.so.0.9.7 while I have newer versions of these libraries.

    I did what should not be done (in /usr/lib64):

    ln -s libcurl.so libcurl.so.3
    ln -s libssl.so libssl.so.0.9.7
    ln -s libcrypto.so libcrypto.so.0.9.7

    These links may well break down later. Given that these dynamic links are there, would it be possible to actually use libcurl.so etc, instead of specific version?

    Thanks
    /Torsten Eriksson

     
    • Again: it turns out to be a much bigger problem. Since I had a newer version of gcc than the one apparenly used for compiling, the library libg2c.so.0 was missing. A kludge fixed that after installing GCC 3.4, but the precompiled binaries craved libstdc++.so.5 (and I had libstdc++.so.6).

      When the kludge that fixed that last probelm didn't work out. I kind of gave up (output below).

      It seems that I will need to compile a version from scratch. Something which I have already horribly failed...

      /T

      load libhaplo.so => couldn't load file "libhaplo.so": /usr/lib64/libstdc++.so.5: version `CXXABI_1.2' not found (required by /usr/local/src/staden-linux-x86_64-1-7-1b/linux-x86_64-bin/../lib/linux-x86_64-binaries/libmutlib.so)
      load libgap.so => couldn't load file "libgap.so": /usr/lib64/libstdc++.so.5: version `CXXABI_1.2' not found (required by /usr/local/src/staden-linux-x86_64-1-7-1b/linux-x86_64-bin/../lib/linux-x86_64-binaries/libmutlib.so)
      invalid command name "load_alignment_matrix"
          while executing
      "load_alignment_matrix       [keylget gap_defs ALIGNMENT.MATRIX_FILE]"
          (file "/usr/local/src/staden-linux-x86_64-1-7-1b/linux-x86_64-bin/../lib/gap/gap.tcl" line 683)

       
    • James Bonfield
      James Bonfield
      2009-01-07

      Library versions is rapidly turning into hell in linux distributions. Why for example when I just use Ansi C should I care about some internal GNU minor change between glibc 2.1.3 and 2.1.4 (for example), yet the code automatically ends up with version specific dependencies.

      The worst offender for this is libcurl, which is optionally used in io_lib - part of the trace reading code to allow fetching of trace files from remote services rather than just local files on disk. The "curl-config --libs" command is meant to tell me which libraries I need to link against when using libcurl. However  it gives me radically inappropriate results leading to binaries tied to the platform I built them on. Eg:

      debian-3.0:~> curl-config --libs
      -L/usr/lib -lcurl -lidn -lssl -lcrypto -ldl -lssl -lcrypto -ldl -lz

      debian-4.0:~> curl-config --libs
      -L/usr/lib -lcurl -L/usr/lib -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lkrb5support -lresolv -lidn -lssl -lcrypto -ldl -lssl -lcrypto -lz

      Actually all I need is "-lcurl" and it just works as libcurl.so itself has the chain of dependencies in it rather than explicitly passing these dependencies up to the application linking against curl.  Similar things happen elsewhere too. Hardly suprisingly this makes supporting binary built distributions problematic unless we just statically link everything.

      What I really need to do, but never seem to find the time for, is to break the package into smaller components that are easier to build. Not necessarily full auto-conf world (as I hate libtool with a passion, but I need dynamic linking still), but something easier to build. Right now it's a bit of a nightmare - sorry!