[Scons-users] InstallVersionedLib should respect SONAME variable

[Andrew C. Morrow]

Hi -

The current implementation of InstallVersionedLib in SCons 3.0.1 does not
consult the SONAME variable from the target that is being installed.

This means that if you have a SharedLibrary which sets both SONAME and
SHLIBVERSION, the resulting installed symlinks are not correct:

env = Environment()

libDS = env.SharedLibrary(
target='libds',
source=[
'libds.cpp',
],
SHLIBVERSION="1.2.3",
SONAME="libds.so.10",
)

env.InstallVersionedLib(
target='install/lib',
source = libDS,
)

$ scons
g++ -o libds.os -c -fPIC libds.cpp
g++ -o libds.so.1.2.3 -shared -Wl,-Bsymbolic -Wl,-soname=libds.so.10
libds.os
Create symlinks for: 'libds.so.1.2.3': '*libds.so.1*'->'libds.so.1.2.3',
'libds.so'->'libds.so.1.2.3'
Install file: "libds.so.1.2.3" as "install/lib/libds.so.1.2.3"

The soname symlink here should be 'libds.so.*10*'->'libds.so.1.2.3',

I think the default behavior of InstallVersionedLib, where it assumes the
major-est version number of the library version sets the ABI, seems pretty
reasonable. But I think there are legitimate cases where the ABI version
may need to be set independently, and InstallVersionedLib should probably
respect that when it happens.

Two notes to go along with that:

- The default of linking with -Bsymbolic (set in the gnulink tool) seems
questionable to me. That choice isn't always correct, and it should be left
to the user to decide.

- It would be nice if there were a way for SONAME to not need to reiterate
the full library name with the SHLIBPREFIX and SHLIBSUFFIX. Perhaps we need
a new variable SOVERSION which takes a number (or string for macOS dylibs
that like to use versions like 'b'), and interpolates it into an
appropriate target specific file name.

Thanks,
Andrew

[Andrew C. Morrow]

Any thoughts on this? Should I open an issue on the GitHub project?

Post by Andrew C. Morrow
Hi -
The current implementation of InstallVersionedLib in SCons 3.0.1 does not
consult the SONAME variable from the target that is being installed.
This means that if you have a SharedLibrary which sets both SONAME and
env = Environment()
libDS = env.SharedLibrary(
target='libds',
source=[
'libds.cpp',
],
SHLIBVERSION="1.2.3",
SONAME="libds.so.10",
)
env.InstallVersionedLib(
target='install/lib',
source = libDS,
)
$ scons
g++ -o libds.os -c -fPIC libds.cpp
g++ -o libds.so.1.2.3 -shared -Wl,-Bsymbolic -Wl,-soname=libds.so.10
libds.os
Create symlinks for: 'libds.so.1.2.3': '*libds.so.1*'->'libds.so.1.2.3',
'libds.so'->'libds.so.1.2.3'
Install file: "libds.so.1.2.3" as "install/lib/libds.so.1.2.3"
The soname symlink here should be 'libds.so.*10*'->'libds.so.1.2.3',
I think the default behavior of InstallVersionedLib, where it assumes the
major-est version number of the library version sets the ABI, seems pretty
reasonable. But I think there are legitimate cases where the ABI version
may need to be set independently, and InstallVersionedLib should probably
respect that when it happens.
- The default of linking with -Bsymbolic (set in the gnulink tool) seems
questionable to me. That choice isn't always correct, and it should be left
to the user to decide.
- It would be nice if there were a way for SONAME to not need to
reiterate the full library name with the SHLIBPREFIX and SHLIBSUFFIX.
Perhaps we need a new variable SOVERSION which takes a number (or string
for macOS dylibs that like to use versions like 'b'), and interpolates it
into an appropriate target specific file name.
Thanks,
Andrew

[Bill Deegan]

Andrew,

Go ahead and open an issue.

Thanks,
Bill

Post by Andrew C. Morrow
Any thoughts on this? Should I open an issue on the GitHub project?
On Fri, Nov 16, 2018 at 11:36 AM Andrew C. Morrow <

Post by Andrew C. Morrow
Hi -
The current implementation of InstallVersionedLib in SCons 3.0.1 does
not consult the SONAME variable from the target that is being installed.
This means that if you have a SharedLibrary which sets both SONAME and
env = Environment()
libDS = env.SharedLibrary(
target='libds',
source=[
'libds.cpp',
],
SHLIBVERSION="1.2.3",
SONAME="libds.so.10",
)
env.InstallVersionedLib(
target='install/lib',
source = libDS,
)
$ scons
g++ -o libds.os -c -fPIC libds.cpp
g++ -o libds.so.1.2.3 -shared -Wl,-Bsymbolic -Wl,-soname=libds.so.10
libds.os
Create symlinks for: 'libds.so.1.2.3': '*libds.so.1*'->'libds.so.1.2.3',
'libds.so'->'libds.so.1.2.3'
Install file: "libds.so.1.2.3" as "install/lib/libds.so.1.2.3"
The soname symlink here should be 'libds.so.*10*'->'libds.so.1.2.3',
I think the default behavior of InstallVersionedLib, where it assumes
the major-est version number of the library version sets the ABI, seems
pretty reasonable. But I think there are legitimate cases where the ABI
version may need to be set independently, and InstallVersionedLib should
probably respect that when it happens.
- The default of linking with -Bsymbolic (set in the gnulink tool) seems
questionable to me. That choice isn't always correct, and it should be left
to the user to decide.
- It would be nice if there were a way for SONAME to not need to
reiterate the full library name with the SHLIBPREFIX and SHLIBSUFFIX.
Perhaps we need a new variable SOVERSION which takes a number (or string
for macOS dylibs that like to use versions like 'b'), and interpolates it
into an appropriate target specific file name.
Thanks,
Andrew
_______________________________________________

Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users