[Fwd: Re: [Mapserver-dev] configure script problems with multiple GD]

[Daniel Morissette]

Daniel Morissette wrote:
> 
> As there is no clever way to ask the runtime linker to
> bind to the right library, the mapserver interface
> should be at least stable to not to crash even in that
> case.
> 

I think you're confusing the runtime linker and the compile-time linker. 
At least on Linux, the runtime linker always uses the version of the lib 
that was specified at compile/link time. This is done through the 
versioning information in the libgd.so.x.y.z. That's not the problem. 
The problem is the presence of multiple sets of headers and multiple 
libgd.so. Keep only one and you're all set.

>> Users are only required to remove the -devel part of
>> the library in the system dirs. It is possible to keep several runtime
>> copies of GD on the system (i.e. several libgd.so.x.y.z) for existing
>> programs to continue to run. 
> 
> 
> Yes, but you cannot assume that the user is using a
> specific operating system and you cannot assume that
> the mapserver is linked to the library with the
> according header files.
> 

Uh? "you cannot assume that the mapserver is linked to the library with 
the according header files."? If we cannot assume that the library that 
we link with matches the header files then how can we hope to compile 
any program in a predictable way?


>> The problems happen only when you have
>> multiple copies of the header files and of libgd.so (e.g. the gd-devel
>> RPM).
> 
> 
> With sunfreeware for example the header- and the
> library files are not always in a separate package.
> 

I'm not familiar with sunfreeware packages, but I think that it's their 
mistake if they didn't think that it would be smart to separate headers 
and runtime libs. Unfortunately that means that sunfreeware users would 
have to manually remove the duplicate copies of the header files and 
libgd.so and keep only one set.

> 
> The other point is that with the current configuration
> of autoconf, all the library paths are given on the
> command line of gcc. Imagine the following:
> The library libxyz has the prefix /usr/here. This is
> also the prefix of some old libgd's. Even when the
> user gives --with-gd=/usr/there the compiler will use
> the version from /usr/here, when the parameters of the
> libxyz library are given first to the compiler.
> 

Exactly, that's the problem that you need to solve if you want to 
support multiple dev copies of the same lib on the same system.

As I mentioned before, I do not have time/resources/knowledge to 
accomodate this kind of configuration and I'm not convinced yet that 
this is a legitimate case to support. If someone else wants to try then 
please go ahead, you've got the source.

The real long term solution to this IMHO is to provide precompiled 
binaries so that the users don't have to compile themselves. There are a 
few sets of Linux/Unix binaries here and there, but they don't cover all 
platforms yet unfortunately.

Daniel
-- 
------------------------------------------------------------
  Daniel Morissette               dmorissette at dmsolutions.ca
  DM Solutions Group              http://www.dmsolutions.ca/
------------------------------------------------------------