From: Bernhard K. <ber...@gm...> - 2003-07-12 18:09:36
|
On Fri, 11 Jul 2003, Chris Purnell wrote: > On Thu, Jul 10, 2003 at 07:30:35PM -0500, Steve Baker wrote: > > Chris Purnell wrote: > > > > >I was not talking about the symlinks. I was talking about the > > >actual soname of the library. The soname is what is important. > > > > Oh - I see - yeah - I guess that needs to be libglut.so.3 > > I thought you mean't the filename it was actually installed under. > > > > >Having freeglut build libfreeglut.so.2 is a lot like the days > > >of libMesaGL.so. > > > > Yeah - we don't want to go *there*. > > The thing is that I don't know how to get libtool to make a shared library > with a soname unrelated to the filename and ldconfig automatically creates > symlinks for the soname. If we want freeglut to be a complete drop-in replacement for glut 3.7, we not only have to use the same filenames but also the same soname. The reason is that packaging tools will (at least I know that rpm does) read the soname from the library(/usr/lib/rpm/find-provides does it) and if the AutoReqProv setting in the spec file of the rpm package is on, it will fill the "Provides" field in the built rpm with this information. If one builds an rpm package, and AutoReqProv is on(which is very recommened normally) rpm -qp --provides <rpm> will not list libglut.so.3, but libglut.so.2 if the SONAME in the library is not changed to libglut.so.3 as well: from /usr/lib/rpm/find-provides: for f in $filelist; do soname=$(objdump -p $f | awk '/SONAME/ {print $2}') So I think what we would need to do to be complete drop-in compatible is to rename libfreeglut.{la,so*} to libglut.{la,so{,.3}}, so we would have: libglut.la (libtool dependency file for static links with -lglut) libglut.so (symlink for shared library compile/link with -lglut) libglut.so.3 (symlink for dynamic link for ld.so, updated by ldconfig) The initial actual shared library file will be libglut.so.3.0.0. For this, src/src/Makefile.am would need to be changed as this unified diff indicates: --- src/Makefile.am +++ src/Makefile.am @@ -6 +6 @@ -lib_LTLIBRARIES = libfreeglut.la +lib_LTLIBRARIES = libglut.la @@ -11 +11 @@ -libfreeglut_la_SOURCES = freeglut_callbacks.c \ +libglut_la_SOURCES = freeglut_callbacks.c \ @@ -37,2 +37,2 @@ -libfreeglut_la_LIBADD = $(LIBM) $(X_LIBS) -lGL -lGLU -lXext -lX11 -lXxf86vm -libfreeglut_la_LDFLAGS = -version-info 2:0:0 +libglut_la_LIBADD = $(LIBM) $(X_LIBS) -lGL -lGLU -lXext -lX11 -lXxf86vm +libglut_la_LDFLAGS = -version-info 3:0:0 I think we should *not* attempt to encode some 3.2.0 or some other version number into the libtool version, because libtool has it's own versioning symbol and if we want it, we should follow it. To me it looks to be a good idea, but we have to keep in mind that the library version number which will be visible in the filename will have nothing to do with freeglut's release version number. Obviously, glut itself does not use libtools versioning scheme and at least on my system it name of the shared library itself is libglut-3.7.1 (like the relase number) but with libtool, we would have a very powerful versions system at hand. The idea behind libtool's versioning system is that a library exports one or more interface versions of itself, specifically, it support a "CURRENT" interface, which is in glut/freeglut's case the number 3. In addition the implementation of the "CURRENT" has a "REVISION" which means if the linker finds a matching interface implementation, it will use the library with the highest "REVISION". Last, and this is the interesting part, I think, it supports an "AGE" field, which is used to tell the "AGE" of the oldest interface (older than "CURRENT") which is supported by this library, so "AGE" ultimantively results in being able to specify a range of interface implementations supported by the library, going down from current(e.g. "0" if it does not support older interface implementation. Currently we use the libtool versioning system, we use -version-info in src/Makefile.am, info libtool says about it: ---- If you want to use libtool's versioning system, then you must specify the version information to libtool using the `-version-info' flag during link mode (*note Link mode::). This flag accepts an argument of the form `CURRENT[:REVISION[:AGE]]'. So, passing `-version-info 3:12:1' sets CURRENT to 3, REVISION to 12, and AGE to 1. ---- So using -version-info 3:0:0, in combination with the rename of the library from libfreeglut to libglut seems to be needed to make it completely compatible(not even needing to relink apps -> completely obsoleting glut) If this is the goal, I think the above diff to src/Makefile.am looks right to me and I would be happy to see it on one hand, because I could drop glut then, but unfortunately there is the compatibility problem with menu rendering, with this setup, as long as glut is installed, it will be used. But one would have to uninstall glut in order to use freeglut... And there would be the packaging problem because of the conflicting /usr/lib/libglut.so.3 file for both packages, so one would have to run ldconfig to fix the link after install/uninstall... So I'm not sure how to solve this best. One idea might be to use -version-info 4:0:0 for libglut.so.4, do not set an 'age' value because freeglut is not 100% compatible (the menu drawing) and let people which need binary compatibitly with libglut.so.3 set a symlink libglut.so.3 -> libglut.so.4, apparantly ldconfig does not delete it at least. But with this we could also keep -version-info 2:0:0 for libglut.so.2, no need to open a arbitrary number of 4. However I could not find a "clean" way to this yet, the symlink for already binary compatibiltiy seems to be some kind of hack also. Bernhard |