- Package:
- g++
- Source:
- gcc-defaults
- Description:
- GNU C++ compiler
- Submitter:
- Jeffrey Walton
- Date:
- 2020-11-21 18:33:02 UTC
- Severity:
- normal
Package: g++ Control: submitter -1 Jeffrey Walton <noloader@gmail.com> Turning this into a g++ bug report.
clang can't handle abi tags (i.e. can't link to new-ABI code even if you aren't trying to mix it with old-ABI code): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797917 https://llvm.org/bugs/show_bug.cgi?id=23529
clang can't handle abi tags (i.e. can't link to new-ABI code even if you aren't trying to mix it with old-ABI code): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797917 https://llvm.org/bugs/show_bug.cgi?id=23529
Yes, correct. That's why we are asking that -Wabi-tag be enabled for GCC and Clang, similar to the way other options are pushed/enabled, like _FORTIFY_SOURCES (unless the user specifies -Wno-abi-tag). In our case, we are a library (Crypto++, https://www.cryptopp.com/), and we don't control how the library is compiled by a distro or how users compile their programs. A distro compiling the library is always OK; its the user and their choices that are creating the issues. The -Wabi-tag warning will serve to alert the user they've wandered into a problem area based on their choices. Jeff
Yes, correct. That's why we are asking that -Wabi-tag be enabled for GCC and Clang, similar to the way other options are pushed/enabled, like _FORTIFY_SOURCES (unless the user specifies -Wno-abi-tag). In our case, we are a library (Crypto++, https://www.cryptopp.com/), and we don't control how the library is compiled by a distro or how users compile their programs. A distro compiling the library is always OK; its the user and their choices that are creating the issues. The -Wabi-tag warning will serve to alert the user they've wandered into a problem area based on their choices. Jeff
Yes, correct. That's why we are asking that -Wabi-tag be enabled for GCC and Clang, similar to the way other options are pushed/enabled, like _FORTIFY_SOURCES (unless the user specifies -Wno-abi-tag). In our case, we are a library (Crypto++, https://www.cryptopp.com/), and we don't control how the library is compiled by a distro or how users compile their programs. A distro compiling the library is always OK; its the user and their choices that are creating the issues. The -Wabi-tag warning will serve to alert the user they've wandered into a problem area based on their choices. Jeff
If you want to change that, that change should be made in dpkg-buildflags.
[Removing debian-devel from Cc]
From the original report:
only affects the warnings emitted when Debian packages are built, whereas
a change in gcc would also affect the warnings emitted when upstream
software is built on Debian.
Jeffrey: who is "us", and does the problematic link step involve libraries
from Debian packages, libraries you have previously compiled yourself, or
both? During which compilation/linking step would you have expected to see
this warning?
It would be useful to have the steps to reproduce the issue you are reporting,
in terms something like this:
- compile libfoo with xyz compiler
- link it to Debian's packaged libbar
- compile and link a program that uses libfoo and libbar with uvw compiler
- expected result: linking the program warns that libbar's version of Bar
returns a std::string but libfoo expects a std::__cxx11::string
- actual result: (paste a typical linker error)
- the expected warning can be achieved by configuring xyz compiler with
-Wabi-tag
(but I'm probably getting the sequence of events totally wrong so please
specify what is actually going on)
S
When Debian builds its packages, I don't believe it {was|is} an issue.
The problem is a confluence, and there's no single point of failure
per se. It appears when a user builds their userland programs using
Debian libraries *and* the user's compiler and/or options are
different than when Debian built the library.
"We" is the Crypto++ project (https://www.cryptopp.com/). Crypto++ is
a C++ class library of cryptographic schemes and algorithms created by
a fellow named Wei Dai.
Yes (but its not a hard yes).
We (Crypto++) do not maintain Debian's Crypto++ library. We are
fortunate that László Böszörményi maintains it for us since it
relieves us from the task. We are also fortunate that László is a
friend of the project, and he works closely with us to ensure the
library is trouble free when integrating with the Debian ecosystem. A
number of bug fixes are credited to him. He also mentors us in Debian
ways to ensure a trouble free experience for both maintainers and
user. (Sorry about the shameless plug for László).
We believe the issue would surface regardless of who is building the
library under Debian when different compilers and or options are used
by the user. László could build it, we could build it, or the user
could build it from sources.
The problem should not be limited to Crypto++. I believe PCRE has a
C++ component, and it should experience the problem too *if* the user
selects a different compiler and/or options. You should be able to
<insert favorite C++ library> and duplicate the issue the user selects
a different compiler and/or options.
Here are the cases I would expect to see the warning. Below, "library"
means the Crypto++ library; and "program" means the program build by
the user linking to the library. "By Debian" implies the GCC compiler
with _GLIBCXX_USE_CXX11_ABI because that's the "out of the box"
configuration.
(1) library supplied by Debian, program built by user using different
options (say -std=c++03)
(2) library supplied by Debian, program built by user using different
compiler (say Clang)
(3) library built by user using GCC with Debian settings, program
built by user using different options (say -std=c++03)
(4) library built by user using GCC with Debian settings, program
built by user using different compiler (say Clang)
(5) library built by user using Clang, program built by user using
Debian's GCC with _GLIBCXX_USE_CXX11_ABI
For completeness, here's what works as excepted. It avoids the
"different compiler and/or options" that's causing the pain point at
link time:
(6) library supplied by Debian, program built by user using GCC with
Debian settings
Let me follow up with some real result from a minimal test case.
Not at all. Its a confluence of events, and that's what is making it
tricky to nail down.
I can't really offer anything useful at the moment because I don't have a clear understanding of what's going on. Sorry about that. Here are the three references I am aware. The Red Hat one made my radar tonight: * "GCC5 and the C++11 ABI", http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ * "Dual ABIs", http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html * "The Case of GCC-5.1 and the Two C++ ABIs", http://allanmcrae.com/2015/06/the-case-of-gcc-5-1-and-the-two-c-abis/ I'm also aware that GCC appears to lack documentation on -Wabi-tag (cf., http://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Warning-Options.html#Warning-Options.). I *thought* -Wabi-tag could be used to detect the differences between ABIs when compiling and linking. That would, in turn alert the user, but I'm not sure that was correct. For example, the following warns of an ABI problem even though C++03 does not have this problem: $ cat test.cxx #include <string> std::string foo __attribute__ ((visibility ("default"))); std::string bar __attribute__ ((visibility ("default"))); And: $ g++ -g3 -O2 -Wabi-tag -std=c++03 -shared test.cxx -o test.so test.cxx:3:13: warning: ‘foo’ inherits the "cxx11" ABI tag that ‘std::__cxx11::string {aka std::__cxx11::basic_string<char>}’ (used in its type) has [-Wabi-tag] std::string foo __attribute__ ((visibility ("default"))); ^ In file included from /usr/include/c++/5/string:52:0, from test.cxx:1: /usr/include/c++/5/bits/basic_string.h:71:11: note: ‘std::__cxx11::string {aka std::__cxx11::basic_string<char>}’ declared here class basic_string ^ test.cxx:4:13: warning: ‘bar’ inherits the "cxx11" ABI tag that ‘std::__cxx11::string {aka std::__cxx11::basic_string<char>}’ (used in its type) has [-Wabi-tag] std::string bar __attribute__ ((visibility ("default"))); ^ In file included from /usr/include/c++/5/string:52:0, from test.cxx:1: /usr/include/c++/5/bits/basic_string.h:71:11: note: ‘std::__cxx11::string {aka std::__cxx11::basic_string<char>}’ declared here class basic_string ^ Then, I thought I could side step the problem by building a library with both old and new symbols that coexist as discussed in the Red Hat blog. But I can't seem to get a definitive answer on what it means to coexist, and how to do it. I asked a couple of questions on the GCC Help mailing list. They may help you more than they helped me: * "Why does -Wabi-tag complain when -std=c++03?", https://gcc.gnu.org/ml/gcc-help/2016-03/msg00123.html * "How to provide coexisting std::string's (with and without abi:cxx11) in GCC 5.1 and above?", https://gcc.gnu.org/ml/gcc-help/2016-03/msg00118.html "What a fine mess we're in" comes to mind right about now... Sorry again about not being able to help. Jeff
Je vous ai invité à remplir le formulaire suivant : Formulaire sans titre Pour remplir ce formulaire, consultez : https://docs.google.com/forms/d/e/1FAIpQLSfkXJFwmAuGwoHhx2QwLuILIPlOXu3n3BB47pMKhn3GTxlgkA/viewform?vc=0&c=0&w=1&flr=0&usp=mail_form_link Hi Dear, I was just going through the Internet search when I found your email address, I want to make a new and special friend, so I decided to contact you to see how we can make it work out if we can. Please I wish you will have the desire with me so that we can get to know each other better and see what happens in future. My name is Lisa Williams, I am an American, but presently I live in the UK, I will be glad to see your reply for us to know each other better to exchange pictures and details about us. Yours Lisa Google Forms vous permet de créer des enquêtes et d'en analyser les résultats.