Re: [Mesa3d-dev] libtool (was CVS and SSE)

[Marcelo E. M. <mar...@bi...>]

>> Brian Paul <br...@va...> writes:

 > "Sven M. Hallberg" wrote:

 > > - Set a libtool -version-info of 0:MESA_VERSION:0 where
 > >   MESA_VERSION would be 30500 for Mesa 3.5.0.
 > > - On Linux (for ABI-conformance), use an install-hook to create two
 > >   symbolic links: libGL.so.1 to libGL.so.0.MESA_VERSION.0 and
 > >   libGL.so to libGL.so.1.

 I missed Sven's post.  Please don't do this.  It breaks binary
 compatibility.  On Linux, among others, the soname would end up being
 libGL.so.0, which means programs compiled with this version of libGL
 would require a libGL.so.0 in order to run.  The symbolic links only
 solve the other problem (compiled with libGL.so.1 and run with
 libGL.so.0 present).  Fixing this once when the library was called
 libMesaGL.so.3 was painful enough...

 > IMHO, libtool should have an option to support arbitrary version numbers.

 It has.  Please don't use it, it's a headache. (-release-info).  The
 problem libtool solves doesn't exist in the case of a GL library,
 namely, how do you ensure you aren't breaking binary compatibility on a
 given plataform?  Some dynamic linkers have the concept of library
 versions, some don't.  And those that have it, don't share it with the
 other (not always, at least).  When you use libtool, you place your
 library's versioning in libtool's hands.  Those who try to change
 libtool's idea of "correct versioning" get burned (the lucky ones end
 up with libfoo-1.2.so as library names, the really lucky ones get away
 with it only because the library already has an stable API).  libtool
 solves another problem, namely, how do you compile a library on system
 X with compiler Y?  At this, libtool does a superb job.  But by design,
 the two solutions are coupled.

-- 
Marcelo