-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CondFormats/Common: remove intrusive macros breaking libstdc++ #11950
CondFormats/Common: remove intrusive macros breaking libstdc++ #11950
Conversation
We cannot redefine 'private' and 'protected' keywords via macros to e.g. 'public'. This is extremely intrusive and breaks encapsulation. This does not work anymore with new libstdc++ libraries, because foward delcaration of struct is implicitly private and then implementation is under explicit private clause. Redefining 'private' only change one of them thus creating compile-time errors in sstream. Details in PR65899 (GCC BZ). It's WONTFIX. Such cleanups are required for GCC 5 and above. Signed-off-by: David Abdurachmanov <[email protected]>
A new Pull Request was created by @davidlt for CMSSW_7_6_X. CondFormats/Common: remove intrusive macros breaking libstdc++ It involves the following packages: CondFormats/Common @diguida, @cerminar, @cmsbuild, @franzoni, @ggovi, @mmusich can you please review it and eventually sign? Thanks. |
Missed a few, will update. |
I was wrong, this is good enough. |
Launched the tests. |
Closed for CMSSW_7_6_X, look at PR for CMSSW_8_0_X. |
We cannot redefine 'private' and 'protected' keywords via macros to e.g.
'public'. This is extremely intrusive and breaks encapsulation.
This does not work anymore with new libstdc++ libraries, because foward
delcaration of struct is implicitly private and then implementation is
under explicit private clause. Redefining 'private' only change one of
them thus creating compile-time errors in sstream.
Details in PR65899 (GCC BZ). It's WONTFIX.
Such cleanups are required for GCC 5 and above.
Signed-off-by: David Abdurachmanov [email protected]