[DebianGIS-dev] Bug#579989: Bug#579989: Bug#579989: Bug#579989: Tries to dlopen libproj.so instead of libproj.so.0

[Francesco P. Lovergine]

On Wed, May 19, 2010 at 11:54:50AM +0200, Jens Thiele wrote:
> > Ok, thanks. Solved in the 1.7.2 branch on svn, due in a few for
> > experimental. The reason for skipping by default a usual shlib
> > linking is quite obscure to me, but that can be better managed
> > by configure. I suspect that is done to avoid depending strictly
> > on a specific SONAME, because proj4 API is frozen since ages, but
> > anyway that's not the way things are done on Debian.
> 
> a) Your solution is IMHO fine (though the upstream naming of the
> configure option is misleading, because afaiu libproj is linked
> dynamically now and not statically).
> 

Agree.

> 
> b) just as additional comment:
> 
> Using dlopen basically allows to move a dependency from build-time to
> run-time. The application can provide features depending on wether a
> certain library is available at run-time or not. There are certain use
> cases where this is required:
> 
> Typically interpreter language modules are implemented like that (you
> can't build all possible combinations of perl/python/... + modules). Or
> "more general" application plugins are done like that. One also can use
> dlopen to update a running application (though this has its own problems
> and I don't know a real-world example for that one at the moment)
> 

The whole thing has a limited sense in the Debian environment, where
the whole toolchain is anyway conventionally linked to many other
libraries. Using this kind of approach would be nice if all drivers
were provided by a (versioned) plugin mechanism, which is not.
Honestly, I see no reason to use that approach for proj and 
nothing else.


-- 
Francesco P. Lovergine