[SRU] Wily (15.10) this package got not compiled with __cxx11 support

[Matthias Goldhoorn]

[Impact]

* with gcc-5 default, and llvm-3.4 built with the gcc-4.9, people can't link programs using cxx11 support

[Test Case]

* compile a program using cxx11 e.g. using boost libraries

[Regression Potential]

* llvm-3.4 is a compiler, and the change should affect only cxx11 support (since the library is ABI compatible).

So, fixing cxx11 support shouln't have any regression, only the feature will start working, while it wasn't before

[Other Info]

* Doko ack'd the SRU, and it should be the best voice here, for sure better than mine :)

This packages does not contain any __cxx11 symbols when installed. This causes the problem that user-space applications cannot link successfully to it.
Recompile the (untouched) dpkg source package on the same machine and installing it solved the problem.

There seems something in the package generation broken.

Steps to reproduce try to compile the attached minimal example
https://github.com/goldhoorn/clang-sandbox

Errors:
CMakeFiles/main.dir/main.cpp.o: In function `foo()':
/tmp/clang-sandbox/main.cpp:25: undefined reference to `clang::NamedDecl::getQualifiedNameAsString[abi:cxx11]() const'
CMakeFiles/main.dir/main.cpp.o: In function `clang::QualType::getAsString[abi:cxx11](clang::SplitQualType)':
/usr/lib/llvm-3.4/include/clang/AST/Type.h:868: undefined reference to `clang::QualType::getAsString[abi:cxx11](clang::Type const*, clang::Qualifiers)'
CMakeFiles/main.dir/main.cpp.o: In function `clang::ast_matchers::internal::matcher_matchesName0Matcher::matches(clang::NamedDecl const&, clang::ast_matchers::internal::ASTMatchFinder*, clang::ast_matchers::internal::BoundNodesTreeBuilder*) const':
/usr/lib/llvm-3.4/include/clang/ASTMatchers/ASTMatchers.h:1439: undefined reference to `clang::NamedDecl::getQualifiedNameAsString[abi:cxx11]() const'
CMakeFiles/main.dir/main.cpp.o: In function `clang::ast_matchers::internal::matcher_hasName0Matcher::matches(clang::NamedDecl const&, clang::ast_matchers::internal::ASTMatchFinder*, clang::ast_matchers::internal::BoundNodesTreeBuilder*) const':
/usr/lib/llvm-3.4/include/clang/ASTMatchers/ASTMatchers.h:1411: undefined reference to `clang::NamedDecl::getQualifiedNameAsString[abi:cxx11]() const'
/usr/lib/llvm-3.4/lib/libclangAST.a(ExprConstant.o): In function `handleIntIntBinOp((anonymous namespace)::EvalInfo&, clang::Expr const*, llvm::APSInt const&, clang::BinaryOperatorKind, llvm::APSInt, llvm::APSInt&)':
(.text+0x6a35): undefined reference to `llvm::APInt::toString(unsigned int, bool) const'
/usr/lib/llvm-3.4/lib/libclangAST.a(StmtPrinter.o): In function `(anonymous namespace)::StmtPrinter::VisitIntegerLiteral(clang::IntegerLiteral*) [clone .isra.302]':

...

This example is workign on privious ubuntus and debians

Sysinfo:
Description: Ubuntu Wily Werewolf (development branch)
Release: 15.10
In a VirtualBox

[mzenzes (mzenzes)]

Same here. Would be nice to get a fix for this before the release happens...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Matthias Goldhoorn (matthias-l)]

I created a PPA package which builds on launchpad and successfully got linked in my case:

https://launchpad.net/~matthias-l/+archive/ubuntu/rock-ppa/+packages

The most relevant change was that i changed the default compiler to gcc-5 instead of a autodetection.

[Matthias Goldhoorn (matthias-l)]

I just created a patch which solved the problem.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "wily-using-right-gcc.patch" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Matthias Goldhoorn (matthias-l)]

Is there anywhere a maintainer around who can give some recommendations or review the patch?

[Matthias Goldhoorn (matthias-l)]

If i added this somehow wrong please let me know. i provided a solution which should be correct to add it to mainstream.
This patch really complicates our development or our projects on a Ubuntu 15.10 target.

Moreover the proposed patch should be review able by any Ubuntu maintainer, the problem is not llvm specific (renamed from gcc-x.x to gcc-x in ubntu15.10). It makes for me a really not good impression for (ubuntu in general) that a review of a straight forward patch took so long....

[mitko (dimitar-asenov)]

I might be hitting the same or at least a related bug: I am using clang 3.7 to compile an application that itself uses libclang3.7 to do some C++ parsing. I get unresolved symbol errors from the linker. Namely this one single error, many times:

undefined reference to `clang::NamedDecl::getQualifiedNameAsString() const'

The same source code compiles fine using gcc 5.2 so it really seems it's a problem with the string ABI change of gcc and stale libraries.

[Matthias Goldhoorn (matthias-l)]

I just uploaded a patched version of the 3.7 to my personal PPA, the 3.7 has the same issue than this 3.4.
Please try the llvm-toolchain-3.7 1:3.7-2ubuntu2 from my rock-ppa if this helps you create a bug report on the 3.7 and i will add the patch there also, hopefully the package maintainer will respond and merge them soon...

P.S. the package needs a bit to build on the ubuntu servers: https://launchpad.net/~matthias-l/+archive/ubuntu/rock-ppa/+build/8213723

[Matthias Goldhoorn (matthias-l)]

mitko: i created a issue on the llvm-3.7 and attached the patch:

https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.7/+bug/1511128

[mitko (dimitar-asenov)]

Thanks, Matthias. Your PPA still hasn't compiled the package. Once its done I will try it and let you know. I'm fairly confident it will work just fine.

[Matthias Goldhoorn (matthias-l)]

mitko: it seems the i386 does not finish because the build-servers are too slow, however the x64 build is finished.
I have no clue howto tell the buildserver to wait longer for the result for the i386 build. of the llvm-3.7. But i recomment we move this 3.7 discussion to the other bugreport

[mitko (dimitar-asenov)]

Alright, I'll post there.

[Sebastien Bacher (seb128)]

Thank you for your bug report. it seems like the change could apply to Debian as well, could you report the bug to the Debian BTS as well?

[Sebastien Bacher (seb128)]

Could you also maybe explain what you changed in the regexp and why and how that resolves the issue?

[Matthias Goldhoorn (matthias-l)]

Debian testing is not affected i use it too

On 10.11.2015 17:57, Sebastien Bacher wrote:
> Debian as well, could you report the bug to the Debian BTS as well?

[Matthias Goldhoorn (matthias-l)]

The rexexp checks for availible compiler versions.
Theregexp checks for X.X.X i changed the regexpt to X.X

The fallback was to use gcc 4.9 which was availible on ubuntu.
The new gcc is 5.2, therefore now the new regexpt matches.

I do not checked the originial debian rules from the debian project. I
can only say that the bug does not exist there..

On 10.11.2015 18:17, Sebastien Bacher wrote:
> Could you also maybe explain what you changed in the regexp and why and
> how that resolves the issue?
>

[Matthias Goldhoorn (matthias-l)]

On 10.11.2015 18:17, Sebastien Bacher wrote:
> Could you also maybe explain what you changed in the regexp and why and
> how that resolves the issue?
>
additon:
By changing the regexpt the package got now compiled with gcc5.2 instead
of 4.9

[Matthias Goldhoorn (matthias-l)]

Just checked debian testing does a simliar change with a slighly different reg-exp:

old:
http://http.debian.net/debian/pool/main/l/llvm-toolchain-3.4/llvm-toolchain-3.4_3.4.2-13.debian.tar.xz
new:
http://http.debian.net/debian/pool/main/l/llvm-toolchain-3.4/llvm-toolchain-3.4_3.4.2-16.debian.tar.xz

[Sebastien Bacher (seb128)]

oh, right, thanks for the details

-16 from Debian has been synced to current Ubuntu
https://launchpad.net/ubuntu/+source/llvm-toolchain-3.4/1:3.4.2-16

Unsure what to do about 15.10, the current package is built with gcc 4.9 and I'm unsure what's the impact of building with gcc5 and if that's fine for a SRU

[Sebastien Bacher (seb128)]

debdiff to backport if you want to SRU the change
http://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/3.4/debian/rules?r1=1456&r2=1610

[Matthias Goldhoorn (matthias-l)]

The package needs to be build with gcc5.2 to have the correct (dualabi)
symbols in the library.

Therefore the back port to 15.10 is definitely needed! Otherwise 3th parity libs cannot link against the clang compiler (what we definitely need)

In generall all librarys on a dualabi system (>=gcc5.2) should be compilet with a dualabi compiler.
By enforcing this the system becomes consistend and fully compiletime safe against c++11.
Mixing pre-dual abi's and and compiled user application can cause a invalid binary.

[Matthias Goldhoorn (matthias-l)]

How can this patch (or the backport) apply for a SRU update, how it is possible to add a SRU maintainer to this thread?

[Mathew Hodson (mhodson)]

In order for this to be SRUed to Wily, you need to make the bug compliant with https://wiki.ubuntu.com/StableReleaseUpdates (Please add a rational, test case, and regression potential to the description of this bug.)

[Matthias Klose (doko)]

looks ok for a SRU

[Iain Lane (laney)]

backported + uploaded the mentioned commit - this bug probably needs SRU information per comment #26 before it'll be accepted though.

thanks!

[Brian Murray (brian-murray)]

Thanks for uploading the fix for this bug report to -proposed. However, when reviewing the package in -proposed and the details of this bug report I noticed that the bug description is missing information required for the SRU process. You can find full details at http://wiki.ubuntu.com/StableReleaseUpdates#Procedure but essentially this bug is missing some of the following: a statement of impact, a test case and details regarding the regression potential. Thanks in advance!

[Chris J Arges (arges)]

Hello Matthias, or anyone else affected,

Accepted llvm-toolchain-3.4 into wily-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/llvm-toolchain-3.4/1:3.4.2-13ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Gianfranco Costamagna (costamagnagianfranco)]

Yes, now clang is built on top of gcc-5

[Launchpad Janitor (janitor)]

This bug was fixed in the package llvm-toolchain-3.4 - 1:3.4.2-13ubuntu2.1

---------------
llvm-toolchain-3.4 (1:3.4.2-13ubuntu2.1) wily; urgency=medium

  * d/rules: fix gcc-5 detection, since gcc-5.2 doesn't provide a g++-5.2
    binary (but it is called g++-5). Patch cherry-picked from Debian
    (Gianfranco Costamagna). LP: #1501300

 -- Iain Lane <email address hidden> Mon, 07 Dec 2015 13:10:08 +0000

[Chris Halse Rogers (raof)]

The verification of the Stable Release Update for llvm-toolchain-3.4 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.