[osmosis-dev] Problem with PBF reader

[Igor Podolskiy]

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