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.

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

Gianni Mariani <gi3nospam@mariani.ws> writes:

> Richard Eich wrote:
> ... 
>
> 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.

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

Logan Shaw <lshaw-usenet@austin.rr.com> 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.

[ Post a follow-up to this message ]