Get LLVM's libc++abi into Fedora, BZ1332306

[E.N. virgo]

Greetings,

The LLVM project has been providing a C++ ABI for a while [1]. A naive user like I'm
would presume Fedora easily ships with that, as the saying goes: “Fedora is a
developer-friendly distro.” Unfortunately, that isn't the case for this instance and
if one is using clang++, they have to link against the GCC's ABI instead of the
LLVM's. Elsewhere, there is no such a quirk, see for instance [2] and [3].

Thanks to Tom Callaway, it's now more than 9 months that there is a candidate package
for this very purpose [4]. If someone with a pedigree as that of "spot" resorts
to saying: “I am waiting on a review for 1332306 in order to get libcxxabi into Fedora. I
did not think it would take this long for that to happen.” [5], what a looker-by should
think? Is this delay on purpose or is the review that difficult? Could some benefactor
packager take over the review so that LLVM+CLANG are not any more like second-citizens in
Fedora?

Thanks.

---
[1] http://libcxx.llvm.org/
[2] https://packages.debian.org/search?keywords=libc%2B%2Babi
[3] https://aur.archlinux.org/packages/libc%2B%2Babi/
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1332306
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1415512#c1

[Florian Weimer]

On 02/15/2017 08:12 AM, E.N. virgo wrote:
>  Greetings,
>
>  The LLVM project has been providing a C++ ABI for a while [1]. A naive user like I'm
> would presume Fedora easily ships with that, as the saying goes: “Fedora is a
> developer-friendly distro.” Unfortunately, that isn't the case for this instance and
> if one is using clang++, they have to link against the GCC's ABI instead of the
> LLVM's. Elsewhere, there is no such a quirk, see for instance [2] and [3]. 
I'm not sure if I follow.  Supporting multiple C++ ABIs would make 
things more complicated for developers because they now have to figure 
out which ABI their project needs and if all the libraries they want to 
use are available with the right ABI.

I really don't think we should move in this direction.

Thanks,
Florian

[E.N. virgo]

>  I'm not sure if I follow.  Supporting multiple C++ ABIs would
> make 
>  things more complicated for developers because they now have to figure 
>  out which ABI their project needs and if all the libraries they want to  
          
                                                    ^^^^^^^^^^^^^^^^^^^^^^^^
>  use are available with the right ABI. 
From the example in BZ1415512, all libraries are standard, the sources remain the same
regardless the compiler to be used. Alas, clang++ now needs to link against the GCC ABI to
successfully compile.

There are some cases when one needs to try different tools, for instance to take advantage
of the LLVM's instrumentation tools which IMHO constitute a plus, not a pain.

>  
>  I really don't think we should move in this direction.
>   
Reading the package review request by "spot" and the comments, there is no
indication the review stalled because of ABIs worries. But I don't really have a clue
in packaging issues; onlooking at the BZ, it stroke me that particular package was not a
hard case review-wise.

Are there pointers elsewhere indicating the corner cases of introducing another C++ ABI
into Fedora? What would be your comments about the situation in Debian+derivatives and
Archlinux+derivatives? Both distros have the LLVM ABI and so far, so good for C++
developers.

Thanks.

> Thanks,
> Florian

[Michael Stahl]

On 15.02.2017 09:48, E.N. virgo wrote:
> > I'm not sure if I follow.  Supporting multiple C++ ABIs would
> make 
> > things more complicated for developers because they now have to figure 
> > out which ABI their project needs and if all the libraries they want to 
>                                                                 ^^^^^^^^^^^^^^^^^^^^^^^^
> > use are available with the right ABI.
>  
>  From the example in BZ1415512, all libraries are standard, the sources remain the same
> regardless the compiler to be used. Alas, clang++ now needs to link against the GCC ABI to
> successfully compile. 
what actual problem is caused by that?

>  There are some cases when one needs to try different tools, for
> instance to take advantage of the LLVM's instrumentation tools which IMHO constitute a
> plus, not a pain. 
which clang instrumentation tool requires libc++abi?

all the sanitizers i tried work just fine with libstdc++.

last i checked, libc++ didn't even have an equivalent of _GLIBCXX_DEBUG,
which is a pretty severe limitation and makes it useless for me.

> > I really don't think we should move in this direction.
>  
>  Are there pointers elsewhere indicating the corner cases of introducing another C++ ABI
> into Fedora? 
there are subtle corner cases breaking exception handling:

https://whatofhow.wordpress.com/2016/03/01/libclibcabi-on-linux/

but hey, some people think that spending many hours debugging that sort
of thing is fun, so taking that as an argument against packaging
libc++abi would clearly go against the C++ philosophy.

[E.N. virgo]

> > Alas, clang++ now needs to link against the GCC ABI to
> successfully compile. 
>  what actual problem is caused by that? 
Please read instead “Alas, clang++ currently
needs to link against the GCC ABI to successfully compile.”
The problem is that one might want to use libstdc++ (GCC) and libc++ (LLVM) along with GCC
ABI and LLVM ABI, respectively. Fedora currently enables the GCC case, but one has to fall
back to GCC ABI even when using an LLVM library.

>  which clang instrumentation tool requires libc++abi? 
Not an
instrumentation in particular, I ran into problems when trying to LD_PRELOAD some
instrumented binaries and founding they needed libc++abi.

>  there are subtle corner cases breaking exception handling:
>  
>  https://whatofhow.wordpress.com/2016/03/01/libclibcabi-on-linux/ 
Blog post amended
in the comments.

Overall, I am not willing to argue about C++ best coding/debugging practices. I am rather
asking if there is any possibility that package review request (BZ1332306) stalled for
ages would get some care. Had I been a packager, sure I would try to handle the review
process myself, but I am not a packager. It would be nice to have some contributor giving
the libc++abi package some time, I am quite sure there are many people who will be very
grateful.

Thanks.

[Neal Gompa]

On Wed, Feb 15, 2017 at 5:21 AM, E.N. virgo <cireyapmin(a)gmail.com&gt; wrote:
> >> Alas, clang++ now needs to link against the GCC ABI to
> successfully compile.
> > what actual problem is caused by that?
>  Please read instead “Alas, clang++ currently needs to link against the GCC ABI to
> successfully compile.”
>  The problem is that one might want to use libstdc++ (GCC) and libc++ (LLVM) along with
> GCC ABI and LLVM ABI, respectively. Fedora currently enables the GCC case, but one has to
> fall back to GCC ABI even when using an LLVM library.
>
> > which clang instrumentation tool requires libc++abi?
>  Not an instrumentation in particular, I ran into problems when trying to LD_PRELOAD some
> instrumented binaries and founding they needed libc++abi.
>
> > there are subtle corner cases breaking exception handling:
> >
> > https://whatofhow.wordpress.com/2016/03/01/libclibcabi-on-linux/
>  Blog post amended in the comments.
>
>  Overall, I am not willing to argue about C++ best coding/debugging practices. I am rather
> asking if there is any possibility that package review request (BZ1332306) stalled for
> ages would get some care. Had I been a packager, sure I would try to handle the review
> process myself, but I am not a packager. It would be nice to have some contributor giving
> the libc++abi package some time, I am quite sure there are many people who will be very
> grateful.
>  
I'll take on the review, but you really should consider becoming
involved in Fedora as a packager, as any packager can review another
packagers packages proposed for inclusion into Fedora.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[E.N. virgo]

>  I'll take on the review, 
Thank you so much for stepping in,
this is mostly appreciated.

>  but you really should consider becoming
>  involved in Fedora as a packager, as any packager can review another
>  packagers packages proposed for inclusion into Fedora. 
I am a slow learner, but
there is some progress. It is by reading some wikis that I learnt about the review process
and about who can review a package. Next, I dived into the RPM format and am still stuck
there. Hopefully, when the learning is over, I will create some packages, there are a
couple of SIGs where I plan to contribute.

Once more, thanks for considering the libc++abi. Apologies if my shameless touting for the
package was not the most elegant way to put forward the case.

[Jonathan Wakely]

On 15/02/17 10:21 -0000, E.N. virgo wrote:
> >> Alas, clang++ now needs to link against the GCC ABI to
> successfully compile.
> > what actual problem is caused by that?
> Please read instead “Alas, clang++ currently needs to link against the GCC ABI to
> successfully compile.”
> The problem is that one might want to use libstdc++ (GCC) and libc++ (LLVM) along with GCC
> ABI and LLVM ABI, respectively. Fedora currently enables the GCC case, but one has to fall
> back to GCC ABI even when using an LLVM library. 
So what? Why is that a problem?

Does the libc++abi have better performance for exception handling?

Smaller footprint for RTTI?

More new features, such as C++17's std::uncaight_exceptions()?

Just because there's a different low-level C++ runtime library
available doesn't mean that using it makes sense. Fedora is built with
GCC and libstdc++, so swapping those pieces out has potentially large
consequences.

You might think I'm biased as I'm a libstdc++ maintainer, but I'd say
the same thing if somebody was asking about replacing libcxxabi on Mac
OS with libsupc++, or replacing libcxxrt on FreeBSD with libsupc++:
don't do it unless you really know what you're doing, and can isolate
it completely from the rest of the OS.

Quoting from
https://www.usenix.org/legacy/publications/library/proceedings/bos94/full...

| One final anecdote regarding the earlier story 
| where someone used an int reference parameter. In 
| discussing this paper, the programmer's comment was 
| - "Well, the feature was in the language so I figured I 
| should use it.". It is our belief that this is not a 
| sufficient criteria for using a feature of C++. A feature 
| should be used only when it can be demonstrated to be 
| of benefit. A mountain is climbed "because it is there". 
| The same should not hold true for C++ features. Their 
| mere existence is not justification for use.


> > which clang instrumentation tool requires libc++abi?
> Not an instrumentation in particular, I ran into problems when trying to LD_PRELOAD some
> instrumented binaries and founding they needed libc++abi. 
Then they were built on a different distro from Fedora?
That's always going to be unsupported to some degree.

> > there are subtle corner cases breaking exception handling:
> >
> > https://whatofhow.wordpress.com/2016/03/01/libclibcabi-on-linux/
> Blog post amended in the comments.
>
> Overall, I am not willing to argue about C++ best coding/debugging practices. I am rather
> asking if there is any possibility that package review request (BZ1332306) stalled for
> ages would get some care. Had I been a packager, sure I would try to handle the review
> process myself, but I am not a packager. It would be nice to have some contributor giving
> the libc++abi package some time, I am quite sure there are many people who will be very
> grateful. 
If adding the package makes it easier for people to create
incompatible builds for Fedora that don't play nicely with the rest of
the OS I don't think it's a good idea.

[E.N. virgo]

>  So what? Why is that a problem?
>  Does the libc++abi have better performance for exception handling?
>  Smaller footprint for RTTI?
>  More new features, such as C++17's std::uncaight_exceptions()?
>  Just because there's a different low-level C++ runtime library
>  available doesn't mean that using it makes sense. Fedora is built with
>  GCC and libstdc++, so swapping those pieces out has potentially large
>  consequences.
>  You might think I'm biased as I'm a libstdc++ maintainer, but I'd say
>  the same thing if somebody was asking about replacing libcxxabi on Mac
>  OS with libsupc++, or replacing libcxxrt on FreeBSD with libsupc++:
>  don't do it unless you really know what you're doing, and can isolate
>  it completely from the rest of the OS. 
As I wrote in another mail, my main intent
was shedding some light into a frozen review request. Nonetheless, thank you for pointing
out what to consider when mixing things that were not designed to work together. Googling
on the subject quickly leads to one of your writing among the top results [1]; I do not in
no way intend to “educate” the libstdc++ maintainer, but if you are still not closely
following libc++ development (as implied in [1]), maybe [2] could be of some use.

>  If adding the package makes it easier for people to create
>  incompatible builds for Fedora that don't play nicely with the rest of
>  the OS I don't think it's a good idea. 
The first use case for the package
is not mine, it belongs to Tom Callaway who in the first place wanted and created the
package. His review request explains why he did. Then in the comments and in another
bugzilla, third parties expressed the same desire to have the package. My needs are
modest, I mainly would like to try some stuff on my Fedora box before interacting with
people who use platforms where libc++ is the “system default”; the said stuff is not much
involved, it does not try to play “with the rest of the OS”. So thanks to Fedora for
helping me in that vein, as I am confident Neal Gompa and Tom Callaway will eventually
make the package alive.

[1] http://stackoverflow.com/questions/14972425/should-i-use-libc-or-libstdc
[2] http://lists.llvm.org/pipermail/cfe-dev/2016-July/049814.html

[Jonathan Wakely]

On 15/02/17 13:48 -0000, E.N. virgo wrote:
> > So what? Why is that a problem?
> > Does the libc++abi have better performance for exception handling?
> > Smaller footprint for RTTI?
> > More new features, such as C++17's std::uncaight_exceptions()?
> > Just because there's a different low-level C++ runtime library
> > available doesn't mean that using it makes sense. Fedora is built with
> > GCC and libstdc++, so swapping those pieces out has potentially large
> > consequences.
> > You might think I'm biased as I'm a libstdc++ maintainer, but I'd say
> > the same thing if somebody was asking about replacing libcxxabi on Mac
> > OS with libsupc++, or replacing libcxxrt on FreeBSD with libsupc++:
> > don't do it unless you really know what you're doing, and can isolate
> > it completely from the rest of the OS.
> As I wrote in another mail, my main intent was shedding some light into a frozen review
> request. Nonetheless, thank you for pointing out what to consider when mixing things that
> were not designed to work together. Googling on the subject quickly leads to one of your
> writing among the top results [1]; I do not in no way intend to “educate” the libstdc++
> maintainer, but if you are still not closely following libc++ development (as implied in
> [1]), maybe [2] could be of some use. 
That's about libc++ which is not the same as libc++abi, and they can
be used independently (you can use libc++ with or without libc++abi,
and vice versa).

I've added some comments to the review request.

[Florian Weimer]

On 02/15/2017 11:21 AM, E.N. virgo wrote:
>  Please read instead “Alas, clang++ currently needs to link against
> the GCC ABI to successfully compile.”
>  The problem is that one might want to use libstdc++ (GCC) and libc++ (LLVM) along with
> GCC ABI and LLVM ABI, respectively. Fedora currently enables the GCC case, but one has to
> fall back to GCC ABI even when using an LLVM library. 
Providing a useful development environment for libc++ is a lot of work. 
We would have to compile most C++ libraries twice, so that they can be 
used with either C++ standard library, and provide tooling to prevent 
accidental cross-linking reliably.  I really do not see the benefit for 
the developer.  More choice isn't always an improvement.

Thanks,
Florian