clang++ and libcxx seems mostly to work (I've been using clang for a
little while on our source tree and it's revealed a number of problems,
and libcxx has shown another couple, I think).
Actually running executables also seems to work, except for output to
std::cerr:
#include <iostream>
int main()
{
std::cout << "Hello world\n";
}
works fine, and valgrind seems happy with it. Changing the cout to cerr
causes a crash (after producing the output):
#0 0x00007fd207b59475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007fd207b5c6f0 in *__GI_abort () at abort.c:92
#2 0x00007fd208388acb in std::uncaught_exception () at ../src/exception.cpp:103
#3 0x00007fd2083913ca in std::__1::basic_ostream<char, std::__1::char_traits<char> >::sentry::~sentry (this=<optimized out>) at ../include/ostream:243
#4 0x0000000000400d6a in std::__1::operator<< <std::__1::char_traits<char> > (__os=..., __str=0x40135c "Hello world\n") at /usr/local/include/ostream:989
#5 0x0000000000400abd in main () at hello.cpp:4
Any ideas about what might cause this? (It feels odd that cout and cerr
should differ in such a way, but I haven't really looked at the
implementation so perhaps it's obvious.)
(I haven't looked if this is a bug in the runtime, but if it is)
Please report your libcxx bugs to
https://github.com/pathscale/libcxxrt/issues
Thanks
If you build with libcxxrt, you have to add -DLIBCXXRT.
Joerg
Joerg Sonnenberger
<joerg-R+WAh6b6Lhar4AypMXd3aLNAH6kLmebB@public.gmane.org> writes:
Two replies so far, and everyone seems to be assuming you're talking about libcxxrt, not libc++. For future reference, calling libc++ libcxx apparently confuses people...
As to the bug, I've seen crashes like this before when doing the FreeBSD and Solaris ports. As I recall, that exception is thrown when the locale_t is NULL. In this case, I would expect you to be using the C locale. I believe on glibc that this is generated by calling __cloc(), so this may be a good place to look.
David
No, I'm just saying that libc++ works if compiled with -DLIBCXXRT against
libcxxrt. On !Apple, the check for uncaught exceptions is explicitly
broken, i.e. calling abort().
Joerg
David Chisnall <theraven-Ae9UE+oIsuU@public.gmane.org> writes:
Two replies so far, and everyone seems to be assuming you're talking
about libcxxrt, not libc++. For future reference, calling libc++
libcxx apparently confuses people...
I've changed the subject line. Probably my own fault; the directory I
checked out libc++ to is called libcxx.
As to the bug, I've seen crashes like this before when doing the
FreeBSD and Solaris ports. As I recall, that exception is thrown when
the locale_t is NULL. In this case, I would expect you to be using
the C locale.
I'm not. At least, LANG is set to en_GB.UTF-8. Setting it to C, en_GB,
unsetting it, doesn't seem to change the crash.
I believe on glibc that this is generated by calling __cloc(), so this
may be a good place to look.
OK. I'm still not seeing anything obvious: if I include <locale> then I
can create a locale (and the destructor seems to complete fine).
ldd shows I'm linking against libstdc++.so.6 and librt.so.1 as well as
libc++.so.1. Is that expected, or should I not be linking against
libstdc++?
linux-vdso.so.1 => (0x00007fffe9976000)
libc++.so.1 => /usr/local/lib/libc++.so.1 (0x00007fced02e2000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fced0043000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fcecfe2c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcecfaa5000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fcecf7a1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcecf584000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fcecf37c000)
/lib64/ld-linux-x86-64.so.2 (0x00007fced065b000)
[...]
I wasn't watching closely the libc++ build.
I suspect I was just thrown by the fact that so much just worked!
I got our whole tree built and all but one of the sets of tests passed. (Our
source doesn't contain that much exotic C++ since we need it to compile
on a variety of platforms all using slightly old compilers, but even so.)
Thanks for the report. Glad to hear it! It sounds like you're missing an implementation of the low level Itanium ABI. Here are two I'm aware of:
http://libcxxabi.llvm.org/
https://github.com/pathscale/libcxxrt
Howard
The only part is making sure all pieces are linked.
libc++ + libgcc_s shows the issues with std::cerr (and possible other
things). No idea about libcxxabi.
Joerg