Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: indridi on February 08, 2016, 05:19:19 PM
-
Hi,
Wondering if anyone could help me understand this but it seems that I can't get exceptions in C++ to work properly.
I'm using: Linux box 4.1.13-piCore_v7+ #1 SMP PREEMPT Thu Dec 3 14:16:36 CET 2015 armv7l GNU/Linux
When I compile the following code, using g++ (5.3.0):
#include <exception>
#include <iostream>
int main(int argc, char **argv)
{
try {
std::cout << "throwing" << std::endl;
throw std::exception();
} catch (std::exception& e) {
std::cout << "catching" << std::endl;
}
return 0;
}
I'll get:
throwing
terminate called after throwing an instance of 'std::exception'
Aborted
Running in gdb will give me:
(gdb) run
Starting program: /mnt/sda1/persistent/build/throw/a.out
throwing
terminate called after throwing an instance of 'std::exception'
Program received signal SIGABRT, Aborted.
0x76cf0950 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x76cf0950 in raise () from /lib/libc.so.6
#1 0x76cf1cc8 in abort () from /lib/libc.so.6
#2 0x76f18644 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
#3 0x76f16870 in ?? () from /usr/lib/libstdc++.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
Running the same code on Ubuntu 14.04 will give me:
throwing
catching
as expected.
I tried adding the -fexceptions flag and also tried cross-compiling it on Ubuntu 14.04, using gcc (4.8.4) but with the same result.
What I'm I missing here?
Thanks,
Indridi
-
Hi,
I found out what the problem is /usr/lib/libstdc++.so.6.0.21 is compiled incorrectly. Downloaded, copiled gcc and replaced the library and exceptions are now working as expected.
Regards,
Indridi
-
I found out what the problem is /usr/lib/libstdc++.so.6.0.21 is compiled incorrectly. Downloaded, copiled gcc and replaced the library and exceptions are now working as expected.
Let us know what did you change in gcc config and share your build script.
-
Hi,
Downloaded gcc.5.3.0, extracted the files, created a special build directory (as is recommended in the README file). Used the same arguments as the orginal gcc was using
build$ ../gcc-5.3.0/configure --libdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-c99 --enable-long-long --enable-clocale=gnu
--enable-languages=c,c++,fortran --disable-multilib --disable-libstdcxx-pch --enable-cloog-backend=isl --with-system-zlib --enable-frame-pointer --disable-bootstrap --enable-lto
--with-pkgversion=piCore --with-arch=armv6zk --with-tune=arm1176jzf-s --with-fpu=vfp --with-float=hard --with-gxx-include-dir=/usr/include/c++/5.3.0
Then make and make install. Not sure why this build is different from the original. Could it be because I created a clean build directory?
Regards,
Indridi
-
Thanks for feedback. At the moment I have no idea....
-
I have the same problem with piCore 7.1 beta3 (4.1.20-piCore+ armv6l).
Is there any progress on that topic?
-
Please help me to solve this!
I can compile my own gcc but, as I understand, my program will not function properly for others using piCore because of the faulty libstdc++.so.
Thanks in advance!
-
I have the same problem with piCore 7.1 beta3 (4.1.20-piCore+ armv6l).
Is there any progress on that topic?
Please provide a sample build script to reproduce the issue.
-
Hello,
I wrote a shell script:
#!/bin/sh
tce-load -i compile-essentials
tce-load -i binutils
cat > test.cpp <<EOF
#include <iostream>
int main(int argc, char **argv)
{
try {
throw 10;
} catch (int& e) {
std::cout << "It works!" << std::endl;
}
return 0;
}
EOF
g++ -fexceptions test.cpp && ./a.out
Success would be the output: It works!
Thanks for the support!
-
@terenyi
Thanks now I can reproduce the issue.
-
Found, it will be fixed in next days.
-
Thanks!
-
piCore-7.1beta4 released, see release announcement:
http://forum.tinycorelinux.net/index.php/topic,19934.msg123791.html#msg123791
-
It works. Thank you very much!
-
Bela, can you describe what was the issue?
-
Bela, can you describe what was the issue?
A stupid one, GCC was built with CXXFLAG -fnoexceptions by accident which caused a buggy libstdc++ Interesting enough there were no any error message from configure or in later phases. Simply it was overlooked :(