The gnulink tool probably should not set -Bsymbolic

[acmorrow]

• Link to SCons Users thread discussing your issue.

• Mentioned but not discussed here: https://pairlist4.pair.net/pipermail/scons-users/2018-November/007441.html

• Version of SCons
  3.x, not sure how much older.

Right now the 'gnulink' tool unconditionally adds -Bsymbolic to the SHLIBVERSIONFLAGS variable. That probably isn't a good idea: the choice of whether to build a dynamic library with internal references as symbolic should probably be left to the developer.

[acmorrow]

Some additional background on this: https://software.intel.com/en-us/articles/performance-tools-for-software-developers-bsymbolic-can-cause-dangerous-side-effects

[mwichmann]

I would tend to agree.

[garyo]

Yes, I agree too. Not appropriate for default setting. It will be a breaking change, however.

[acmorrow]

@garyo - Agree it is a breaking change, but probably one for the better. Those who wanted -Bsymbolic were probably already asking for it explicitly by adding it to SHLINKFLAGS, because why would they expect it to magically arrive? Those who don't want it or don't know what it is are probably unaware of the risks/consequences/subtleties and would be better off without it being auto-added. I propose making the breaking change and adding a release note.

[bdbaddog]

We probably need to figure out how the SCons Deprecation cycle applies to such a change.
Likely we'd announce we're going to do it in next release, and then make the change in the following release?

see: https://github.com/SCons/scons/wiki/DeprecationCycle

[garyo]

Yes, that's the proper SCons process for making a breaking change. In this case the change is pretty minor, and makes sense, but it still would (in some edge cases, which we can discuss the importance of) violate the principle of not breaking builds in a minor release.

The workaround in either direction is pretty simple: users can reset SHLINKFLAGS to omit -Bsymbolic today, and if we remove it, it's easy for users to add.

We'd certainly need to announce that it's coming before we do it, and follow the parts of the deprecation cycle that make sense (not all of that applies in this case).

[acmorrow]

Just to add my thoughts. I consider this a bug, not a user breaking change. I don't think a deprecation cycle is necessary. That flag has dangerous side effects and SCons shouldn't be setting link policy like that.

[acmorrow]

My thought is that we should, as noted above, immediately remove -Bsymbolic without a deprecation cycle. We can include the following language or something similar in the changelog or release notes:

The -Bsymbolic flag has been removed from SHLIBVERSIONFLAGS in the gnulink Tool. Versioned shared libraries will no longer have this flag applied to the link step by default. Use of this flag is unsafe in C++ projects because it leads to ODR violations and can interfere with proper behavior of new/delete. A build system should not, by default, introduce the potential for undefined behavior. Projects which were relying on automatic application of -Bsymbolic in versioned shared libraries must now explicitly add the -Bsymbolic flag to SHLIBVERSIONFLAGS or SHLIBFLAGS` in their project setup.

[garyo]

I agree it's dangerous and should be removed (I was using it years ago but we stopped once better alternatives became available). People are probably using SCons without noticing that it adds that.

But we can't just spring it on people in a minor release without warning. Maybe it would be enough to do the following: 1. announce on users/devs lists, 2. announce on discord, 3. highlight it in release notes (and why it's not following the usual depr cycle) per @acmorrow's note above. That's my opinion anyway...

[bdbaddog]

@garyo - sounds reasonable. Done.

[mwichmann]

This isn't even a new issue... https://pairlist4.pair.net/pipermail/scons-users/2016-May/004893.html. Looks like some effort was made to mitigate this already in 3.0.0 (see CHANGES.txt).

[bdbaddog]

Fixed in #3621