HI Martijn,
On 06.07.2012 21:36, Martijn van Exel wrote:
Even after compiling and installing zlib 1.2.7 from source, the
default 'one-click' install for osmconvert did not work, but after
explicitly pointing to /usr/local/lib with the -L option, it did.
Thanks for your patient responses.
you're welcome :)
Apparently I have an older version of zlib hanging around in /usr/lib.
Is this something I should be worried about in general?
Well, I'm not sure myself. Let's talk about what's involved step by
step. For this 'one-click' promise to be fulfilled, there are a lot of
search paths involved:
1. The include search paths which is where the C preprocessor (cpp)
looks for "zlib.h" if you say #include <zlib.h> in your code.
2. The library files search path where the linker (ld) looks for shared
(libz.so or something like this) or static (libz.a) libraries _during
linking_.
3. If you use shared libraries, the runtime search path where the linker
runtime (ld.so) looks for the libraries to load when you run the
compiled program.
<rant>
All of this is controlled by linker and preprocessor options,
environment variables, configuration files, symlink networks and by
interaction between all of the above. It also differs by platform, by
architecture, by distribution and most probably by distribution version.
And of course, you have the classic problem of library versioning, also
known as "DLL hell" (despite the name, the hell is very much
cross-platform - call it SO hell on Linux if you like :)). In short, it
is a total flying circus.
This is why you almost never see 'one-click' programs - most commonly
you see the 'two-click' version, something like "configure && make". The
"configure" step is there (among other things) to figure out those
search paths (1) and (2) for your system and complain more or less
comprehensibly if it cannot so you don't get cryptic gcc error messages
like you got them. The paths to the libraries are then passed to gcc
explicitly with -I (headers) or -L (libraries).
</rant>
Normally, (2) and (3) should be more or less in sync. Also, by
convention, /usr/local/lib should take precedence over /usr/lib. For
some reason, this is not the case on your system:
1. /usr/local/include has taken precedence over /usr/include so you got
the 1.2.7 headers with gzbuffer defined.
2. /usr/local/lib did _not_ take precedence over /usr/lib while linking
so you got the linker error and had to set it by hand.
3. /usr/local/lib _did_ take precedence over /usr/lib when you ran the
program because you got it running without manually setting
LD_LIBRARY_PATH or something like that. If it was like in (2), the
compiled convert would crash horribly because it got the right zlib
version during linkage but not during runtime.
This is the only thing I would worry about because it is somewhat
counter-intuitive and could also mess up other software that relies on
shared libraries - this is not osmconvert-specific. Sadly, I have no
idea what could cause this or how to fix it or what is actually wrong.
I'm just replaying the compilation stages and your error description in
my head :) Maybe this is even somehow correct by some bizarre logic
(remember, it's a flying circus :)).
Bye
Igor
_______________________________________________
osmosis-dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/osmosis-dev
