[opensuse-packaging] How to avoid more undefined symbols?
Hello, I came along two issues recently where symbols from C++ class libraries which were provided by specific software package versions did not fit together temporarily. Combinations: * libmodman1 / libproxy1 https://bugzilla.opensuse.org/show_bug.cgi?id=937157#c5 * yast2-core / libyui6 https://bugzilla.suse.com/show_bug.cgi?id=937665#c2 How are the chances that such name mangling changes because of application binary interface adjustments will trigger appropriate updates automatically? Do dependency descriptions need any more fine-tuning for corresponding RPM specifications? Regards, Markus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
В Fri, 10 Jul 2015 21:48:19 +0200 SF Markus Elfring <elfring@users.sourceforge.net> пишет:
Hello,
I came along two issues recently where symbols from C++ class libraries which were provided by specific software package versions did not fit together temporarily.
Combinations: * libmodman1 / libproxy1 https://bugzilla.opensuse.org/show_bug.cgi?id=937157#c5
* yast2-core / libyui6 https://bugzilla.suse.com/show_bug.cgi?id=937665#c2
How are the chances that such name mangling changes because of application binary interface adjustments will trigger appropriate updates automatically?
Do dependency descriptions need any more fine-tuning for corresponding RPM specifications?
I see three possible ways to handle such transition. 1. Explicitly list each symbol in Requires and Provides. 2. Bump library major version every time it happens. 3. Make mangling style part of library Provides and Requires. The first is unlikely feasible. The second has the problem that there is no changes in package sources or APIs - the results become incompatible during build. So we cannot simply bump library major in SRPM. The third one sounds feasible, something like Requires: liby2.so.4(stdc++11) assuming it is possible to detect how library was built. I do not know if this information is stored in library though. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
3. Make mangling style part of library Provides and Requires.
How are the chances to reduce surprises from name mangling by such an approach? How often were similar attempts discussed already?
The third one sounds feasible, something like
Requires: liby2.so.4(stdc++11)
assuming it is possible to detect how library was built.
Would you like to introduce dedicated variables?
I do not know if this information is stored in library though.
It will finally land in special function names, won't it? But I guess that it might be inappropriate to consider another demangle step in the software build process at the end. Regards, Markus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
SF Markus Elfring <elfring@users.sourceforge.net> writes:
3. Make mangling style part of library Provides and Requires.
How are the chances to reduce surprises from name mangling by such an approach? How often were similar attempts discussed already?
The third one sounds feasible, something like
Requires: liby2.so.4(stdc++11)
assuming it is possible to detect how library was built.
Would you like to introduce dedicated variables?
I do not know if this information is stored in library though.
It will finally land in special function names, won't it?
It will show up in the demangled symbol as "[abi:cxx11]". $ c++filt _ZN6LHAPDF5pathsB5cxx11Ev LHAPDF::paths[abi:cxx11]() Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Mon, 13 Jul 2015, Andreas Schwab wrote:
I do not know if this information is stored in library though.
It will finally land in special function names, won't it?
It will show up in the demangled symbol as "[abi:cxx11]".
$ c++filt _ZN6LHAPDF5pathsB5cxx11Ev LHAPDF::paths[abi:cxx11]()
Not for all of them: $ c++filt \ _ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb libmodman::module_manager::load_dir(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool) (That's the symbol Markus initially stumbled over) Here the only indication is the __cxx11 namespace before basic_string, which is a good hint (but not all __cxx11 occurrences mean an ABI change). Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
3. Make mangling style part of library Provides and Requires.
Are there any RPM specifications available which reuse such information? Now I see that there is another software development to consider if I would like install specific software in parallel to compare effects from application binary interface changes. Does parallel installation only work for such an use case if the package name will be adjusted accordingly? Would other developers and system testers also like to choose the provided ABI more directly? Regards, Markus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
3. Make mangling style part of library Provides and Requires.
How often do you need to pack such information around software requirements into corresponding package names so that parallel installation will work properly? Regards, Markus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (4)
-
Andreas Schwab -
Andrei Borzenkov -
Michael Matz -
SF Markus Elfring