[Scons-users] Setting macOS shared library versioning information with scons

Bill Deegan bill at baddogconsulting.com
Mon Jul 16 22:41:29 EDT 2018


I added onto the macports bug.

Here's my question:

Given SHLIBVERSION = 1.2.3

What would you expect/want the arguments to -current_version and
-compatibility_version to be?

Both to SHLIBVERSION (1.2.3) or compatibility_version to 1.2?

(SCons developer here)


On Wed, May 9, 2018 at 1:30 PM, Ryan Schmidt <scons at ryandesign.com> wrote:

> On May 8, 2018, at 13:02, Bill Deegan wrote:
>
> > On Tue, May 8, 2018 at 12:40 PM, Ryan Schmidt wrote:
> >
> >> I'm a developer with the MacPorts package management system.
> >>
> >> We noticed that after updating our scons port to 2.4.1, serf's shared
> library was built incorrectly, in that its current version and
> compatibility version were no longer being set. Here is our bug report
> about this:
> >>
> >> https://trac.macports.org/ticket/50854
> >>
> >> It seems that scons's shared library generation code was refactored in
> 2.4.1, and in the process, the code that sets the -current_version and
> -compatibility_version flags was removed. Was this regression intentional,
> and if so, how are projects that use scons to build shared libraries on
> macOS now supposed to set library version information? Should they manually
> specify -current_version and -compatibility_version?
> >>
> >> I realize scons 2.4.1 was released 2.5 years ago, but the problem
> remains in scons 3.0.1. The developers of serf are preparing to release
> serf 1.4.0, and I'm trying to help them ensure that they finally fix the
> shared library versioning issue on their end, hopefully in a way that's
> compatible with both current and future versions of scons.
> >
> > Looks like (as you're pointing out), the updates to support shared
> library versioning on other platforms broke mac?
> >
> > Can you point me to the serf logic where they build the shared library
> using SCons?
> > (So I can see how they're calling SharedLibrary(),etc.)
> >
> > Certainly that's an indicator that however it was being used our tests
> weren't covering that usage to ensure it didn't get broken.
>
> Here's serf's SConstruct:
>
> https://svn.apache.org/repos/asf/serf/trunk/SConstruct
>
> It is doing this:
>
>
> # This version string is used in the dynamic library name, and for Mac OS
> X also
> # for the compatibility_version option in the .dylib.
> soversion = '%d.%d.%d' % (MAJOR, MINOR, 0)
> libversion = '%d.%d.%d' % (MAJOR, MINOR, PATCH)
> if sys.platform != 'sunos5':
>   env['SHLIBVERSION'] = soversion
>
>
> install_shared = env.InstallVersionedLib(libdir, lib_shared)
>
>
> The CHANGES.txt entry for scons 2.4.1 states:
>
> - InstallVersionedLib() doesn't use SHLIBVERSION anymore.
>
> So the change sounds deliberate. But it doesn't explain why.
>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20180716/c4704658/attachment.html>


More information about the Scons-users mailing list