[Bug 1000508] Re: PendingMessages member variable of APT's GlobalError class initializes as "true" with -std=c++11

Matthias Klose doko at ubuntu.com
Thu Jun 14 10:06:11 UTC 2012


this is a change in GCC 4.7's c++11 mode (see
http://gcc.gnu.org/wiki/Cxx11AbiCompatibility).  There is no "easy"
solution. c++0x/c++11 mode is still marked experimental in GCC, so
better don't use it in production code. so either:

 - build qapt in c++98 mode
 - rebuilding libapt-pkg in c++11 mode isn't a solution, because it will break binaries,
    which are built in c++98 mode.
 - build libapt-pkg both in c++98 and c++11 mode with a different soname. This approach
   doesn't scale for the whole distribution.
 - avoid the ABI incompatibility by changing libapt-pkg's ABI, so that it works with both
   c++98 and c++11 mode ().

The last one may be an option until you find the next incompatibility,
so in the long term it might be better to just build in c++98 mode.


** Changed in: gcc-4.7 (Ubuntu)
       Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1000508

Title:
  PendingMessages member variable of APT's GlobalError class initializes
  as "true" with -std=c++11

Status in “apt” package in Ubuntu:
  Confirmed
Status in “gcc-4.7” package in Ubuntu:
  Won't Fix

Bug description:
  Symptoms: If a program using libapt-pkg is compiled with -std=c++11
  with gcc 4.7 (this used to work in gcc 4.6), APT's global GlobalError
  class[1] (accessible via the macro "_error" in any file that includes
  apt-pkg/error.h) always returns "true" when the PendingError() member
  is called. This happens directly after the GlobalError instance is
  created, so there is no chance for libapt-pkg to have put anything on
  the error stack. Calling Discard() or DumpErrors() does not clear the
  flag, and none of the functions that print the errors to stdout
  actually print anything. (Presumably, the error stack really is empty)

  This behavior is not present when compiling an application with
  -std=c++11 with gcc 4.6, and the issue goes away if compiled without
  the c++11 cxxflag with gcc 4.7.

  The impact is fairly severe. The libqapt library utilizes c++11
  features in its source code, so this effectively breaks the qaptworker
  runtime utility from running any sort of apt transaction (Cache
  update, commit) due to the fact that it can't check for errors
  reliably, and will error out immediately due to the detected "error".
  This, in effect, breaks the Muon Suite (Kubuntu's default package
  manager.) which uses libqapt (and the qaptworker) for running apt
  tasks that require administrative access. For this reason I'm
  assigning the bug priority for this report to "high".

  I've attached a (very) small Minimally Reproducible Testcase along
  with a small build script that should aid in making testing this bug
  convenient. The test case prints "error!" if the bug is present, and
  will return silently if everything is working as it should.

  [1]http://bazaar.launchpad.net/~ubuntu-
  branches/ubuntu/quantal/apt/quantal/view/head:/apt-
  pkg/contrib/error.cc (also error.h)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1000508/+subscriptions




More information about the foundations-bugs mailing list