On 15/05/2005, at 12:24 PM, Peter O'Gorman wrote:
It what sense do you think 'it works fine'? How does a single
libtool version string get translated into the two possibly
different version strings required by MacOS X?
I don't follow what you think is wrong. Libtool's versioning system
us
Bill Northcott wrote:
On 15/05/2005, at 12:55 AM, Peter O'Gorman wrote:
It what sense do you think 'it works fine'? How does a single libtool
version string get translated into the two possibly different version
strings required by MacOS X?
I don't follow what you think is wrong. Libtool's ver
On 15/05/2005, at 10:06 PM, Peter O'Gorman wrote:
Possibly, the last line could equally be:
install_name libfoo.2.dylib compatibility_version 3.0.0
current_version 3.2.15
That would have the same effect on Darwin, if applied consistently.
The encoded current_version is for informational purpose
On 15/05/2005, at 1:57 PM, Peter O'Gorman wrote:
I have so far only found one GNU libtool packages which correctly
versions its libraries on MacOS X. This is R and they seem to do
it with code in Makefile.in which overrides the libtool versioning.
Looks like R builds a framework on darwin a
On 15/05/2005, at 10:06 PM, Peter O'Gorman wrote:
Possibly, the last line could equally be:
install_name libfoo.2.dylib compatibility_version 3.0.0
current_version 3.2.15
That would have the same effect on Darwin, if applied consistently.
The encoded current_version is for informational purpose
Bill Northcott wrote:
Possibly, the last line could equally be:
install_name libfoo.2.dylib compatibility_version 3.0.0 current_version
3.2.15
That would have the same effect on Darwin, if applied consistently.
The encoded current_version is for informational purposes only, nothing uses
it, com
Bill Northcott wrote:
I have so far only found one GNU libtool packages which correctly
versions its libraries on MacOS X. This is R and they seem to do it
with code in Makefile.in which overrides the libtool versioning.
Looks like R builds a framework on darwin and uses install_name_tool to
On 15/05/2005, at 12:55 AM, Peter O'Gorman wrote:
| How should libtool versioning be used so as to support both the
MacOS
| X/Darwin scheme and the Linux ELF way of doing things? Is this
| possible, or should one write specific makefile routines to adjust
| version numbers at install time?
Mac
On Sat, 14 May 2005, Ed Hartnett wrote:
In the case of shared library versions, what about the header file?
Most libraries (including the one I am converting to libtool) have a
header file that is installed along with the library.
Although the versioning scheme is very clever about letting me have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill Northcott wrote:
| How should libtool versioning be used so as to support both the MacOS
| X/Darwin scheme and the Linux ELF way of doing things? Is this
| possible, or should one write specific makefile routines to adjust
| version numbers at ins
On Sat, May 14, 2005 at 05:28:10AM -0600, Ed Hartnett wrote:
> In the case of shared library versions, what about the header file?
>
> Most libraries (including the one I am converting to libtool) have a
> header file that is installed along with the library.
>
> Although the versioning scheme is
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> On Fri, 13 May 2005, Ed Hartnett wrote:
>>
>> How does the version number get used in this situation? That is, is
>> there any time on the users machine that the linker notices that he is
>> now linking to 1.0.0 instead of 0.0.0?
>
> Yes, the linker no
On 14/05/2005, at 3:45 AM, Ed Hartnett wrote:
But I don't understand why it's not 0.5.0 and 0.6.0. That is,
wouldn't
it be a case of incrementing the minor version number, the middle
number?
If libexample 0.0.6 is merely a bug fix, it is usually customary to
only
updated the least significant
On 14/05/2005, at 1:33 AM, Bob Friesenhahn wrote:
How does the version number get used in this situation? That is, is
there any time on the users machine that the linker notices that
he is
now linking to 1.0.0 instead of 0.0.0?
Yes, the linker notices it when it runs. :-)
Existing programs conti
On Fri, 13 May 2005, Ed Hartnett wrote:
Daniel Reed <[EMAIL PROTECTED]> writes:
Many projects will continue to make bug fix releases even if a newer
API is currently under development--including Libtool itself. For this
example scenario, if libexample-1.0.2 is the current release, but a
critical bu
On Fri, 13 May 2005, Ed Hartnett wrote:
So this is not actually replacing libexample-0.0.5, it is adding
libexample-0.0.6, and the loader is smart enough to automatically use
that in preference to libexample-0.0.5.
Right
Is that correct? And libexample-0.0.5 stays on the users' systems
until they f
Daniel Reed <[EMAIL PROTECTED]> writes:
> On Fri, 13 May 2005, Ed Hartnett wrote:
>> Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>>> Yes. Unless it is explicitly deleted.
>> Suppose that we discover a bug which doesn't require any API change to
>> fix, but which will cause he users' computers to
On Fri, 13 May 2005, Daniel Reed wrote:
People using software that depends on libexample's 1 series should not be
confused by the new release for the older 0 series, because 0.0.6 is still
less than 1.0.anything. The only down side is that installing libexample
0.0.6 might cause libexample.so to
On Fri, 13 May 2005, Ed Hartnett wrote:
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
That implies that when I install a new version, the old version says
around. Is that correct?
Yes. Unless it is explicitly deleted.
Suppose that we discover a bug which doesn't require any API change to
fix, but wh
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>> That implies that when I install a new version, the old version says
>> around. Is that correct?
>
> Yes. Unless it is explicitly deleted.
>
Suppose that we discover a bug which doesn't require any API change to
fix, but which will cause he users' c
On Fri, 13 May 2005, Ed Hartnett wrote:
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
On Fri, 13 May 2005, Ed Hartnett wrote:
How does the version number get used in this situation? That is, is
there any time on the users machine that the linker notices that he is
now linking to 1.0.0 instead of 0.0.
On Fri, 13 May 2005, Ed Hartnett wrote:
I hope things are well in the Great State of Texas today!
OK, so an existing program, linked to version 0.0.0, will continue to
use the old version of the library?
Yes. If there is an implementation change (e.g. bug-fix) with no
interface change, then if yo
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> On Fri, 13 May 2005, Ed Hartnett wrote:
>>
>> How does the version number get used in this situation? That is, is
>> there any time on the users machine that the linker notices that he is
>> now linking to 1.0.0 instead of 0.0.0?
>
> Yes, the linker no
On Fri, 13 May 2005, Ed Hartnett wrote:
How does the version number get used in this situation? That is, is
there any time on the users machine that the linker notices that he is
now linking to 1.0.0 instead of 0.0.0?
Yes, the linker notices it when it runs. :-)
Existing programs continue to use ex
24 matches
Mail list logo
