Re: Missing shared library version information with scons 2.4.1 and later

[Ryan Schmidt <se...@ryandesign.com>]

On Sep 27, 2017, at 16:24, Ryan Schmidt wrote:

> Hello,
> 
> I'm a developer with the MacPorts package management system.
> 
> When built with scons 2.3, the libserf dynamic library on macOS has current_version and compatibility_version information recorded in it, as it should:
> 
> $ otool -L opt/local/lib/libserf-1.dylib | head -n 2
> opt/local/lib/libserf-1.dylib:
> 	/opt/local/lib/libserf-1.dylib (compatibility version 1.3.4, current version 1.3.4)
> 
> When built with scons 2.4.1 or later, it does not:
> 
> $ otool -L opt/local/lib/libserf-1.dylib | head -n 2
> opt/local/lib/libserf-1.dylib:
> 	/opt/local/lib/libserf-1.dylib (compatibility version 0.0.0, current version 0.0.0)
> 
> We were quite surprised to discover this had occurred, after we rebuilt libserf due to an openssl upgrade, coincidentally after scons had been updated. Everything else that used libserf then broke, complaining that it was trying to load an older version of the library than it had been built with.
> 
> It is mentioned in the scons change log that InstallVersionedLib, which serf uses, doesn't honor SHLIBVERSION anymore:
> 
> https://github.com/SConsProject/scons/blob/rel_2.4.1/src/CHANGES.txt#L39
> 
> I have a fiery passionate hatred for scons (and refer you to the "Please consider dropping scons" and "I now officially declare myself completely beaten by scons" threads, and also invite you to ponder the notion that the developers of scons thought it acceptable to break backward compatibility in this manner in a bugfix release) and don't wish to try to figure out how to fix this. Do you have any ideas?
> 
> Here is the MacPorts bug report:
> 
> https://trac.macports.org/ticket/50854


Has anybody had any thoughts on this issue?

Is nobody else experiencing this problem? Am I doing something wrong?

Re: Missing shared library version information with scons 2.4.1 and later

[Greg Stein <gs...@gmail.com>]

I work on a mac also, so I can try this out with those different scons
versions.

And I agree with you: this kind of change in scons is ridiculous. Just...
wow.

Maybe we really should look to another system. I believe several people in
the community have pushed for CMake.

Note: I've done the multiple-build-system maintenance for serf before. It
sucks. ... I believe any solution should work for Windows + unix-ish
systems, or it's a non-starter. I dunno if some of Google's build tools are
multi-platform, but they've pushed out a number of tools over the years.

Right now, we're in a better spot than our multi-system before. But yeah:
maybe we can do better, again. Especially if those scons yahoos keep up
this nonsense.

Cheers,
-g


On Mon, Oct 9, 2017 at 1:57 AM, Ryan Schmidt <se...@ryandesign.com> wrote:

> On Sep 27, 2017, at 16:24, Ryan Schmidt wrote:
>
> > Hello,
> >
> > I'm a developer with the MacPorts package management system.
> >
> > When built with scons 2.3, the libserf dynamic library on macOS has
> current_version and compatibility_version information recorded in it, as it
> should:
> >
> > $ otool -L opt/local/lib/libserf-1.dylib | head -n 2
> > opt/local/lib/libserf-1.dylib:
> >       /opt/local/lib/libserf-1.dylib (compatibility version 1.3.4,
> current version 1.3.4)
> >
> > When built with scons 2.4.1 or later, it does not:
> >
> > $ otool -L opt/local/lib/libserf-1.dylib | head -n 2
> > opt/local/lib/libserf-1.dylib:
> >       /opt/local/lib/libserf-1.dylib (compatibility version 0.0.0,
> current version 0.0.0)
> >
> > We were quite surprised to discover this had occurred, after we rebuilt
> libserf due to an openssl upgrade, coincidentally after scons had been
> updated. Everything else that used libserf then broke, complaining that it
> was trying to load an older version of the library than it had been built
> with.
> >
> > It is mentioned in the scons change log that InstallVersionedLib, which
> serf uses, doesn't honor SHLIBVERSION anymore:
> >
> > https://github.com/SConsProject/scons/blob/rel_2.4.1/src/CHANGES.txt#L39
> >
> > I have a fiery passionate hatred for scons (and refer you to the "Please
> consider dropping scons" and "I now officially declare myself completely
> beaten by scons" threads, and also invite you to ponder the notion that the
> developers of scons thought it acceptable to break backward compatibility
> in this manner in a bugfix release) and don't wish to try to figure out how
> to fix this. Do you have any ideas?
> >
> > Here is the MacPorts bug report:
> >
> > https://trac.macports.org/ticket/50854
>
>
> Has anybody had any thoughts on this issue?
>
> Is nobody else experiencing this problem? Am I doing something wrong?
>
>