[mapserver-dev] libtool usage

[thomas bonfort]

Daniel, Steve,



On Mon, Dec 19, 2011 at 16:54, Stephen Woodbridge
<woodbri at swoodbridge.com> wrote:
> On 12/19/2011 10:03 AM, Daniel Morissette wrote:
>>
>> On 11-12-18 9:26 AM, thomas bonfort wrote:
>>>
>>> While trying to build mapserver as a shared library, it occured to me
>>> that our build-process is rather fragile. (For the curious this is
>>> ongoing work on making a mapserver apache module, which requires a
>>> clean+crossplatform way of loading the libmapserv shared library into
>>> the httpd server).
>>>
>>> Is there a reason we are not using libtool for managing the
>>> compilation tasks for us?
>>> I know gdal can be configured to build with or without libtool, is
>>> there a reason to maintain both build scripts?
>>>
>>
>> Hi Thomas,
>>
>> My little experience with GDAL's libtool builds over the years is that
>> there is some magic behind libtool that doesn't work on every platform
>> (or with unusual configurations), and when it doesn't work it is nearly
>> impossible to troubleshoot for non-libtool experts and then we end up
>> falling back on buildibg without libtool which just works.

I understand your reticense, however note that in our current setup we
are bandaid fixing our build tools to support shared libraries, with
marginal success (php mapscript has to be statically linked to
libmapserver, we are unconditionaly adding -fPIC on static builds,
getting the apache module to load requires either a static build or
manually adding a Loadfile libmapserver.so in httpd.conf, ...). I am
confident that the libtool guys are much better than we are in sorting
these things out, even though the blackbox approach of libtool might
seem a bit unnerving.

>>
>> I admit that I do not have a clear idea of the real issues and whether
>> they are fixable, but I have had to switch back to non-libtool builds of
>> GDAL in the past when libtool builds would not work... so I am hesitant
>> to support a complete switch to libtools, but then I also realize that I
>> should not prevent this kind of move forward without some good reasons.
>> If we make that switch, are you prepared to support libtool related
>> issues on all platforms and configurations that used to work without it?
>> (That's a big commitment)
I'm probably being naive, but I do not anticipate this to be a
daunting task. My libtool-builded mapserv (cgi+fcgi), mod_mapserver.so
and php_mapscript.so , dybamically linked to a libmapserver.so placed
in a non-standard location, all load flawlessy on debian and osx (the
latter being an known pain to support with custom gcc/ld build
commands, at least from my experience)


>>
>> Maybe Frank or others involved in the GDAL libtool build support could
>> share their experience?

I would very much like to get the feedback of Frank or Even on this, yes.

>>
>
> Is there anything in the refactoring that you need to do that would prevent
> us from supporting both libtool and non-libtool builds? Like
>
> ./configure --with-libtool=[yes|no]
>
> I admit that I'm asking out ignorance as to the effort to do this, but as
> Daniel points out when it does not work he reverted to non-libtools builds,
> so it seems prudent to maintain support for that regardless.

In theory this would be possible, as the changes to the Makefile.in
are sufficiently limited to allow us to use both. In practice, I have
already spent too many hours/days trying to get the dynamic library
loading working without libtool to want to invest any more time in
doing so (as both build systems would need to be kept in sync
featurewise). The move to libtool also removes a lot of cruft from
configure.in / Makefile.in which we would have to put back would we
want to support both.

>
> I would agree with the fact that libtool is much more complicated behind the
> scenes which is not a problem in and of itself as long as things work.
>
> On the other side, I think being able to support mapserver as an apache
> module and as a clean shared library has a lot of benefit to the project.

I also think the benefits outrun the risks. We get to stop maintaining
shared builds, to build dynamically linked binaries and php module (I
have not tried the swig modules yet), and a functional mod_mapserver
apache module, which is well worth it performance wise, as seen on an
identical request coming from the wms shootout:

ab -c10 -n1000 -k
'http://localhost/wms?LAYERS=default&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&FORMAT=image%2Fpng&SRS=EPSG%3A900913&BBOX=-567468.49798891,6750918.338147,-557684.5583684,6760702.2777675&WIDTH=256&HEIGHT=256'

Requests per second:    218.02 [#/sec] (mean)


ab -c10 -n1000 -k
'http://localhost/fcgi-bin/mapserv?MAP=/Users/tbonfort/dev/mapserver-utils/osm-google.map&LAYERS=default&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&FORMAT=image%2Fpng&SRS=EPSG%3A900913&BBOX=-567468.49798891,6750918.338147,-557684.5583684,6760702.2777675&WIDTH=256&HEIGHT=256'

Requests per second:    74.22 [#/sec] (mean)


>
> -Steve W
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev