smart link ? better use of make ? ...stupid programmer ? - Unix

This is a discussion on smart link ? better use of make ? ...stupid programmer ? - Unix ; C code gcc 3.4.6 / 3.3.5 SuSE 9.3, RHAS4 I'm starting to get into a situation where shared libraries either don't exist on a target platform, or if they exist their version number can vary by platform. (For example, the ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: smart link ? better use of make ? ...stupid programmer ?

  1. smart link ? better use of make ? ...stupid programmer ?

    C code
    gcc 3.4.6 / 3.3.5
    SuSE 9.3, RHAS4

    I'm starting to get into a situation where shared libraries either
    don't exist on a target platform, or if they exist their version
    number can vary by platform. (For example, the default libpcap in
    SuSE 9.3 is 0.8.1, and on RHAS4 it's 0.8.3.)

    I recently got caught, for example, when I tried to run a set of
    images, built on RHAS4, on SuSE 9.3 -- and it didn't find libpcap
    0.8.3.

    Duh.

    For shared object files that simply don't exist on a given platform,
    what I've been doing is editing the code to remove references that
    would be resolved in unavailable shared objects, and building images
    on that platform, and maintaining separate image sets. I don't see
    that I've got much choice about that; I can nest conditionally-
    included code in an #ifdef block, and pass the necessary define on
    the 'make' command line. (If there's a more elegant way to do that,
    I'd love to know it exists.)

    But for library versions, I need to learn if there's a smarter way to
    handle this than explicitly building of a set of images on each of
    the platforms. I'm guessing that this would be done in the Makefile
    somewhere, but if I could get a hint about what capabilities exist I
    can then focus on learning more about the tools. Just would like to
    minimize the time I might spend barking up the wrong tree.

    Any guidance or references greatly appreciated. If I'm basically
    doing it the way it has to be done, I'd appreciate knowing that as
    well.

  2. Re: smart link ? better use of make ? ...stupid programmer ?

    Richard Eich wrote:
    ....
    > Any guidance or references greatly appreciated. If I'm basically
    > doing it the way it has to be done, I'd appreciate knowing that as
    > well.


    As soon as there is an incompatability like you describe, I place the
    library source code in my build tree and comple it in statically. The
    technique I use usually means that when the library source is updated, I
    simply update the version number in my source tree and it fetches,
    uncompresses and builds the libraries. I can then build "precompiled"
    versions on these files and place then in the source tree as well.

    If you want to see how it's done, download the Austria C++ alpha:

    http://netcabletv.org/public_releases/

    It contains precompiled binaries for openssl, zlib, libxml2 etc.

    You can choose to link statically or dynamically (but that means you
    need to distribute the shared libraries as well) what you choose to do
    depends on what you are doing it for.

  3. Re: smart link ? better use of make ? ...stupid programmer ?

    Gianni Mariani writes:

    > Richard Eich wrote:
    > ...
    >> Any guidance or references greatly appreciated. If I'm basically
    >> doing it the way it has to be done, I'd appreciate knowing that as
    >> well.

    >
    > As soon as there is an incompatability like you describe, I place the
    > library source code in my build tree and comple it in statically.


    You can only do that if your code is distributed under a license
    compatible with that of the libraries you statically link in.

    An alternative is to link dynamically on the oldest platform you
    wish to support. In the OP case, linking on SuSE and running on
    RHEL would have probably worked.

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  4. Re: smart link ? better use of make ? ...stupid programmer ?

    Paul Pluzhnikov wrote:
    > An alternative is to link dynamically on the oldest platform you
    > wish to support. In the OP case, linking on SuSE and running on
    > RHEL would have probably worked.


    In the general case, you can build your own copy of the library
    (at whatever version is the oldest) and build-time-link against
    that, then *run* (and run-time-link) against whatever is actually
    installed.

    This could be useful if, for example, platform A has libfoo-1.0
    and libbar-1.5 and platform B has libfoo-2.0 and libbar-1.0.
    Then there is no one platform that has the lowest versions of
    all the libraries.

    Having your own copies of all the libraries would also allow
    you to build on whatever platform is convenient (rather than
    having login to the oldest, slowest machine around), and it
    insulates you from issues with maintaining an old machine.
    But it's also more of a pain in the butt.

    - Logan

  5. Re: smart link ? better use of make ? ...stupid programmer ?

    Logan Shaw writes:

    > Having your own copies of all the libraries would also allow
    > you to build on whatever platform is convenient (rather than
    > having login to the oldest, slowest machine around), and it
    > insulates you from issues with maintaining an old machine.


    This does not work well on Linux (though it could be done):
    it is rather tricky to link against non-default glibc (because it
    has dependencies on /lib/ld-linux.so.2, and by definition there
    can only be one of these), and if you use default glibc, then your
    executable is quite unlikely to run on older glibc versions.

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

+ Reply to Thread