[PATCH] add soname

[GoogleCodeExporter]

What steps will reproduce the problem?
1. scons
2. scons install 
3. obbjdump -x libserf-1.so | grep SONAME

What is the expected output? What do you see instead?

actual: (nothing)
expected: SONAME               libserf-1.so.0

What version of the product are you using? On what operating system?

1.3.0, GNU/Linux openSUSE 12.1, 12.2, 12.3, Factory (13.1)

Please provide any additional information below.

The attached patch passes the soname to the linker. 

Original issue reported on code.google.com by andreas.stieger@gmx.de on 24 Jul 2013 at 10:30

[GoogleCodeExporter]

Original comment by andreas.stieger@gmx.de on 24 Jul 2013 at 10:31

Attachments:

• libserf-1.3.x-soname.patch

[GoogleCodeExporter]

Applying a global linker flag that applies to all platforms is not the right 
way to fix this.

Looking through the SCons sources for this flag it appears that you/we should 
use the VersionedSharedLibrary, to automatically handle the right flags on all 
platforms.

A patch like:

Index: SConstruct
===================================================================
--- SConstruct  (revision 2076)
+++ SConstruct  (working copy)
@@ -184,6 +184,8 @@ thisdir = os.getcwd()
 libdir = '$PREFIX/lib'
 incdir = '$PREFIX/include/serf-$MAJOR'

+env['SHLIBVERSION']='0.${MAJOR}.0'
+
 LIBNAME = 'libserf-${MAJOR}'
 if sys.platform != 'win32':
   LIBNAMESTATIC = LIBNAME

----
Should handle this completely platform independent, applying about the same 
code as your patch on most posix systems, but something completely different on 
'darwin' and 
'cygwin'.

Original comment by bhuijben on 25 Jul 2013 at 8:12

[GoogleCodeExporter]

SHLIBVERSION was introduced in scons 2.3.0 releases in March. Would that be 
acceptable?

Original comment by andreas.stieger@gmx.de on 25 Jul 2013 at 5:49

[GoogleCodeExporter]

The macport version of scons is 2.3.0. My Ubuntu install only has 2.2.x.

Just adding an envvar won't "require" 2.3.0... it'll just mean the symlinks 
won't appear when run with 2.2.x. I think that we could print a warning in that 
case.

Original comment by gstein on 26 Jul 2013 at 6:53

• Changed state: Accepted

[GoogleCodeExporter]

Just to confirm that setting SHLIBVERSION with scons >= 2.3.0 works for me, and 
I can work around for previous releases with the previous patch.

Original comment by andreas.stieger@gmx.de on 28 Jul 2013 at 1:22

Attachments:

• libserf-1.3.x-soname.patch

[GoogleCodeExporter]

Setting SHLIBVERSION is not enough, need to use env.InstallVersionedLib to get 
both the shared library without version and the symbolic link. Also, I think we 
should have the minor version in the library name.

Attached patch will give this as result on Mac OS X:
/usr/local/lib/libserf-1.3.0.0.dylib
/usr/local/lib/libserf-1.a
/usr/local/lib/libserf-1.dylib -> libserf-1.3.0.0.dylib

and for trunk:
/usr/local/lib/libserf-2.0.0.0.dylib
/usr/local/lib/libserf-2.a
/usr/local/lib/libserf-2.dylib -> libserf-2.0.0.0.dylib

Original comment by lieven.govaerts@gmail.com on 5 Aug 2013 at 10:06

Attachments:

• scons_shared_lib_version.patch.txt

[GoogleCodeExporter]

Original comment by chemodax@gmail.com on 9 Aug 2013 at 4:53

• Added labels: scons

[GoogleCodeExporter]

Fixed in r2124, using SHLIBVERSION and InstallVersionedLib.

Original comment by andreas.stieger@gmx.de on 10 Aug 2013 at 7:45

• Changed state: Fixed