[mapserver-dev] Revisit installing multiple mapserver versions

[thomas bonfort]

Steve,
While I agree with your conclusion, I believe you are somewhat
mistaken with your reluctance towards the first solution (more
inline...)

On Mon, Jul 16, 2012 at 9:11 PM, Stephen Woodbridge
<woodbri at swoodbridge.com> wrote:
> On 7/16/2012 12:45 PM, thomas bonfort wrote:
>>
>> I believe we have 2 options here:
>> - without any change to our build, you can configure with
>> --prefix=/usr/local/mapserver-6.2, then
>> /usr/local/mapserver-6.2/bin/mapserv will link to
>> /usr/local/mapserver-6.2/lib/libmapserver.so, and your multiple
>> mapserv binaries can be copied around and will link to their original
>> libmapserver.so location
>
>
> While this seems straight forward, I really don't like the proliferation of
> directories and the potential impact on PATH, LD_LIBRARY_PATH, INCLUDE to
> manage these. As an occasional hacker, I can certainly manage this on my
> personal systems, but my concern is the need to manage this in production
> environments.
for PATH: you'd have to deal with this anyways if you want to have
multiple versions running in parallel, unless we'd suffix our binaries
with a version number.
for INCLUDE: we don't publish an (stable) api, and even if we did
publish an unstable one then dispatching to distinct directories would
make it easier to configure other projects by referencing a distinct
path

>
> I also think that this requires setting LD_LIBRARY_PATH appropriately for
> the the executable in question to find its appropriate library.
for LD_LIBRARY_PATH: on all the recent linux distros I have worked
with, there is no need to set this one as $prefix/lib is encoded into
the created binary. I have my dev versions $prefix'd to ~/local and
have never had to set LD_LIBRARY_PATH to ~/local/lib

>
>
>> - we can update our build process to add libtool version-info
>> information, which is supposed to work in this case. This will need to
>> be manually tweaked at release time as the libtool version-info isn't
>> related to our own versioning scheme (c.f.
>>
>> http://www.freesoftwaremagazine.com/articles/building_shared_libraries_once_using_autotools,
>> scroll down to "The Libtool library versioning scheme")
>
>
> OK, this is an extra step (and something that needs to be added to the
> release check list) from a development point of view to make sure we version
> things correctly it clearly seems to be the right way to go. From the end
> users point of view and the system admin managing deployment this should be
> straight forward and intuitive and should minimize support questions and
> issues. I strongly recommend that mapserver adopt this as part of our
> release practice.
I agree that an extra step on our part is beneficial, and libtool
provides us the tools to (more or less) easily accomplish this.

>
> Would you like me to open a ticket requesting this?
yes please.
>
> BTW, thanks for the libtool article, that was very informative.

thanks for the feedback. btw, not trying to be pejorative here, just
giving some extra info as to why the first solution isn't completely
off-base from my point of view.

cheers,
thomas

>
> Thanks,
>   -Steve W
>
>
>> thomas
>>
>> On Mon, Jul 16, 2012 at 5:50 PM, Stephen Woodbridge
>> <woodbri at swoodbridge.com> wrote:
>>>
>>> Thomas,
>>>
>>> I am have a problem with multiple mapserver versions installed. This is a
>>> common scenario in many environments. Looking at my system, I have:
>>>
>>>> woodbri at mappy:$ ls /usr/local/lib/libmaps* -l
>>>> -rwxr-xr-x 1 root root 5942968 2012-07-02 09:36
>>>> /usr/local/lib/libmapserver-6.1-dev.so
>>>> -rwxr-xr-x 1 root root 5934502 2012-07-14 17:10
>>>> /usr/local/lib/libmapserver-6.2.0-beta1.so
>>>> -rwxr-xr-x 1 root root 5935167 2012-07-14 23:24
>>>> /usr/local/lib/libmapserver-6.3-dev.so
>>>> -rwxr-xr-x 1 root root    2066 2012-07-14 23:24
>>>> /usr/local/lib/libmapserver.la
>>>> lrwxrwxrwx 1 root root      23 2012-07-14 23:24
>>>> /usr/local/lib/libmapserver.so -> libmapserver-6.3-dev.so
>>>> woodbri at mappy:$ ls /usr/local/lib/libmapserver.so -l
>>>> lrwxrwxrwx 1 root root 23 2012-07-14 23:24
>>>> /usr/local/lib/libmapserver.so
>>>> -> libmapserver-6.3-dev.so
>>>
>>>
>>>
>>>> woodbri at mappy:$ ls /usr/local/bin/mapserv
>>>> /usr/local/bin/mapserv
>>>
>>>
>>>
>>>> woodbri at mappy:$ mapserv -v
>>>> MapServer version 6.3-dev OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG
>>>> SUPPORTS=PROJ
>>>> SUPPORTS=GD SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=ICONV
>>>> SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT
>>>> SUPPORTS=WFS_SERVER
>>>> SUPPORTS=GEOS INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL
>>>> INPUT=SHAPEFILE
>>>
>>>
>>>
>>> This one works fine since it was last installed. But my typical pattern
>>> is
>>> to install mapserver then:
>>>
>>>    cp /usr/local/bin/mapserv /path/to/cgi-bin/mapserv-<version>
>>>
>>> So I have these on my system:
>>>
>>> /usr/lib/cgi-bin/mapserv
>>> /usr/lib/cgi-bin/mapserv-6.1-dev
>>> /usr/lib/cgi-bin/mapserv-6.2-beta1
>>> /usr/lib/cgi-bin/mapserv-60
>>> /usr/lib/cgi-bin/mapserv-tc
>>>
>>> I think the problem is the symlink:
>>>
>>> /usr/local/lib/libmapserver.so -> libmapserver-6.3-dev.so
>>>
>>> Ideally the executable should try to load the explicit library that it
>>> was
>>> built against and not some generic libmapserver.so that is a symlink and
>>> then I think everything would work just fine.
>>>
>>> Is this something that can be done?
>>>
>>> Thanks,
>>>    -Steve
>>> _______________________________________________
>>> mapserver-dev mailing list
>>> mapserver-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>
>