[webkit-help] dylib strangeness

[Tim Prepscius]

Greetings again,

So I've been able to (perhaps) solve my opengl issues, by switching
cocoa basically.  I'm still using agl via the window ref of the cocoa
window.  Seems to function, I wonder if it will fail with some update
of safari.  On a side note, if anyone sees this post while
investigating opengl problems, don't bother with xulrunner on mac!  It
will just be a waste of time.   It took me a while to figure out that
npapi was in webkit as well.


But now I'm seeing some extreme strangeness in other areas.


So I have a Client application.
It is made up of about 20 libraries and a bit of connecting code.

One version links as a windowed executable.
One version links as a plugin.
(depending on which bit of connecting code you use)
However the rest of the code for the application in both cases is
exactly they same.  99.999% of it.


The strangeness I'm seeing is this:
The application version functions without problem both debug and
release.  (as it has done for quite a while).
The plugin version crashes.  But only the optimized non debug build.

And it crashes is weird ways that are reminiscent of out of sync
linking problems.  For instance "dynamic_cast" is failing and causing
a crash in an area nearly impossible.  And that area of code has
existed without problem for 9 years.

There seem to be initialization problems of variables.  Or perhaps a
copy operator/constructor is not being called correctly.



I've spent the last two days investigating what could be causing this.
 It is a mystery, cause the normal application just hums along fine,
while the plugin crashes, not immediately, however in the first 5
seconds or so, as significant events occur.

My leaning is to think there is a problem with gcc and optimized code
in dylibs, perhaps their static initializations are not being
completely performed?  But I must think that the chances of this are
fairly small, as apple uses dylibs everywhere, so they would make sure
that these function correctly.


Has anyone else seen a situation where optimized code doesn't perform
as a dylib, while as an executable it does?  What was the work around?

Or, does anyone know of problems with mixing objective-c and c++ in a dylib?



As of now, I'm trying to isolate the module which causes the problem
in release build, and see if I can isolate the code segment, but it is
slow going, and I'm not sure whether this error will manifest
somewhere else.

-tim