> On Wed, 23 Mar 2016 at 13:31:32 +0100, Matthias Klose wrote:
>> If you want to change that, that change should be made in dpkg-buildflags.
>
> From the original report:
>
>> >On Tue, 22 Mar 2016 at 10:34:29 -0400, Jeffrey Walton wrote:
>> >>It appears Debian built the library with GCC, and GCC used
>> >>_GLIBCXX_USE_CXX11_ABI. The user then compiled with Clang and caught a
>> >>link error. The tools did not warn him about the problems, so the
>> >>report trickled downhill to us.
>
> it isn't clear to me whether that would have helped: dpkg-buildflags
> 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.
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.
> Jeffrey: who is "us",
"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.
> and does the problematic link step involve libraries
> from Debian packages, libraries you have previously compiled yourself, or
> both?
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.
> During which compilation/linking step would you have expected to see
> this warning?
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
> - compile and link a program that uses libfoo and libbar with uvw compiler
Let me follow up with some real result from a minimal test case.
> (but I'm probably getting the sequence of events totally wrong so please
> specify what is actually going on)
Not at all. Its a confluence of events, and that's what is making it
tricky to nail down.
-Wabi-tag is somewhat of a mystery at the moment. Though introduced in
GCC 5.1, its still not documented at 5.3 (cf.,
http://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Warning-Options.html#Warning-Options).
According to
http://allanmcrae.com/2015/06/the-case-of-gcc-5-1-and-the-two-c-abis/,
its intended to catch the mixing and matching that's causing the pain.
Jeff
