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

[Sean Gillies]

On Oct 27, 2004, at 7:46 AM, Daniel Morissette wrote:

> 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,

There is a legitimate case: users who are trying to compile mapserver on
a system where

a) GD 1.8 (or less than 2.0.12) exists
b) this user can not sudo to remove a)

People are stymied when they try to build mapserv on their ISP's 
systems.
They really have no recourse other than to hack the configure script so
that it doesn't perform the check for gdImageSetAntialias.

Sean

--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies