[gdal-dev] Fwd: Re: No SONAME in libgdal.so when building with --without-libtool

[Gareth Francis]

I've attached an updated patch, though I don't think it's good enough for
all gdal versions/platform combinations

libtool is provided with all 3 version components via -version-info and
uses them as a base for the soname entry.
On Linux/similar it should just be the first component (libgdal.so.21),
however some platforms have other requirements.
Without knowing all of the possible platforms, or exactly what libtool does
I don't think there's a sensible default (may be why there wasn't one at
all)

It's also possible that the so-version isn't always the same as the product
version..

I'm happy to maintain this change just for my build if needed. I don't
think it's a problem for the final build output, just test harnesses/etc
which run from the build directory (before rpaths/etc are stripped out).

Thanks
Gareth


On 9 August 2016 at 13:43, Even Rouault <even.rouault at spatialys.com> wrote:

> Forwarding to the list.
>
> ----------  Message transmis  ----------
>
> Sujet : Re: [gdal-dev] No SONAME in libgdal.so when building with
> --without-
> libtool
> Date : mardi 09 août 2016, 14:38:00
> De : Gareth Francis <gfrancis.dev at gmail.com>
> À : Even Rouault <even.rouault at spatialys.com>
>
> Not having a SONAME entry doesn't directly cause any problems, however
> libraries linked to libgdal.so can end up having a DT_NEEDED entry
> containing the library path '../../build/lib64/libgdal.so' instead of just
> 'libgdal.so.20'. This happens when linking with GNU ld using CMake's
> default behaviour. Linking without rpaths/etc probably avoids the issue.
>
> Any executable which doesn't directly link to libgdal.so will then try to
> look for '../../build/lib64/libgdal.so', regardless of the LD_LIBRARY_PATH
> contents.
>
> The only special case I can think of is Android, where the SONAME should
> just be 'libgdal.so' without any version numbers.
>
> I'll have to double-check what our version of libtool generated, I probably
> just made a mistake.
>
>
> On 9 August 2016 at 13:10, Even Rouault <even.rouault at spatialys.com>
> wrote:
>
> > Gareth,
> >
> > What sort of issue do you encounter with SONAME not being defined ?
> >
> > I've tested your patch and it doesn't generate the same soname as
> libtool.
> > libtool generates libgdal.so.20 deduced from the LIBGDAL_CURRENT /
> > LIBGDAL_REVISION / LIBGDAL_AGE variables.
> >
> > Digging into history, it seems to be a voluntary choice not to define by
> > default the soname in non-libtool builds, but I'm not sure why :
> > https://trac.osgeo.org/gdal/changeset/4855
> >
> > Even
> >
> > > Encountered on Centos 6, x86_64
> > >
> > > configured with --without-libtool, resulting libgdal.so has no SONAME
> > entry
> > >
> > > The link command for libgdal.so uses the variable 'GDAL_SLIB_SONAME'
> > which
> > > isn't defined in GDALmake.opt.in
> > >
> > > The attached patch fixes the issue, and I believe will generate the
> same
> > > name as libtool.
> > >
> > > Thanks
> > > Gareth Francis
> >
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com
> >
>
>
>
> --
> --------------------
> Gareth Francis
> www.gfrancisdev.co.uk
>
> -------------------------------------------------------
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev




-- 
--------------------
Gareth Francis
www.gfrancisdev.co.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160809/5c43c93b/attachment.html>
-------------- next part --------------
Index: GDALmake.opt.in
===================================================================
--- GDALmake.opt.in	(revision 35008)
+++ GDALmake.opt.in	(working copy)
@@ -135,6 +135,7 @@
 GDAL_LIB	= 	$(GDAL_ROOT)/libgdal.a
 GDAL_SLIB	=	$(GDAL_ROOT)/libgdal.$(SO_EXT)
 GDAL_SLIB_LINK	=	-L$(GDAL_ROOT) -lgdal
+GDAL_SLIB_SONAME = -Wl,-soname,libgdal.$(SO_EXT).$(LIBGDAL_CURRENT)
 
 # Mac OS X Framework definition
 MACOSX_FRAMEWORK = @MACOSX_FRAMEWORK@