Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]

[Sven M. H. <pe...@gm...>]

On Thu, Jun 07, 2001 at 11:30:22PM +0200, Marcelo E. Magallon wrote:
> >> li...@th... writes:
> 
>  > So the 1.2 is "static"? Have you looked at -release? I don't know what
>  > this will do to the SONAME though. It won't give you the name above
>  > but close enough (libGL-1.2.xxyyzz.so).
> 
>  This is the problem.  In this case the soname *must* be libGL.so.1 (on
>  Linux).  The problem is that the library is provided by several
>  vendors, and a sane development environment is needed: if I compile foo
>  with a particular vendor's version it must run with all the others.
>  The exposed interface is well defined and this level of compatibility
>  is achievable.  Mesa is unique in that it's available for a multitude
>  of platforms.  Linux is the only one where this issue is critical (it'd
>  be nice if Mesa used the native libgl's soname on every platfrom, but
>  it's just a minor issue)

As far as my understanding goes, the only platform where we're concerned about
the naming of the library archive and the soname is Linux right now, because
there exists an OpenGL ABI we need to follow WRT to the soname, and a common
convention for naming the archive file we wouldn't want to break with, either.

Therefore I think it is okay if we inspect the way libtool works on this
particular platform and devise a scheme which takes advantage of that, in
order to conform to the standards governing us (again only on that particular
platform). If further platforms with different conventions appear, we will
have to adopt specific strategies for them as well, of course.


Additionally I want to follow up to the argument against using generating
CURRENT, REVISION, and AGE in any other way than that described in the libtool
docs:

I have read the entire libtool documentation, and reread the version-info part
thoroughly for this particular problem. I fully agree with libtool's scheme of
encapsulating library version details behind an abstract interface. There's
actually no point in arguing against that.

With the above in mind, I was very careful to devise a scheme which would,
regardless of the concrete archive name and soname for now, first of all _not_
defy the purpose and meaning of libtool's version-info. I believe that, what 
I have come up with fully satisfies that requirement because the version-info
it creates (see my earlier post for a description) is still nothing else than
a description of the interface(s) the library implements. The reason is the
fact that the OpenGL interface is exactly defined by the OpenGL standard.
That standard has a clear versioning scheme which guarantees that any
interface change will be reflected by a corresponding version number change.
Finally, we use only that version number for the CURRENT and AGE fields.

As far as REVISION is concerned, libtool states that it is used to choose one
of multiple libraries implementing the _same_ interfaces. The only property
required of the number used as REVISION is that, for two libs of the same
interface, the greater REVISION number is to be preferred. Clearly the mesa
version number has that property.


I think the above shows that the proposed scheme does not conflict with any
libtool idiom, therefore justifying the call for a REVISION field supporting
large enough integers.


Best regards,
Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]