Howto set SONAME (DLLVERSION)?

I want to set SONAME to 1.33, since 1.33.1 should be compatible with 1.33.0. Where/how can I set this?

Doug Gregor wrote:
On Nov 11, 2005, at 9:31 AM, Neal Becker wrote:
I want to set SONAME to 1.33, since 1.33.1 should be compatible with 1.33.0. Where/how can I set this?
I'm not sure if 1.33.1 is binary compatible with 1.33.0 (and, worse, I don't know how to check...).
I guess the best bet would be to compile all tests with the 1.33.0 release, but then run them with boost libraries compiled with 1.33.1. Of course, that's still not sufficient, as tests don't guarantee to provide full coverage, but it might be a good indicator anyways. Regards, Stefan

Stefan Seefeld wrote:
Doug Gregor wrote:
On Nov 11, 2005, at 9:31 AM, Neal Becker wrote:
I want to set SONAME to 1.33, since 1.33.1 should be compatible with 1.33.0. Where/how can I set this?
I'm not sure if 1.33.1 is binary compatible with 1.33.0 (and, worse, I don't know how to check...).
I guess the best bet would be to compile all tests with the 1.33.0 release, but then run them with boost libraries compiled with 1.33.1.
Of course, that's still not sufficient, as tests don't guarantee to provide full coverage, but it might be a good indicator anyways.
Regards,
Thanks, guys - but does anyone know the answer to my original question? How do I use bjam and specify SONAME? I see it is called DLLVERSION in some jam files, but I don't know how to set it. I tried bjam -sDLLVERSION=xxx.

Neal Becker wrote:
Thanks, guys - but does anyone know the answer to my original question? How do I use bjam and specify SONAME? I see it is called DLLVERSION in some jam files, but I don't know how to set it. I tried bjam -sDLLVERSION=xxx.
As others mentioned, you really shouldn't as they are it's not guaranteed or tested to be binary compatible, and we specifically changed the naming because of that. But you can do it with "bjam -sBOOST_VERSION=1.33.0 ...". But that's only for the build and doesn't affect the internal CPP version numbers. And if you are on Unix/Linux I also don't see the point as one can make symlinks without the version number, as the regular build does. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

Rene Rivera wrote:
Neal Becker wrote:
Thanks, guys - but does anyone know the answer to my original question? How do I use bjam and specify SONAME? I see it is called DLLVERSION in some jam files, but I don't know how to set it. I tried bjam -sDLLVERSION=xxx.
As others mentioned, you really shouldn't as they are it's not guaranteed or tested to be binary compatible, and we specifically changed the naming because of that.
I think part of the confusion stems from a long tradition of using name-x.y.z in a way that only increasing x to x + 1 will indicate ABI incompatibility. Thus, from a packager's point of view (as opposed to project manager's) version 33.1 should never exist, it should be called 34 instead. (I have left out the initial '1.' here, as that seems to be a relict anyways.) Regards, Stefan

Rene Rivera wrote:
Neal Becker wrote:
Thanks, guys - but does anyone know the answer to my original question? How do I use bjam and specify SONAME? I see it is called DLLVERSION in some jam files, but I don't know how to set it. I tried bjam -sDLLVERSION=xxx.
As others mentioned, you really shouldn't as they are it's not guaranteed or tested to be binary compatible, and we specifically changed the naming because of that. But you can do it with "bjam -sBOOST_VERSION=1.33.0 ...". But that's only for the build and doesn't affect the internal CPP version numbers. And if you are on Unix/Linux I also don't see the point as one can make symlinks without the version number, as the regular build does.
Point is, when I do rpm -U boost-1.33.1-1.x86_64.rpm it will remove the libraries and all bins will have to be rebuilt.

I'm not sure if 1.33.1 is binary compatible with 1.33.0 (and, worse, I don't know how to check...).
Lordy. You can start with just looking at what is exported, and checking to see if things were added or removed between 1.33.0 and 1.33.1. That's a good first step. Some of this is checking automated on different build systems, or has been hacked in. -benjamin

On Mon, 14 Nov 2005 13:27:02 -0600, Benjamin Kosnik wrote
I'm not sure if 1.33.1 is binary compatible with 1.33.0 (and, worse, I don't know how to check...).
Lordy.
You can start with just looking at what is exported, and checking to see if things were added or removed between 1.33.0 and 1.33.1. That's a good first step.
I assume you are talking about something like 'nm -g' ? Jeff
participants (6)
-
Benjamin Kosnik
-
Doug Gregor
-
Jeff Garland
-
Neal Becker
-
Rene Rivera
-
Stefan Seefeld