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 <[email protected]> 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 <[email protected]> > À : Even Rouault <[email protected]> > > 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 <[email protected]> > 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- -------------------- Gareth Francis www.gfrancisdev.co.uk
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@
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
