Bug 667450 – =sys-libs/libcxxabi-7.0.1 fails to emerge on arm when gcc is used to compile it with: cxa_default_handlers.cpp:39:54: error: invalid operands of types ‘char [8]’ and ‘const uint64_t

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description tt_1 2018-10-01 14:20:16 UTC]

Created attachment 548580 [details]
compressed build.log

here is the most interesting part of the error message: 

/var/tmp/portage/sys-libs/libcxxabi-6.0.1/work/libcxxabi-6.0.1.src/src/cxa_default_handlers.cpp:39:54: error: invalid operands of types ‘char [8]’ and ‘const uint64_t {aka const long long unsigned int}’ to binary ‘operator&’
                 (unwind_exception->exception_class   & get_vendor_and_language) ==
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
/var/tmp/portage/sys-libs/libcxxabi-6.0.1/work/libcxxabi-6.0.1.src/src/cxa_default_handlers.cpp:44:58: error: ISO C++ forbids comparison between pointer and integer [-fpermissive]
                     unwind_exception->exception_class == kOurDependentExceptionClass ?
                                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~


I'll attach the full build log

[Comment 1 tt_1 2018-10-01 14:21:29 UTC]

Created attachment 548582 [details]
output of emerge --info

this is the emerge --info from that system

[Comment 2 tt_1 2018-10-01 14:25:08 UTC]

A solution for this is to use clang for compilation. If CC=clang and CXX=clang++ are set via a package.env file, the compile works just fine. 

Possible mitigation of this: add a clang useflag, to use clang as a compiler, just as compiler-rt has it.

[Comment 3 tt_1 2018-10-07 14:59:05 UTC]

I think the linked bug from llvm bug tracker is the same as this one here. It has some discussions about it and a patch, but it seems to be stuck.

[Comment 4 tt_1 2018-10-07 15:55:35 UTC]

The fedora seems to be legit, it applied to current 7.0.0 and I was able to recompile libcxxabi with both gcc and clang. 

Adding the patches url for other users, to test.

@mgorny - I doubt any patch would be added to the tree before it's merged upstream, right?

[Comment 5 Michał Górny 2018-10-07 17:02:48 UTC]

(In reply to tt_1 from comment #4)
> @mgorny - I doubt any patch would be added to the tree before it's merged
> upstream, right?

I generally prefer to wait for upstream.  However, if the patch looks correct and we can't build it otherwise, I'll just add it.  But I'll try to ping upstream first.

[Comment 6 tt_1 2018-10-07 17:17:22 UTC]

To ping upstream could be really helpfull. 

The review is here: https://reviews.llvm.org/D42242 

But the reviewed/discussed patch is incomplete, the working patch is from Fedora and a link is posted in the comments.

[Comment 7 Michał Górny 2018-10-10 11:02:05 UTC]

Hopefully I've pushed things enough to get the first patch merged.  Would you be able to locate the author of the Fedora patch and possibly ask him to submit the other part upstream separately?

[Comment 8 tt_1 2018-10-10 12:06:43 UTC]

Created attachment 550328 [details, diff]
changes introduced by the fedora patch

I wrote the guy an email, hopefully I'm going to hear from him how to proceed. 

The "official" patch and the fedora patch are 95% identical, it's attached. With only D42242 applied to libcxxabi, it fails with this error: 

/var/tmp/portage/sys-libs/libcxxabi-7.0.0/work/libcxxabi-7.0.0.src/src/cxa_personality.cpp: In function ‘void __cxxabiv1::scan_eh_tab(__cxxabiv1::{anonymous}::scan_results&, _Unwind_Action, bool, _Unwind_Control_Block*, _Unwind_Context*)’:
/var/tmp/portage/sys-libs/libcxxabi-7.0.0/work/libcxxabi-7.0.0.src/src/cxa_personality.cpp:574:22: error: ‘_URC_FATAL_PHASE1_ERROR’ was not declared in this scope
     results.reason = _URC_FATAL_PHASE1_ERROR;
                      ^~~~~~~~~~~~~~~~~~~~~~~
/var/tmp/portage/sys-libs/libcxxabi-7.0.0/work/libcxxabi-7.0.0.src/src/cxa_personality.cpp:594:30: error: ‘_URC_FATAL_PHASE2_ERROR’ was not declared in this scope
             results.reason = _URC_FATAL_PHASE2_ERROR;
                              ^~~~~~~~~~~~~~~~~~~~~~~
/var/tmp/portage/sys-libs/libcxxabi-7.0.0/work/libcxxabi-7.0.0.src/src/cxa_personality.cpp: In function ‘_Unwind_Reason_Code __cxxabiv1::__gxx_personality_v0(_Unwind_State, _Unwind_Control_Block*, _Unwind_Context*)’:
/var/tmp/portage/sys-libs/libcxxabi-7.0.0/work/libcxxabi-7.0.0.src/src/cxa_personality.cpp:1099:16: error: ‘_URC_FATAL_PHASE1_ERROR’ was not declared in this scope
         return _URC_FATAL_PHASE1_ERROR;
                ^~~~~~~~~~~~~~~~~~~~~~~
/var/tmp/portage/sys-libs/libcxxabi-7.0.0/work/libcxxabi-7.0.0.src/src/cxa_personality.cpp:1112:11: error: invalid conversion from ‘int’ to ‘_Unwind_State’ [-fpermissive]
     state &= ~_US_FORCE_UNWIND;
     ~~~~~~^~~~~~~~~~~~~~~~~~~~
/var/tmp/portage/sys-libs/libcxxabi-7.0.0/work/libcxxabi-7.0.0.src/src/cxa_personality.cpp:1192:12: error: ‘_URC_FATAL_PHASE1_ERROR’ was not declared in this scope
     return _URC_FATAL_PHASE1_ERROR;
            ^~~~~~~~~~~~~~~~~~~~~~~

[Comment 9 matoro 2018-12-27 21:41:27 UTC]

What is the status of this patch upstream-wise?  I see discussion on the LLVM review portal but it seems to have fizzled out around October.  I ran into this problem on clang 7.0.1, so it doesn't seem to have made it to release yet.

[Comment 10 tt_1 2018-12-27 21:57:00 UTC]

D42242 was merged by upstream into the 8.0 branch, but didn't got backported to 7.0.1 or the like. 

It solves most but not all of the problems, and so I posted the rest of the fedora patch to their code review system. However, I was a bit naive and thought they're going to accept it 'as is', which they didn't. So, I can't solve this on my own, because I can't really code or hack something on this level. 

If you need the library take the updated fedora patch from #8 in addition to D42242, stick to clang as a compiler, or if you're able to solve this take it over. 

(We were granted permission from the fedora guy to basically do whatever we want with his patch)

[Comment 11 tt_1 2019-01-01 21:53:38 UTC]

@llvm 

would you be willing to add the patch from D42242 [1] to libcxxabi-7.0.1? It fixes this initial bug. Also there are some more problems but for them it might be better to open a new gentoo bug. 

P.S. libcxxabi got keyworded ~arm, this is not exactly right as its not possible to compile it with gcc at the moment. 

[1] = https://reviews.llvm.org/D42242

[Comment 12 Michał Górny 2019-01-02 08:14:13 UTC]

I don't see a point in backporting a partial fix.  We should wait for the issue to be resolved compeletely, shouldn't we?

Also, I'm not sure whether https://reviews.llvm.org/D53127 is actually necessary.  Looking at the sources, I don't see how the enums listed there would be missing.

[Comment 13 matoro 2019-01-02 18:49:09 UTC]

After running in circles for a few days I have finally managed to get =sys-libs/libcxxabi-7.0.1 to compile with gcc, including with wacky CFLAGS.  There are two steps required:  one, add the below patch (only tested on 7.0.1) and two, add "-lgcc_s" to LDFLAGS.  I did this with package.env but a programmatic way needs to be devised before it can be merged into the tree.

[Comment 14 matoro 2019-01-02 18:50:49 UTC]

Created attachment 559568 [details, diff]
=sys-libs/libcxxabi-7.0.1 patch

[Comment 15 tt_1 2019-01-02 19:41:23 UTC]

The patch you attached is identical with the patch written by the Fedora dev. Most of it got merged in D42242 and the additional part to make it compile got rejected in D53127. 

The problem is I ran into this by accident, but I can't help that much to fix it for my lack of experience in coding.

[Comment 16 matoro 2019-01-02 20:56:00 UTC]

So if I am reading the review right, according to https://reviews.llvm.org/D53127#1264838 they want these defines to be specified on the build command line instead of #ifdefs in the code?  I don't quite understand why we should not be adding downstream patches if upstream wants to sacrifice things actually building for code quality.  IMO keeping the Gentoo tree up to date should take priority over keeping downstream code vanilla.

[Comment 17 tt_1 2019-01-02 21:08:10 UTC]

well, 

I intended to do some research, but soon found out none of this is really doable for me. Lack of basic knowledge, not much experience, you get the idea. The only thing I was able to understand was to replace __GNUC__ with (__ARM_EABI_UNWINDER__) 

If you're willing to pick this up in D53127, you're much welcome. But please base your patch on current trunk, gentoo devs are usually reluctant to add patches to the gentoo tree which are not yet upstreamed. This is especially true for libc's, compiler, and other core packages. On the other hand, it shouldn't be much of a problem to add a not yet existing second patch to 7.0.1 as long as it got accepted by upstream. 

(The user stefson talking @D53127 is me)

[Comment 18 tt_1 2019-07-22 11:55:03 UTC]

The initial bug has been solved, therefore closing this.