Just for more fun: here's another visibility-related dynamic_cast error that
I've been seeing. They appear in OS X's system.log, from an application that
AFAIK is *not* started through LaunchServices so that should be able to print
errors to stderr instead of to the system log:
May 8 18:00:28
: [Interest] dynamic_cast failing
On Saturday April 11 2015 18:31:38 Nikos Chantziaras wrote:
Thanks,
You might be hitting some undefined behavior. Do your classes have
virtual functions? If not, dynamic_cast can fail, as it's only supposed
to work with polymorphic classes.
I'll have a look; it's
On 11/04/15 19:27, René J.V. Bertin wrote:
On Saturday April 11 2015 18:31:38 Nikos Chantziaras wrote:
You might be hitting some undefined behavior. Do your classes have
virtual functions? If not, dynamic_cast can fail, as it's only
supposed to work with polymorphic classes.
[...]
However,
On Sun, Apr 12, 2015 at 3:05 PM, René J.V. rjvber...@gmail.com wrote:
That works on Linux, but with the most appropriate way of building plugins
on OS X it doesn't (nor is it possible on MS Windows, AFAIK).
I think that you can have this on OS X if you pass the option -undefined
On Sunday April 12 2015 17:16:46 Jean-Michaël Celerier wrote:
I think that you can have this on OS X if you pass the option -undefined
dynamic_lookup to your linker.
Not with the mode I was referring to, at least I don't think it would allow to
link with objects linked with -bundle .
R.
On Saturday April 11 2015 10:43:14 Thiago Macieira wrote:
Make sure that all classes participating in this party check all these boxes:
* have an export macro in the class declaration
That was the culprit. The dynamically-casted-to class (Okular::ViewerInterface
in this case) didn't have an
On Saturday 11 April 2015 21:50:53 René J.V. Bertin wrote:
Can that be something that behaves differently on different OSes, or using
different C++ runtimes (libstdc++ vs. libc++)?
Runtime, no.
But the OS is a factor. Remember OS X uses Mach-O, and since 10.4 or something
it has used a
On Saturday April 11 2015 10:43:14 Thiago Macieira wrote:
Without concrete code it's difficult to be sure, but the usual suspect in
this
Right now I'm grappling with Okular
(http://quickgit.kde.org/?p=okular.gita=tree), but I've seen the same issue
occur in other KPart based KDE
On Saturday April 11 2015 18:31:38 Nikos Chantziaras wrote:
Thanks,
You might be hitting some undefined behavior. Do your classes have
virtual functions? If not, dynamic_cast can fail, as it's only supposed
to work with polymorphic classes.
I'll have a look; it's not my own code, I'm just
On Saturday 11 April 2015 17:08:45 René J.V. Bertin wrote:
Hi,
I have an issue with some KDE4 code (built against Qt 4.8.6) where a
dynamic_cast fails on OS X but not on Linux (be it with gcc or clang
3.5). In a nutshell:
class D: public class C, public class B, public class A;
Without
On 11/04/15 18:08, René J.V. Bertin wrote:
Hi,
I have an issue with some KDE4 code (built against Qt 4.8.6) where a
dynamic_cast fails on OS X but not on Linux (be it with gcc or clang
3.5).
You might be hitting some undefined behavior. Do your classes have
virtual functions? If not,
Hi,
I have an issue with some KDE4 code (built against Qt 4.8.6) where a
dynamic_cast fails on OS X but not on Linux (be it with gcc or clang
3.5). In a nutshell:
class D: public class C, public class B, public class A;
with C inheriting QObject (ultimately), the others being root
classes. The
12 matches
Mail list logo
