scons incorrectly builds projects, serf1 unexpectedly changed dylib versions with just a revbump for OpenSSL

[jeremyhu (Jeremy Huddleston Sequoia)]

serf1 was recently revbumped to rebuild against an updated OpenSSL. In doing so, other ports on my system broke because the dylib version of libserf changed:

/tmp/r1 $ tar xjf .../serf1-1.3.4_1+universal.darwin_15.i386-x86_64.tbz2 

/tmp/r1 $ otool -L opt/local/lib/libserf-1.dylib 
opt/local/lib/libserf-1.dylib:
	/opt/local/lib/libserf-1.dylib (compatibility version 0.0.0, current version 0.0.0)
	...

/tmp/r0 $ tar xjf .../serf1-1.3.4_0+universal.darwin_15.i386-x86_64.tbz2 

/tmp/r0 $ otool -L opt/local/lib/libserf-1.dylib 
opt/local/lib/libserf-1.dylib:
	/opt/local/lib/libserf-1.dylib (compatibility version 1.3.4, current version 1.3.4)
	...

---

Timestamps of when they were built:

-rw-r--r--   1 root admin 424529 Oct 17 00:33 serf1-1.3.4_0+universal.darwin_15.i386-x86_64.tbz2
-rw-r--r--   1 root admin 410869 Mar 10 11:09 serf1-1.3.4_1+universal.darwin_15.i386-x86_64.tbz2

The only change to the serf1 port since Oct 17 was the revbump.

However, scons was recently updated from 2.3.4 to 2.4.1, and that certainly seems like the likley cause. I'll give a try reverting it.

[ryandesign (Ryan Carsten Schmidt)]

Yuck.

From the scons 2.4.1 CHANGES.txt file:

  From Paweł Tomulik:
    - Reimplemented versioning for shared libraries, with the following effects
    - Fixed tigris issues #3001, #3006.
    - Fixed several other issues not reported to tigris, including:
      issues with versioned libraries in subdirectories with tricky names,
      issues with versioned libraries and variant directories,
      issue with soname not being injected to library when using D linkers,
    - Switched to direct symlinks instead of daisy-chained ones -- soname and
      development symlinks point directly to the versioned shared library now),
      for rationale see:
      https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
      https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages
      https://bitbucket.org/scons/scons/pull-requests/247/new-versioned-libraries-gnulink-cyglink/diff#comment-10063929
    - New construction variables to allow override default behavior: SONAME,
      SHLIBVERSIONFLAGS, _SHLIBVERSIONFLAGS, SHLIBNOVERSIONSYMLINKS,
      LDMODULEVERSION, LDMODULEVERSIONFLAGS, _LDMODULEVERSIONFLAGS,
      LDMODULENOVERSIONSYMLINKS.
    - Changed logic used to configure the versioning machinery from
      platform-centric to linker-oriented.
    - The SHLIBVERSION/LDMODULEVERSION variables are no longer validated by
      SCons (more freedom to users).
    - InstallVersionedLib() doesn't use SHLIBVERSION anymore.
    - Enchanced docs for the library versioning stuff.
    - New tests for versioned libraries.
    - Library versioning is currently implemented for the following linker
      tools: 'cyglink', 'gnulink', 'sunlink'.
    - Fix to swig tool - pick-up 'swig', 'swig3.0' and 'swig2.0' (in order).
    - Fix to swig tool - respect env['SWIG'] provided by user.

[jeremyhu (Jeremy Huddleston Sequoia)]

Yep, definitely scons. Rolling back to 2.3.4 produced a libserf with the same versioning.

[ryandesign (Ryan Carsten Schmidt)]

I did ​report this problem to the developers of scons. A developer responded to commiserate, but nothing has been done to fix it.

[ryandesign (Ryan Carsten Schmidt)]

diffing the scons 2.4.0 and 2.4.1 code, the code that sets -current_version and -compatibility_version was removed in a code refactor. It's not clear to me whether that was intentional or not.

​Here's a patch from the developers of serf that fixes the problem in serf. But that does nothing to fix any other projects that use scons.

​I reported the scons problem to the developers; let's wait a little while and see if they think this is something that should be fixed in scons or individually in serf and other ports.

[bdbaddog]

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)

[jeremyhu (Jeremy Huddleston Sequoia)]

-current_version should likely be 1.2.3 -compatibility_version should likely be 1.0 (if you are compatible back to 1.0) or to 1.2 (if you are compatible back to 1.2).

IE, if you removed symbols in 1.2 that were in 1.0 (and thus are not binary compatible with clients that expect 1.0 compatible ABI), then you should set the compatibility version to 1.2.

[jeremyhu (Jeremy Huddleston Sequoia)]

Most well behaved libraries (IE: system libraries) set -compatibility_version to just 1.0 and continue to rev -current_version over time such that they have binary compatibility with all older clients.

You should only bump the compatibility_version if you break ABI compatibility with older clients.

[bdbaddog]

Perhaps a SHLIBCOMPATVERSION should be used and if not defined default to 1.0?

[bdbaddog]

We're going to try to get this in the next release of SCons. Please take a look at the bug with spec.

​https://github.com/SCons/scons/issues/3241

I'll be working on this right now. So if you have feedback, please make it fairly quickly.

[bdbaddog]

There's a Pull Request in review on SCons for this issue. If you have any feedback, please add comments there.

​https://github.com/SCons/scons/pull/3251

[ryandesign (Ryan Carsten Schmidt)]

The PR was merged and included in scons 3.0.2. MacPorts updated from 3.0.1 to 3.0.3 in [3918578c64697923330cd1eabf59c10ca19f1c73/macports-ports].