It might not be strictly a 32bit vs. 64bit issue, but just a matter of luck...
Every code like this reproduces it:
#include <stdint.h>
void do_something();
int main() {
do_something();
return 0;
}
However, by googling around (*) on this issue it becomes clear that throwing exceptions across shared library boundaries is risky and fragile. So in this case we should do what Kultala suggested in IRC: print an error to std::cerr where this is detected and exit(2). Not throw and assume the CLI code is able to catch it through several layers of different plugins/shared libs.
It might not be strictly a 32bit vs. 64bit issue, but just a matter of luck...
Every code like this reproduces it:
#include <stdint.h>
void do_something();
int main() {
do_something();
return 0;
}
However, by googling around (*) on this issue it becomes clear that throwing exceptions across shared library boundaries is risky and fragile. So in this case we should do what Kultala suggested in IRC: print an error to std::cerr where this is detected and exit(2). Not throw and assume the CLI code is able to catch it through several layers of different plugins/shared libs.
(*) www.qtcentre. org/threads/ 4726-exception- in-shared- libraries old.nabble. com/-static- libgcc, -static- libstdc% 2B%2B.a- and-dynamicly- loaded- so-files- td26745112. html stackoverflow. com/questions/ 5044993/ typeinfo- shared- libraries- and-dlopen- without- rtld-global
http://
http://
http://