Opened 3 years ago

Last modified 3 months ago

#50854 new defect

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

Reported by: jeremyhu (Jeremy Huddleston Sequoia) Owned by: ryandesign (Ryan Schmidt)
Priority: Normal Milestone:
Component: ports Version: 2.3.4
Keywords: Cc:
Port: scons

Description (last modified by 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 (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 (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.

Change History (12)

comment:1 Changed 3 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Description: modified (diff)

comment:2 Changed 3 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Description: modified (diff)

comment:3 Changed 3 years ago by ryandesign (Ryan Schmidt)


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:
    - New construction variables to allow override default behavior: SONAME,
    - 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.

comment:4 Changed 3 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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

comment:5 Changed 11 months ago by ryandesign (Ryan Schmidt)

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

Last edited 11 months ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:6 Changed 11 months ago by ryandesign (Ryan 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.

comment:7 Changed 8 months ago by 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)

comment:8 Changed 8 months ago by 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.

comment:9 Changed 8 months ago by 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.

comment:10 Changed 8 months ago by bdbaddog

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

comment:11 Changed 4 months ago by bdbaddog

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

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

comment:12 Changed 3 months ago by bdbaddog

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

Note: See TracTickets for help on using tickets.