it's me and wxMozilla again... I got building wxMozilla outside of
wxPython tree running, but the problem is that built binary crashes
immediately. Worse yet, it crashes in places where it absolutely
should not crash (like wxCursor::operator= or wxWindow::SetName). As
far as I can tell libwxmozilla.so was built against wxWindows from
/usr/lib/wxPython and I used helpers.h, pyistream.h and wxPython.h
from CVS to compile SWIG wrapper generated by running
wxswig -c++ -python -shadow -keyword -dnone -D__WXGTK__
-I/home/vasek/softlabs/wxWindows-2.4/wxPython/src -module mozilla
-o mozilla_wrap.cpp mozilla.i
(I tried to mirror exactly what wxPython's build system does, but
probably failed.)
Can you see anything obviously wrong with this? If not then I guess
I'll give up and start lobbying for wxMozilla's inclusion in
wxPython 2.4.0.8 instead
it's me and wxMozilla again... I got building wxMozilla outside of wxPython tree running, but the problem is that built binary crashes immediately. Worse yet, it crashes in places where it absolutely should not crash (like wxCursor::operator= or wxWindow::SetName). As far as I can tell libwxmozilla.so was built against wxWindows from /usr/lib/wxPython and I used helpers.h, pyistream.h and wxPython.h from CVS to compile SWIG wrapper generated by running
wxswig -c++ -python -shadow -keyword -dnone -D__WXGTK__ -I/home/vasek/softlabs/wxWindows-2.4/wxPython/src -module mozilla
-o mozilla_wrap.cpp mozilla.i
(I tried to mirror exactly what wxPython's build system does, but probably failed.)
Can you see anything obviously wrong with this? If not then I guess I'll give up and start lobbying for wxMozilla's inclusion in wxPython 2.4.0.8 instead
I don't see anything obviously wrong, but I don't know why it shouldn't work. I've been meaning to look into this since you mentioned it on the wxMozilla list but havn't had a chance yet.
In my experience, usually when things crash at odd places like that it is because of a mismatch in the vtables. The most typical is a mismatch in __WXDEBUG__ but if you are using the wx-config from /usr/lib/wxPython/bin then that should be taken care of. Is it possible that different versions of gcc could cause this too? The current wxPython binaries were built on a RH 7.3 system which has gcc 2.96. What is on your system?
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
I should add to Vaclav's comments that I've also tried building wxMozilla from within the wxPython tree (I pulled the 2.4.0.7 tarball off of wxPython.org), and I still get the same crash. I haven't tried running SWIG to regenerate the cpp and py files yet though.
Also, Vaclav's changes are not in CVS yet, but a tarball with his mods is available from
The wxPython/contrib/mozilla subdirectory has the .i file and SWIG-generated files.
Thanks,
Kevin
···
On Monday, May 5, 2003, at 04:11 PM, Vaclav Slavik wrote:
Hi,
it's me and wxMozilla again... I got building wxMozilla outside of
wxPython tree running, but the problem is that built binary crashes
immediately. Worse yet, it crashes in places where it absolutely
should not crash (like wxCursor::operator= or wxWindow::SetName). As
far as I can tell libwxmozilla.so was built against wxWindows from
/usr/lib/wxPython and I used helpers.h, pyistream.h and wxPython.h
from CVS to compile SWIG wrapper generated by running
wxswig -c++ -python -shadow -keyword -dnone -D__WXGTK__
-I/home/vasek/softlabs/wxWindows-2.4/wxPython/src -module mozilla
-o mozilla_wrap.cpp mozilla.i
(I tried to mirror exactly what wxPython's build system does, but
probably failed.)
Can you see anything obviously wrong with this? If not then I guess
I'll give up and start lobbying for wxMozilla's inclusion in
wxPython 2.4.0.8 instead
On Monday, May 5, 2003, at 04:38 PM, Robin Dunn wrote:
Vaclav Slavik wrote:
Hi,
it's me and wxMozilla again... I got building wxMozilla outside of wxPython tree running, but the problem is that built binary crashes immediately. Worse yet, it crashes in places where it absolutely should not crash (like wxCursor::operator= or wxWindow::SetName). As far as I can tell libwxmozilla.so was built against wxWindows from /usr/lib/wxPython and I used helpers.h, pyistream.h and wxPython.h from CVS to compile SWIG wrapper generated by running
wxswig -c++ -python -shadow -keyword -dnone -D__WXGTK__ -I/home/vasek/softlabs/wxWindows-2.4/wxPython/src -module mozilla
-o mozilla_wrap.cpp mozilla.i
(I tried to mirror exactly what wxPython's build system does, but probably failed.)
Can you see anything obviously wrong with this? If not then I guess I'll give up and start lobbying for wxMozilla's inclusion in wxPython 2.4.0.8 instead
I don't see anything obviously wrong, but I don't know why it shouldn't work. I've been meaning to look into this since you mentioned it on the wxMozilla list but havn't had a chance yet.
In my experience, usually when things crash at odd places like that it is because of a mismatch in the vtables. The most typical is a mismatch in __WXDEBUG__ but if you are using the wx-config from /usr/lib/wxPython/bin then that should be taken care of. Is it possible that different versions of gcc could cause this too? The current wxPython binaries were built on a RH 7.3 system which has gcc 2.96. What is on your system?
On mine, I've got RH 8 with gcc 3.2. This would explain the problem. Of course, that means that we probably need to proceed with our lobbying initiative... <G>
I should add to Vaclav's comments that I've also tried building
wxMozilla from within the wxPython tree (I pulled the 2.4.0.7
tarball off of wxPython.org), and I still get the same crash. I
haven't tried running SWIG to regenerate the cpp and py files yet
though.
Did you remove all *.h files (so that wxPython's own copy is certainly
used)? If yes, then the SWIG file must be misgenerated
In my experience, usually when things crash at odd places like that
it is because of a mismatch in the vtables.
The weird thing is that it does not jump to functions it shouldn't,
execusion flow looks correct...
The most typical is a
mismatch in __WXDEBUG__ but if you are using the wx-config from
/usr/lib/wxPython/bin then that should be taken care of. Is it
possible that different versions of gcc could cause this too? The
No, I recompiled SRPM package myself w/ gcc 3.2. I thought that it may
be related to using -fno-rtti in wxMozilla, but not even recompiling
wxPython with this flag helped...
The most typical is a
mismatch in __WXDEBUG__ but if you are using the wx-config from
/usr/lib/wxPython/bin then that should be taken care of. Is it
possible that different versions of gcc could cause this too? The
No, I recompiled SRPM package myself w/ gcc 3.2. I thought that it may be related to using -fno-rtti in wxMozilla, but not even recompiling wxPython with this flag helped...
Okay, there is one more possibility that comes to mind. Is there anything in the mozilla headers (or elsewhere that is not normally included) that might change the value of NDEBUG? Or perhaps something like structure alignment?
Otherwise I'll try to find some time to do a build myself and see what I can see.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Okay, there is one more possibility that comes to mind. Is there
anything in the mozilla headers (or elsewhere that is not normally
included) that might change the value of NDEBUG? Or perhaps
something like structure alignment?
There are both (although #pragma pack seems to restore previous state
correctly), but none of affected headers is included by wxMozilla
(checked by grepping automake's .deps directory).
