Menu
▾
▴
mesa3d-dev
|
From: Sven M. H. <pe...@gm...> - 2001-06-07 10:43:02
|
Hi,
I'm working on the Mesa project's build system using autoconf, automake, and
libtool. We're running into the following problem:
We use the formula
version-info = Major+minor:Mesa_version:Minor
to compute proper libtool version-info from the OpenGL version number (1.2)
and our current Mesa release number (MM.Mm.Mt, e.g. 3.5.0). So, Mesa_version
is an integer derived from that release number. We'd like to use
Mesa_version = MM * 10^4 + Mm * 10^2 + Mt
which would yield something like 30500. However libtool only accepts three
digits for the REVISION part of the version-info (as Marcelo mentions below).
Is it possible to extend that limitation to five or six digits?
That would be greatly appreciated.
Thanks in advance,
Sven
PS: Libtool rocks!
----- Forwarded message from "Marcelo E. Magallon" <mar...@bi...> -----
From: "Marcelo E. Magallon" <mar...@bi...>
To: Brian Paul <br...@va...>
Cc: mes...@li...
Subject: Re: [Mesa3d-dev] Re: libtool (was CVS and SSE)
Date: Mon, 21 May 2001 23:41:40 +0200
>> Brian Paul <br...@va...> writes:
> I'm curious why revision 30500 doesn't work. Do you know if the revision
> is stored as a number or a string? I'd at least ask the libtool people why
> 30500 doesn't work.
because libtool defines non negative as:
0 | [1-9] | [1-9][0-9] | [1-9][0-9][0-9]
i.e., it not only can't start with 0, it can only have three digits. I
suspect this has to do with some funny test or expr implementation. Or
perhaps they thought three digits would be enough. Or maybe some sick
linker uses integers to store this info.
Hmm... funky that '0 | [1-9]' bit...
--
Marcelo
_______________________________________________
Mesa3d-dev mailing list
Mes...@li...
http://lists.sourceforge.net/lists/listinfo/mesa3d-dev
----- End forwarded message -----
--
"Would the All-Seeing Eye please look in my direction?"
[ KeyID........: 0xC297FEAB ]
[ Fingerprint..: FEA5 0F93 7320 3F39 66A5 AED3 073F 2D5F C297 FEAB ]
|
|
From: Peter E. <pe...@gm...> - 2001-06-07 15:23:24
|
Sven M. Hallberg writes: > We use the formula > version-info = Major+minor:Mesa_version:Minor > to compute proper libtool version-info from the OpenGL version number (1.2) > and our current Mesa release number (MM.Mm.Mt, e.g. 3.5.0). So, Mesa_version > is an integer derived from that release number. We'd like to use > Mesa_version = MM * 10^4 + Mm * 10^2 + Mt > which would yield something like 30500. However libtool only accepts three > digits for the REVISION part of the version-info (as Marcelo mentions below). You must have missed the part of the documentation that says: : *_Never_* try to set the interface numbers so that they correspond : to the release number of your package. This is an abuse that only : fosters misunderstanding of the purpose of library versions. (not my emphasis) The documentation describes in detail how you are supposed to set the three version fields. Anything else will be trouble. -- Peter Eisentraut pe...@gm... http://funkturm.homeip.net/~peter |
|
From: Brian P. <br...@va...> - 2001-06-07 17:47:54
|
Peter Eisentraut wrote: > > Sven M. Hallberg writes: > > > We use the formula > > version-info = Major+minor:Mesa_version:Minor > > to compute proper libtool version-info from the OpenGL version number (1.2) > > and our current Mesa release number (MM.Mm.Mt, e.g. 3.5.0). So, Mesa_version > > is an integer derived from that release number. We'd like to use > > Mesa_version = MM * 10^4 + Mm * 10^2 + Mt > > which would yield something like 30500. However libtool only accepts three > > digits for the REVISION part of the version-info (as Marcelo mentions below). > > You must have missed the part of the documentation that says: > > : *_Never_* try to set the interface numbers so that they correspond > : to the release number of your package. This is an abuse that only > : fosters misunderstanding of the purpose of library versions. > > (not my emphasis) > > The documentation describes in detail how you are supposed to set the > three version fields. Anything else will be trouble. I'm not going to put a lot of effort into explaining this but here's the story. Mesa's used the convention libGL.so.1.2.xxyyzz for some years now. The "1.2" indicates the library implements the OpenGL 1.2 API. Anything else there would be VERY confusing for end users at this point. The last part "xxyyzz" is usually something like 030402 to indicate Mesa version 3.4.2. With this convention, people can look at their libGL.so.1.2.xxyyzz file and determine which version of Mesa they're using. It also allows various versions of libGL.so.1.2.* to coexist. This very useful for the developers so we may easily switch between versions when doing regression testing. I understand that libtool has a specific versioning convention and we don't want you to change that. It's just that if the REVISION part could accomodate a 6-digit number (with leading zeros) we'd be grateful. -Brian |
|
From: Lars J. A. <la...@si...> - 2001-06-07 18:26:50
|
On Thu, Jun 07, 2001 at 11:50:44AM -0600, Brian Paul wrote: : I'm not going to put a lot of effort into explaining this but here's : the story. : : Mesa's used the convention libGL.so.1.2.xxyyzz for some years now. : The "1.2" indicates the library implements the OpenGL 1.2 API. : Anything else there would be VERY confusing for end users at this : point. You probably won't be able to use that scheme with libtool without changing libtool. libtool doesn't just pass the integers through the system for library naming reasons. Another thing is that how the numbers are set up depends on the system (e.g. on IRIX, the age part is dropped from the library filename, and the current part is incremented by one). Lars J |
|
From: <li...@th...> - 2001-06-07 19:41:09
|
On Thu, Jun 07, 2001 at 11:50:44AM -0600, Brian Paul wrote: > I'm not going to put a lot of effort into explaining this but here's > the story. > > Mesa's used the convention libGL.so.1.2.xxyyzz for some years now. > The "1.2" indicates the library implements the OpenGL 1.2 API. > Anything else there would be VERY confusing for end users at this > point. > > The last part "xxyyzz" is usually something like 030402 to indicate > Mesa version 3.4.2. With this convention, people can look at their > libGL.so.1.2.xxyyzz file and determine which version of Mesa they're > using. It also allows various versions of libGL.so.1.2.* to coexist. > This very useful for the developers so we may easily switch between > versions when doing regression testing. 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). -- albert chin (ch...@th...) |
|
From: Marcelo E. M. <mar...@bi...> - 2001-06-07 21:30:41
|
>> 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) What Mesa needs from libtool is libtool's knowledge about multiple platform's oddities regarding compilation and linking, but it also needs a way to be able to set the soname. Yes, this is bad in general. It defeats the whole purpose of libtool, but the problem is that Mesa is providing another version of an existing library. I can imagine things like Motif (lesstif), OpenInventor (Coin, mostly non issue now) are in the same situation. -- Marcelo |
|
From: Lars J. A. <la...@si...> - 2001-06-08 11:25:53
|
On Thu, Jun 07, 2001 at 11:30:22PM +0200, Marcelo E. Magallon wrote: : needs a way to be able to set the soname. Yes, this is bad in general. : It defeats the whole purpose of libtool, but the problem is that Mesa : is providing another version of an existing library. I can imagine : things like Motif (lesstif), OpenInventor (Coin, mostly non issue now) : are in the same situation. Just to digress; for Coin we use the soname libCoin.so.#.#.# (normal libtool version-info) because Open Inventor is C++, and achieving ABI-compatibility with it is impossible. I don't even think either SGI or TGS Open Inventor is ABI-compatible with itself for many version-increments at a time. Of course, your point is still valid for the situation with Mesa and Lesstif. Another digression; I'd like to know what you meant with the "mostly non issue" comment. Lars J |
|
From: Marcelo E. M. <mar...@bi...> - 2001-06-08 15:04:50
|
>> "Lars J. Aas" <la...@si...> writes: > Another digression; I'd like to know what you meant with the "mostly non > issue" comment. I forgot there's still a "Professional Edition" of Coin, and that even LGPL Coin is anything but dead. My mistake. WRT ABI compatibility, it should be possible with gcc 3.0. Other compilers are a different can of worms. -- Marcelo |
|
From: Sven M. H. <pe...@gm...> - 2001-06-09 23:16:14
|
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 ] |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X