Обсуждение: phase 2 of wxWidgets 2.9 build
I'm glad to see my work to date on wxWidgets 2.9 compatibility has
been committed.
We have 4 (and now, I think, 2) problems:
1. The Flex/Bison headers problem. This is a bit of a mystery. I
e-mailed the Flex users list, and I was informed that neither Flex nor
Bison directly use headers at any point. The "additional C/C++
includes", which has header includes and some additional PgScript
copyright stuff, that is originally in pgsGrammar.yy but doesn't make
it into parser.tab.hh, even though the existing tree parser.tab.hh
does have those includes.
Just fixing that by hacking parser.tab.hh and putting in the includes
alone doesn't make things work again - additional files need to be
hacked, but it can be done.
My new approach to logging variadics has done away with the need to
change the grammar at all, because only logging needed to be changed
there through const wxChar* casts. Someone is going to have to fix
this at some stage if they ever want to change the grammar, but it
need not hold up 2.9 support. It is now a separate, unrelated problem.
2. The wx 2.9 logging problem. My problem here was that I'm wasn't
sure how I should be extending wx logging functionality.
I see that SysLog.cpp has lots of definitions of logger functions like
wxLogSql() . That file (as it exists in master) won't compile against
2.9 currently. Through some indirection with macros, our logger calls
are basically a call to:
#define wxMAKE_LOGGER(level) \
wxLogger(wxLOG_##level, __FILE__, __LINE__, __WXFUNCTION__, wxLOG_COMPONENT)
// this macro generates the expression which logs whatever follows it in
// parentheses at the level specified as argument
#define wxDO_LOG(level) wxMAKE_LOGGER(level).Log
wxLogger is a class defined in log.h
Anyway, I think that the problem has been resolved by #ifdef'ing the
definitions away for 2.9.
3. Linker problems on 2.9 + OGL as they exist on my system. I think
these can be resolved by playing around with the OGL bakefile.
4. The OGL Problem itself. The task of talking to contributors and
getting them to re-licence is ongoing. I suppose we'll have to
integrate OGL, and build it as part of our own build system. Should I
get started on this in anticipation of the re-licensing going ahead?
It would be nice if our Makefile just invoked a separate
makefile/build system for OGL, so OGL remained self-contained and
could easily be used by third parties.
--
Regards,
Peter Geoghegan
On Wed, Feb 2, 2011 at 2:41 AM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > I'm glad to see my work to date on wxWidgets 2.9 compatibility has > been committed. > > We have 4 (and now, I think, 2) problems: I like 2 best. Let's choose that one :-) > 3. Linker problems on 2.9 + OGL as they exist on my system. I think > these can be resolved by playing around with the OGL bakefile. > > 4. The OGL Problem itself. The task of talking to contributors and > getting them to re-licence is ongoing. I suppose we'll have to > integrate OGL, and build it as part of our own build system. Should I > get started on this in anticipation of the re-licensing going ahead? > It would be nice if our Makefile just invoked a separate > makefile/build system for OGL, so OGL remained self-contained and > could easily be used by third parties. I think you should assume we'll go ahead. Every response so far has been positive, including the leading contributor who is responsible for 99% of the code. I don't think we should spend time trying to separate the build. We're not trying to maintain this for third party users - most of them will find the published code usable. It's only a problem for those of us with BSD style licences, and even they could just replace our module.mk files with the equivalent for their projects in a matter of minutes, much as we will replace the bakefile. Will you use the code that Julian sent you, or stick with the original? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 2 February 2011 08:06, Dave Page <dpage@pgadmin.org> wrote: > I like 2 best. Let's choose that one :-) Heh, okay. >> 4. The OGL Problem itself. The task of talking to contributors and >> getting them to re-licence is ongoing. I suppose we'll have to >> integrate OGL, and build it as part of our own build system. Should I >> get started on this in anticipation of the re-licensing going ahead? >> It would be nice if our Makefile just invoked a separate >> makefile/build system for OGL, so OGL remained self-contained and >> could easily be used by third parties. > > I think you should assume we'll go ahead. Every response so far has > been positive, including the leading contributor who is responsible > for 99% of the code. That's what I thought. > I don't think we should spend time trying to separate the build. We're > not trying to maintain this for third party users - most of them will > find the published code usable. It's only a problem for those of us > with BSD style licences, and even they could just replace our > module.mk files with the equivalent for their projects in a matter of > minutes, much as we will replace the bakefile. > > Will you use the code that Julian sent you, or stick with the original? I'm going to work with Julian's new code. -- Regards, Peter Geoghegan
On Wed, Feb 2, 2011 at 3:18 PM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > Find attached linker errors when building against 2.9. > > This doesn't look OGL related. They are all related to wxAUI classes. > Are we missing a build flag or something? I'm investigating. You are missing the aui library for some reason. Try adding 'aui' to the list of libraries in pgadmin3_LDADD in acinclude.m4 (and then run the bootstrap script). -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Find attached linker errors when building against 2.9. This doesn't look OGL related. They are all related to wxAUI classes. Are we missing a build flag or something? I'm investigating. -- Regards, Peter Geoghegan
Вложения
On 2 February 2011 15:26, Dave Page <dpage@pgadmin.org> wrote: > On Wed, Feb 2, 2011 at 3:18 PM, Peter Geoghegan > <peter.geoghegan86@gmail.com> wrote: >> Find attached linker errors when building against 2.9. >> >> This doesn't look OGL related. They are all related to wxAUI classes. >> Are we missing a build flag or something? I'm investigating. > > You are missing the aui library for some reason. Try adding 'aui' to > the list of libraries in pgadmin3_LDADD in acinclude.m4 (and then run > the bootstrap script). It seems that in 2.9, wx-config --libs doesn't give the non-standard libs by default. They must be specified separately. Building... -- Regards, Peter Geoghegan
On 2 February 2011 15:33, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: Now just a single linker error: undefined reference to `wxBitmapComboBox::Insert(wxString const&, wxBitmap const&, unsigned int, void*) I've now appended adv to pgadmin3_LDADD, and am building again... -- Regards, Peter Geoghegan
Well, none of that has worked. However, considering this:
[peter@localhost local]$ nm -D
/usr/local/lib/libwx_gtk2u_adv-2.9.so.1.0.0 | grep wxBitmapComboBox |
grep Insert | c++filt
000000000016b8b0 T wxBitmapComboBox::SetInsertionPoint(long)
000000000016ce10 T
wxBitmapComboBox::GTKInsertComboBoxTextItem(unsigned int, wxString
const&)
000000000016ca70 T wxBitmapComboBox::Insert(wxString const&, wxBitmap
const&, unsigned int)
000000000016cc10 T wxBitmapComboBox::Insert(wxString const&, wxBitmap
const&, unsigned int, wxClientData*)
*snip*
I find it hard to argue with my linker on this one - the last function
should have a void* as its last parameter. I suspect a bug in 2.9.1 .
Changing this:
cbConnection->Insert(newconn->GetName(),
CreateBitmap(GetServerColour(newconn)), sel, newconn);
to this:
cbConnection->Insert(newconn->GetName(),
CreateBitmap(GetServerColour(newconn)), sel, (wxClientData*)newconn);
so that the wxClientData* overload rather than the void* overload is
called seems to have fixed the problem.
We have a complete 2.9 build!
[peter@localhost pgadmin]$ ldd pgadmin3
linux-vdso.so.1 => (0x00007fffc7bff000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000003195c00000)
libwx_gtk2u_stc-2.9.so.1 => /usr/local/lib/libwx_gtk2u_stc-2.9.so.1
(0x00007fbb05ecf000)
libwxcode_gtk2u_ogl-2.9.so.0 =>
/usr/local/lib/libwxcode_gtk2u_ogl-2.9.so.0 (0x00007fbb05c44000)
libwx_gtk2u_aui-2.9.so.1 => /usr/local/lib/libwx_gtk2u_aui-2.9.so.1
(0x00007fbb05989000)
libwx_gtk2u_xrc-2.9.so.1 => /usr/local/lib/libwx_gtk2u_xrc-2.9.so.1
(0x00007fbb05605000)
libwx_gtk2u_html-2.9.so.1 => /usr/local/lib/libwx_gtk2u_html-2.9.so.1
(0x00007fbb052bc000)
libwx_gtk2u_qa-2.9.so.1 => /usr/local/lib/libwx_gtk2u_qa-2.9.so.1
(0x00007fbb05061000)
libwx_gtk2u_adv-2.9.so.1 => /usr/local/lib/libwx_gtk2u_adv-2.9.so.1
(0x00007fbb04c62000)
libwx_gtk2u_core-2.9.so.1 => /usr/local/lib/libwx_gtk2u_core-2.9.so.1
(0x00007fbb04355000)
libwx_baseu_xml-2.9.so.1 => /usr/local/lib/libwx_baseu_xml-2.9.so.1
(0x00007fbb04119000)
libwx_baseu_net-2.9.so.1 => /usr/local/lib/libwx_baseu_net-2.9.so.1
(0x00007fbb03eb7000)
libwx_baseu-2.9.so.1 => /usr/local/lib/libwx_baseu-2.9.so.1
(0x00007fbb0397c000)
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0000003195400000)
libz.so.1 => /lib64/libz.so.1 (0x000000318a600000)
libxslt.so.1 => /usr/lib64/libxslt.so.1 (0x00000031a0400000)
libm.so.6 => /lib64/libm.so.6 (0x000000318a200000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x0000003196000000)
libpq.so.5 => /usr/local/pgsql/lib/libpq.so.5 (0x00007fbb03756000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x000000318fa00000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000318aa00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003189600000)
libc.so.6 => /lib64/libc.so.6 (0x0000003189200000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003195000000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003193800000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003196c00000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003195800000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x000000318ce00000)
libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x0000003639c00000)
libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x0000003639400000)
libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x0000003194800000)
libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x0000003191200000)
libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x0000003192800000)
libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0
(0x0000003193400000)
libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x000000318de00000)
libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x0000003192000000)
libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x000000318d200000)
libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x000000318da00000)
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x000000318b600000)
libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x0000003190200000)
libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x000000318b200000)
librt.so.1 => /lib64/librt.so.1 (0x0000003189e00000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x000000318ae00000)
libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x0000003198800000)
libSM.so.6 => /usr/lib64/libSM.so.6 (0x00000034ca200000)
libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x000000319c000000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003189a00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003188e00000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x000000318ba00000)
libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0
(0x0000003639000000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x000000318c600000)
libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x000000318e600000)
libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x0000003639800000)
libXext.so.6 => /usr/lib64/libXext.so.6 (0x000000318d600000)
libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x000000318ee00000)
libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x000000318ea00000)
libXi.so.6 => /usr/lib64/libXi.so.6 (0x000000318e200000)
libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x000000318f200000)
libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x000000318f600000)
libXcomposite.so.1 => /usr/lib64/libXcomposite.so.1 (0x0000003194c00000)
libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x0000003191800000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x000000318ca00000)
libICE.so.6 => /usr/lib64/libICE.so.6 (0x0000003190600000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00000034c9e00000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x000000318be00000)
libpixman-1.so.0 => /usr/lib64/libpixman-1.so.0 (0x0000003193000000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x000000318c200000)
Now to investigate this assertion failure, that I see plenty of:
/usr/local/include/wx-2.9/wx/strvararg.h(449): assert "(argtype &
(wxFormatStringSpecifier<T>::value)) == argtype" failed in
wxArgNormalizer(): format specifier doesn't match argument type
ASSERT INFO:
/usr/local/include/wx-2.9/wx/strvararg.h(449): assert "(argtype &
(wxFormatStringSpecifier<T>::value)) == argtype" failed in
wxArgNormalizer(): format specifier doesn't match argument type
BACKTRACE:
[1] wxOnAssert(char const*, int, char const*, char const*, char const*)
[2] wxArgNormalizer() /usr/local/include/wx-2.9/wx/strvararg.h:449
[3] wxArgNormalizerUtf8() /usr/local/include/wx-2.9/wx/strvararg.h:481
[4] int wxString::Printf<unsigned long>(wxFormatString const&,
unsigned long) /usr/local/include/wx-2.9/wx/string.h:2305
[5] pgCollection::UpdateChildCount(ctlTree*, int)
/home/peter/pgadmin3/pgadmin/./schema/pgCollection.cpp:93
*SNIP*
We seem to just get an assertion failure when refreshing an expanded
node where we would have crashed before. Progress.
I've attached:
A patch for anyone that wants to reproduce this. It doesn't break the 2.8 build.
A screenshot, which seems to show some minor problems with this build
of pgAdmin, that are probably related to AUI in some way.
--
Regards,
Peter Geoghegan
Вложения
On Wed, Feb 2, 2011 at 6:23 PM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > Well, none of that has worked. However, considering this: > > [peter@localhost local]$ nm -D > /usr/local/lib/libwx_gtk2u_adv-2.9.so.1.0.0 | grep wxBitmapComboBox | > grep Insert | c++filt > 000000000016b8b0 T wxBitmapComboBox::SetInsertionPoint(long) > 000000000016ce10 T > wxBitmapComboBox::GTKInsertComboBoxTextItem(unsigned int, wxString > const&) > 000000000016ca70 T wxBitmapComboBox::Insert(wxString const&, wxBitmap > const&, unsigned int) > 000000000016cc10 T wxBitmapComboBox::Insert(wxString const&, wxBitmap > const&, unsigned int, wxClientData*) > *snip* > > I find it hard to argue with my linker on this one - the last function > should have a void* as its last parameter. I suspect a bug in 2.9.1 . Hmm, the docs for both 2.8 and 2.9 show 3 Insert members - one with three parameters and 2 with 4, one with wxClientData* and one with void*. Certainly looks like an issue. > Changing this: > cbConnection->Insert(newconn->GetName(), > CreateBitmap(GetServerColour(newconn)), sel, newconn); > to this: > cbConnection->Insert(newconn->GetName(), > CreateBitmap(GetServerColour(newconn)), sel, (wxClientData*)newconn); > > so that the wxClientData* overload rather than the void* overload is > called seems to have fixed the problem. Yup. > We have a complete 2.9 build! Wahoo! Nice work Sir! > Now to investigate this assertion failure, that I see plenty of: > > /usr/local/include/wx-2.9/wx/strvararg.h(449): assert "(argtype & > (wxFormatStringSpecifier<T>::value)) == argtype" failed in > wxArgNormalizer(): format specifier doesn't match argument type > > ASSERT INFO: > /usr/local/include/wx-2.9/wx/strvararg.h(449): assert "(argtype & > (wxFormatStringSpecifier<T>::value)) == argtype" failed in > wxArgNormalizer(): format specifier doesn't match argument type > > BACKTRACE: > [1] wxOnAssert(char const*, int, char const*, char const*, char const*) > [2] wxArgNormalizer() /usr/local/include/wx-2.9/wx/strvararg.h:449 > [3] wxArgNormalizerUtf8() /usr/local/include/wx-2.9/wx/strvararg.h:481 > [4] int wxString::Printf<unsigned long>(wxFormatString const&, > unsigned long) /usr/local/include/wx-2.9/wx/string.h:2305 > [5] pgCollection::UpdateChildCount(ctlTree*, int) > /home/peter/pgadmin3/pgadmin/./schema/pgCollection.cpp:93 > *SNIP* > > We seem to just get an assertion failure when refreshing an expanded > node where we would have crashed before. Progress. :-) > I've attached: > > A patch for anyone that wants to reproduce this. It doesn't break the 2.8 build. > > A screenshot, which seems to show some minor problems with this build > of pgAdmin, that are probably related to AUI in some way. Thanks Peter, great work. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 2 February 2011 18:51, Dave Page <dpage@pgadmin.org> wrote:
>> so that the wxClientData* overload rather than the void* overload is
>> called seems to have fixed the problem.
>
> Yup.
The problem is that the c style cast is equivalent to a
reinterpret_cast<>() (part of the reason why I avoid C style casts in
C++). We're technically resorting to undefined behaviour here. Time to
ping the wx guys about the linker thing I suppose. It might be fixed
in wx SVN. I'll check tomorrow.
>> We have a complete 2.9 build!
>
> Wahoo! Nice work Sir!
Thanks.
I'm going to clean up your commit from the other day per your
suggestion. I'm also going to get started on moving OGL into the tree,
and building it ourselves.
I've noticed that the sample OGL applications have obvious bugs in
them, probably because of my cursory fixes to get them to work against
2.9. I wasn't too worried about it at the time. Should I be now? I'll
certainly want to clean up numerous OGL compiler warnings.
I'm seeing some errors like this:
An error has occurred:
XRC error: file:/home/peter/pgadmin3/pgadmin/ui/dlgTable.xrc:6:
unknown style flag "wxRESIZE_BOX"
...and...
An error has occurred:
XRC error: file:/home/peter/pgadmin3/pgadmin/ui/frmHint.xrc:6: unknown
style flag "wxTHICK_FRAME"
Any suggestions on a good place to attack to remove the probable AUI
related weirdness? Sometimes the "Object browser" header (i.e. where
it says object browser) isn't visible. the other panes seem unaffected
though. Object browser seems well behaved when docked anywhere other
than its default position.
There's this too, which I see when I start the SQL editor:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000460063 in wxWindowBase::GetSize (this=0xd9d9abab8686)
at /usr/local/include/wx-2.9/wx/window.h:321
321 DoGetSize(& w, & h);
(gdb) bt
#0 0x0000000000460063 in wxWindowBase::GetSize (this=0xd9d9abab8686)
at /usr/local/include/wx-2.9/wx/window.h:321
#1 0x00000000008024b1 in gqbSplitter::onVerticalSashResize (this=0x18bbb40,
event=...) at ./gqb/gqbController.cpp:596
#2 0x00007ffff577349d in
wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&,
wxEvent&) const () from /usr/local/lib/libwx_baseu-2.9.so.1
#3 0x00007ffff598dcf1 in
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&,
wxEvtHandler*, wxEvent&) ()
from /usr/local/lib/libwx_baseu-2.9.so.1
#4 0x00007ffff598de53 in wxEventHashTable::HandleEvent(wxEvent&,
wxEvtHandler*) () from /usr/local/lib/libwx_baseu-2.9.so.1
#5 0x00007ffff598e1e3 in wxEvtHandler::ProcessEventLocally(wxEvent&) ()
from /usr/local/lib/libwx_baseu-2.9.so.1
#6 0x00007ffff598e25d in wxEvtHandler::ProcessEvent(wxEvent&) ()
from /usr/local/lib/libwx_baseu-2.9.so.1
#7 0x00007ffff65fb611 in wxSplitterWindow::DoSendEvent(wxSplitterEvent&) ()
from /usr/local/lib/libwx_gtk2u_core-2.9.so.1
#8 0x00007ffff65fbce9 in wxSplitterWindow::SetSashPositionAndNotify(int) ()
from /usr/local/lib/libwx_gtk2u_core-2.9.so.1
#9 0x00007ffff65fbeb9 in wxSplitterWindow::OnSize(wxSizeEvent&) ()
from /usr/local/lib/libwx_gtk2u_core-2.9.so.1
I see this, which prevents me from calling the edit table dialog:
An error has occurred:
XRC error: file:/home/peter/pgadmin3/pgadmin/ui/dlgTable.xrc:330: too
many children in grid sizer: 36 > 3 x 11 (consider omitting the number
of rows or columns)
I expect to fix quite a few bugs tomorrow. My feeling is that we're
past the worst of it though. I'd like to close phase 2 by having a
pgAdmin III that builds against 2.9 with no obvious defects, but
doesn't yet have OGL in the tree. We'll then have something to commit
before moving on to phase 3, bringing OGL into the pgAdmin tree and
building it ourselves. Thoughts?
--
Regards,
Peter Geoghegan
On Thu, Feb 3, 2011 at 3:00 AM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > > I'm going to clean up your commit from the other day per your > suggestion. I'm also going to get started on moving OGL into the tree, > and building it ourselves. OK. > I've noticed that the sample OGL applications have obvious bugs in > them, probably because of my cursory fixes to get them to work against > 2.9. I wasn't too worried about it at the time. Should I be now? I'll > certainly want to clean up numerous OGL compiler warnings. We won't be including the sample apps in our tree. Probably just headers in pgadmin/include/ogl and required source in pgadmin/ogl > I'm seeing some errors like this: > > An error has occurred: > > XRC error: file:/home/peter/pgadmin3/pgadmin/ui/dlgTable.xrc:6: > unknown style flag "wxRESIZE_BOX" > > ...and... > > An error has occurred: > > XRC error: file:/home/peter/pgadmin3/pgadmin/ui/frmHint.xrc:6: unknown > style flag "wxTHICK_FRAME" Hmm, interesting. Is that coming from wxrc, or when building xrcDialogs.cpp? > Any suggestions on a good place to attack to remove the probable AUI > related weirdness? Sometimes the "Object browser" header (i.e. where > it says object browser) isn't visible. the other panes seem unaffected > though. Object browser seems well behaved when docked anywhere other > than its default position. My first suggestion would be to select the "Default View" option, and see if that helps. Failing that, comment out the code that sets either the default or the stored perspective, and see what happens if you let the controls figure out their own default layout. > There's this too, which I see when I start the SQL editor: > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000460063 in wxWindowBase::GetSize (this=0xd9d9abab8686) > at /usr/local/include/wx-2.9/wx/window.h:321 > 321 DoGetSize(& w, & h); > (gdb) bt > #0 0x0000000000460063 in wxWindowBase::GetSize (this=0xd9d9abab8686) > at /usr/local/include/wx-2.9/wx/window.h:321 > #1 0x00000000008024b1 in gqbSplitter::onVerticalSashResize (this=0x18bbb40, > event=...) at ./gqb/gqbController.cpp:596 > #2 0x00007ffff577349d in > wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, > wxEvent&) const () from /usr/local/lib/libwx_baseu-2.9.so.1 > #3 0x00007ffff598dcf1 in > wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, > wxEvtHandler*, wxEvent&) () > from /usr/local/lib/libwx_baseu-2.9.so.1 > #4 0x00007ffff598de53 in wxEventHashTable::HandleEvent(wxEvent&, > wxEvtHandler*) () from /usr/local/lib/libwx_baseu-2.9.so.1 > #5 0x00007ffff598e1e3 in wxEvtHandler::ProcessEventLocally(wxEvent&) () > from /usr/local/lib/libwx_baseu-2.9.so.1 > #6 0x00007ffff598e25d in wxEvtHandler::ProcessEvent(wxEvent&) () > from /usr/local/lib/libwx_baseu-2.9.so.1 > #7 0x00007ffff65fb611 in wxSplitterWindow::DoSendEvent(wxSplitterEvent&) () > from /usr/local/lib/libwx_gtk2u_core-2.9.so.1 > #8 0x00007ffff65fbce9 in wxSplitterWindow::SetSashPositionAndNotify(int) () > from /usr/local/lib/libwx_gtk2u_core-2.9.so.1 > #9 0x00007ffff65fbeb9 in wxSplitterWindow::OnSize(wxSizeEvent&) () > from /usr/local/lib/libwx_gtk2u_core-2.9.so.1 Trying to get the size of something before it's drawn perhaps? > I see this, which prevents me from calling the edit table dialog: > > An error has occurred: > > XRC error: file:/home/peter/pgadmin3/pgadmin/ui/dlgTable.xrc:330: too > many children in grid sizer: 36 > 3 x 11 (consider omitting the number > of rows or columns) Probably a simple counting error. I suspect theres just one row too many. > I expect to fix quite a few bugs tomorrow. My feeling is that we're > past the worst of it though. I'd like to close phase 2 by having a > pgAdmin III that builds against 2.9 with no obvious defects, but > doesn't yet have OGL in the tree. We'll then have something to commit > before moving on to phase 3, bringing OGL into the pgAdmin tree and > building it ourselves. Thoughts? Sounds like a plan! -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
I'm not sure how to deal with the apparent removal of the wxRESIZE_BOX and wxTHICK_FRAME style flags. The removal of wxRESIZE_BOX is documented here: http://trac.wxwidgets.org/ticket/9735 . Does anyone have any particular feelings on what should be done, other than "suck it and see"? -- Regards, Peter Geoghegan
On Mon, Feb 7, 2011 at 7:26 PM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > I'm not sure how to deal with the apparent removal of the wxRESIZE_BOX > and wxTHICK_FRAME style flags. > > The removal of wxRESIZE_BOX is documented here: > http://trac.wxwidgets.org/ticket/9735 . > > Does anyone have any particular feelings on what should be done, other > than "suck it and see"? I can't find any documentation (even for 2.6) for either, except the one line mentioned in that ticket. I suspect these styles have been obsolete for a long time. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
I've fixed the SQL editor segfault - it was a wild pointer dereference. I don't currently know what condition has changed in the 2.9 to make both gqbSplitter::tablesBrowser gqbSplitter::browserPanel not initialised to something valid when onVerticalSashResize() is called, so now we just check if they're null or not there. They're now explicitly initialised to NULL. Styles were removed without any apparent side effects, except making the error go away. I've isolated the table view segfault. -- Regards, Peter Geoghegan
Seemingly many of those wxString::Printf( ) assertion failures that I now see are actually bugs in wx 2.9.1 . I'm now working with wxWidgets SVN head, and suggest that anyone that wants to help with or recreate my work do the same. As we all know, 2.9/3.0 support isn't something of much practical use until wxWidgets 3.0 packages are available on popular platforms. Also, the ticket that reported this bug and included a patch is six months old. It doesn't appear as if the wx guys can be bothered producing many point releases for development branches. -- Regards, Peter Geoghegan
Most runtime bugs are now fixed. The only two that I know of at the moment (although I just built wx SVN in the last two hours) is the distortion of AUI widgets and the disappearance of our splashscreen, which I didn't see against 2.9.1 . Many of the bugs are fixed by just building against wxWidgets SVN head, so it's essential that we work from that. For your convenience: svn checkout http://svn.wxwidgets.org/svn/wx/wxWidgets/trunk wxWidgets -- Regards, Peter Geoghegan
I have more progress to report. In the few cases when I saw errors like this: XRC error: file:/home/peter/pgadmin3/pgadmin/ui/dlgIndexConstraint.xrc:170: too many children in grid sizer: 8 > 2 x 2 (consider omitting the number of rows or columns) I simply removed the number of rows, and left the number of columns as-is in each of the affected xrc files. Everything appears alright, across wx versions. I made a bug report, and that linker error on the Insert() member function is now gone when building against wx SVN trunk (revision 66869). The implementation was simply omitted in their tree. Our splashscreen has yet to re-appear, which, as I've said, isn't a problem in 2.9.1, just in 2.9.2 devel/SVN head. The only other problem that remains that I'm currently aware of is the AUI grey overlay thing, which is prominent on the object browser, but also appears on the toolbar to the right of its buttons. For some reason, when I drag the object browser to the right of the main form, that problem goes away. More work is required to figure out why this is happening, but I don't have any leads at the moment. Selectively commenting out code that sets either the default or the stored perspective per Dave's suggestion hasn't helped. It's probably time to ask the wx-user list what they think. I've attached images that show differences between 2.8 and 2.9 in this regard. I've also attached a patch that shows my work to date. The patch doesn't affect the 2.8 build's behaviour, but makes 2.9 builds complete successfully (if you transfer the OGL headers so that they're in the same place as they were for 2.8, of course). By the way, the "refresh expanded node" bug appears to have gone now. It doesn't cause an assertion failure or anything else, which suggests that it wasn't our fault to begin with. -- Regards, Peter Geoghegan
Вложения
On Thu, Feb 10, 2011 at 12:17 AM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > Our splashscreen has yet to re-appear, which, as I've said, isn't a > problem in 2.9.1, just in 2.9.2 devel/SVN head. The only other problem > that remains that I'm currently aware of is the AUI grey overlay > thing, which is prominent on the object browser, but also appears on > the toolbar to the right of its buttons. For some reason, when I drag > the object browser to the right of the main form, that problem goes > away. iirc, there's some code in events.cpp which skips certain types of background redraw. Try commenting that out. > By the way, the "refresh expanded node" bug appears to have gone now. > It doesn't cause an assertion failure or anything else, which suggests > that it wasn't our fault to begin with. :-) -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 10 February 2011 03:04, Dave Page <dpage@pgadmin.org> wrote: > iirc, there's some code in events.cpp which skips certain types of > background redraw. Try commenting that out. Perhaps you should commit my earlier patch. It's very difficult to predict how long it will take to figure this out. By the way, your earlier commit "Implement a more reliable method for detecting changes to the focussed" broke 2.9 compatibility, which I've fixed. -- Regards, Peter Geoghegan
On Thu, Feb 10, 2011 at 2:35 PM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > On 10 February 2011 03:04, Dave Page <dpage@pgadmin.org> wrote: >> iirc, there's some code in events.cpp which skips certain types of >> background redraw. Try commenting that out. > > Perhaps you should commit my earlier patch. It's very difficult to > predict how long it will take to figure this out. Done. > By the way, your earlier commit "Implement a more reliable method for > detecting changes to the focussed" broke 2.9 compatibility, which I've > fixed. D'oh! Please send that over. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 10 February 2011 22:22, Dave Page <dpage@pgadmin.org> wrote: > D'oh! Please send that over. It's included in the patch. I did the "git stash; git pull; git stash pop" trick. -- Regards, Peter Geoghegan
On Thu, Feb 10, 2011 at 11:49 PM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > On 10 February 2011 22:22, Dave Page <dpage@pgadmin.org> wrote: > >> D'oh! Please send that over. > > It's included in the patch. I did the "git stash; git pull; git stash > pop" trick. Oh, OK - so what is in GIT now should build with wx2.9 from SVN (bar OGL of course)? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 10 February 2011 23:01, Dave Page <dpage@pgadmin.org> wrote: > Oh, OK - so what is in GIT now should build with wx2.9 from SVN (bar > OGL of course)? Yes. You'll want to build OGL against 2.9 SVN too, obviously. I don't think I made available a version that builds cleanly against 2.9, but you independently did that yourself anyway, right? By the way, I missed one of the "(consider omitting number of rows or columns)" problems on the options dialog earlier. I may have missed others, but obviously that won't affect 2.8 builds. -- Regards, Peter Geoghegan
On 2/11/11, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > On 10 February 2011 23:01, Dave Page <dpage@pgadmin.org> wrote: >> Oh, OK - so what is in GIT now should build with wx2.9 from SVN (bar >> OGL of course)? > > Yes. You'll want to build OGL against 2.9 SVN too, obviously. I don't > think I made available a version that builds cleanly against 2.9, but > you independently did that yourself anyway, right? Can u send me the code from Julian please? > By the way, I missed one of the "(consider omitting number of rows or > columns)" problems on the options dialog earlier. I may have missed > others, but obviously that won't affect 2.8 builds. I don't believe I've had a patch with any of that yet. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 10 February 2011 23:31, Dave Page <dpage@pgadmin.org> wrote:
> Can u send me the code from Julian please?
I assume you want me to send you the new, improved OGL from Julian +
my fixes to make it build against 2.9, which I myself am using . I'll
send it to you later, because I don't have it at the moment.
>> By the way, I missed one of the "(consider omitting number of rows or
>> columns)" problems on the options dialog earlier. I may have missed
>> others, but obviously that won't affect 2.8 builds.
>
> I don't believe I've had a patch with any of that yet.
You have. Changes look like this:
<object class="sizeritem">
<object class="wxFlexGridSizer">
<cols>2</cols>
- <rows>2</rows>
<vgap>5</vgap>
I remove the row per the suggestion of the wx error message. That has
no apparent effect, other than making the error go away.
--
Regards,
Peter Geoghegan
On Fri, Feb 11, 2011 at 12:44 AM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > On 10 February 2011 23:31, Dave Page <dpage@pgadmin.org> wrote: >> Can u send me the code from Julian please? > > I assume you want me to send you the new, improved OGL from Julian + > my fixes to make it build against 2.9, which I myself am using . I'll > send it to you later, because I don't have it at the moment. Or just what he sent - it didn't take long to fix it up last time. I see it now though anyway... thanks! >>> By the way, I missed one of the "(consider omitting number of rows or >>> columns)" problems on the options dialog earlier. I may have missed >>> others, but obviously that won't affect 2.8 builds. >> >> I don't believe I've had a patch with any of that yet. > > You have. Changes look like this: > > <object class="sizeritem"> > <object class="wxFlexGridSizer"> > <cols>2</cols> > - <rows>2</rows> > <vgap>5</vgap> > > I remove the row per the suggestion of the wx error message. That has > no apparent effect, other than making the error go away. I saw your description of the fix, but I didn't see a patch to go with it. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 11 February 2011 03:34, Dave Page <dpage@pgadmin.org> wrote: > Or just what he sent - it didn't take long to fix it up last time. I > see it now though anyway... thanks! Are you going to integrate it into our tree, or do you just want to see what I see? -- Regards, Peter Geoghegan
On Fri, Feb 11, 2011 at 1:07 PM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > On 11 February 2011 03:34, Dave Page <dpage@pgadmin.org> wrote: >> Or just what he sent - it didn't take long to fix it up last time. I >> see it now though anyway... thanks! > > Are you going to integrate it into our tree, or do you just want to > see what I see? The latter, but I'll do the former to get there I expect. Unless you've done all the work already? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 11 February 2011 12:54, Dave Page <dpage@pgadmin.org> wrote: > The latter, but I'll do the former to get there I expect. Unless > you've done all the work already? No, I haven't. I imagine you want to do it a certain way, and I might have my own ideas, so there isn't much point in proceeding until we have consensus. -- Regards, Peter Geoghegan
On Fri, Feb 11, 2011 at 6:01 PM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > Can you try again please? That appears to just be an empty file. Crap - sorry. Did a git diff, not a git diff --cached. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
Can you try again please? That appears to just be an empty file. -- Regards, Peter Geoghegan
On Fri, Feb 11, 2011 at 2:13 PM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > On 11 February 2011 12:54, Dave Page <dpage@pgadmin.org> wrote: > >> The latter, but I'll do the former to get there I expect. Unless >> you've done all the work already? > > No, I haven't. I imagine you want to do it a certain way, and I might > have my own ideas, so there isn't much point in proceeding until we > have consensus. OK, here's a patch. I haven't touched the VC++ project files yet, but it includes all the required changes to the autotools build system. Minimally invasive, and builds fine on 2.8. Haven't yet tried 2.9. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
I'm building it now. Should the OGL headers really be in a wx directory of their own? My instinct is "no". -- Regards, Peter Geoghegan
On Fri, Feb 11, 2011 at 6:57 PM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > I'm building it now. > > Should the OGL headers really be in a wx directory of their own? My > instinct is "no". I just did that to avoid editing all the source files. It's no biggie to change though. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 11 February 2011 19:44, Dave Page <dpage@pgadmin.org> wrote: > On Fri, Feb 11, 2011 at 6:57 PM, Peter Geoghegan > <peter.geoghegan86@gmail.com> wrote: >> I'm building it now. >> >> Should the OGL headers really be in a wx directory of their own? My >> instinct is "no". > > I just did that to avoid editing all the source files. It's no biggie > to change though. Alright, I'll fix it. We actually don't include it in that many source files. Since you didn't apply my earlier phase 2 patch, I suppose we'll leave it until I produce a patch that fixes absolutely everything except the AUI weirdness and the splashscreen thing. -- Regards, Peter Geoghegan
On Fri, Feb 11, 2011 at 8:50 PM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > On 11 February 2011 19:44, Dave Page <dpage@pgadmin.org> wrote: >> On Fri, Feb 11, 2011 at 6:57 PM, Peter Geoghegan >> <peter.geoghegan86@gmail.com> wrote: >>> I'm building it now. >>> >>> Should the OGL headers really be in a wx directory of their own? My >>> instinct is "no". >> >> I just did that to avoid editing all the source files. It's no biggie >> to change though. > > Alright, I'll fix it. We actually don't include it in that many source files. > > Since you didn't apply my earlier phase 2 patch, I suppose we'll leave > it until I produce a patch that fixes absolutely everything except the > AUI weirdness and the splashscreen thing. I did apply the earlier patch - the one you sent on 2nd Feb. I can't find any others. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 11 February 2011 20:28, Dave Page <dpage@pgadmin.org> wrote: > I did apply the earlier patch - the one you sent on 2nd Feb. I can't > find any others. I'm referring to wx29_phase2_first.patch - sent on 9th of Feb. You said this shortly afterwards: >> Perhaps you should commit my earlier patch. It's very difficult to >> predict how long it will take to figure this out. > Done. I guess it was a misunderstanding. It doesn't matter now though. I'll concentrate on producing a new patch that includes everything we've already done. -- Regards, Peter Geoghegan
I've found more problems with wx 2.9. Specifically, I seem to be having some problems with the table editor. Segfaults occur when I edit columns of specific datatypes. I'm using the dellstore2 sample database, available from http://pgfoundry.org/projects/dbsamples/. The following datatypes segfault when I press return to commit changes: SERIAL (though, curiously, not integer, even when it's our PK) text/varchar(n) date The following do not: integer numeric This occurs on the debug and release builds. Here's a stacktrace from when I modify a varchar(50) field, country, from dellstore2's customers table: Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00007ffff6b1f710 in wxGridCellTextEditor::EndEdit(int, int, wxGrid const*, wxString const&, wxString*) () from /usr/local/lib/libwx_gtk2u_adv-2.9.so.2 #2 0x00007ffff6b050b2 in wxGrid::SaveEditControlValue() () from /usr/local/lib/libwx_gtk2u_adv-2.9.so.2 #3 0x00007ffff6b06083 in wxGrid::EnableCellEditControl(bool) () from /usr/local/lib/libwx_gtk2u_adv-2.9.so.2 #4 0x00007ffff586066d in wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const () from /usr/local/lib/libwx_baseu-2.9.so.2 #5 0x00007ffff5a3b2c1 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from /usr/local/lib/libwx_baseu-2.9.so.2 #6 0x00007ffff5a3b41c in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from /usr/local/lib/libwx_baseu-2.9.so.2 #7 0x00007ffff5a3b713 in wxEvtHandler::ProcessEventLocally(wxEvent&) () from /usr/local/lib/libwx_baseu-2.9.so.2 #8 0x00007ffff5a3b781 in wxEvtHandler::ProcessEvent(wxEvent&) () from /usr/local/lib/libwx_baseu-2.9.so.2 #9 0x00007ffff5a3b527 in wxEvtHandler::SafelyProcessEvent(wxEvent&) () from /usr/local/lib/libwx_baseu-2.9.so.2 #10 0x00007ffff63d6cbb in wxWindow::GTKHandleFocusOutNoDeferring() () from /usr/local/lib/libwx_gtk2u_core-2.9.so.2 #11 0x00007ffff63d6d60 in wxWindow::GTKHandleFocusOut() () from /usr/local/lib/libwx_gtk2u_core-2.9.so.2 #12 0x00007ffff63d6d7c in gtk_window_focus_out_callback () from /usr/local/lib/libwx_gtk2u_core-2.9.so.2 #13 0x00000032b874e223 in _gtk_marshal_BOOLEAN__BOXED (closure=0x184e5f0, return_value=0x7fffffffc470, n_param_values=<value optimized out>, param_values= 0x18418a0, invocation_hint=<value optimized out>, marshal_data=<value optimized out>) at gtkmarshalers.c:86 #14 0x00000032b020e03e in g_closure_invoke (closure=0x184e5f0, return_value=0x7fffffffc470, n_param_values=2, param_values=0x18418a0, invocation_hint= 0x7fffffffc430) at gclosure.c:766 #15 0x00000032b021ee87 in signal_emit_unlocked_R (node=<value optimized out>, detail=0, instance=0x1698290, emission_return=0x7fffffffc5e0, instance_and_params=0x18418a0) at gsignal.c:3252 #16 0x00000032b0228555 in g_signal_emit_valist (instance=<value optimized out>, signal_id=<value optimized out>, detail=<value optimized out>, var_args=<value optimized out>) at gsignal.c:2993 #17 0x00000032b0228983 in g_signal_emit (instance=<value optimized out>, signal_id=<value optimized out>, detail=<value optimized out>) at gsignal.c:3040 #18 0x00000032b8885aef in gtk_widget_event_internal (widget=0x1698290 [wxPizza], event=0x181df30) at gtkwidget.c:4992 #19 0x00000032b8893cf1 in IA__gtk_widget_send_focus_change (widget=0x1698290 [wxPizza], event=0x181df30) at gtkwidget.c:11416 #20 0x00000032b8893ef2 in do_focus_change (widget=0x1698290 [wxPizza], in=0) at gtkwindow.c:5304 #21 0x00000032b88957ea in gtk_window_real_set_focus (window=0x161ee20 [GtkWindow], focus=0x0) at gtkwindow.c:5508 #22 0x00000032b020e03e in g_closure_invoke (closure=0xf3aef0, return_value=0x0, n_param_values=2, param_values=0x16b8d20, invocation_hint=0x7fffffffc910) at gclosure.c:766 #23 0x00000032b021ec98 in signal_emit_unlocked_R (node=<value optimized out>, detail=0, instance=0x161ee20, emission_return=0x0, instance_and_params= 0x16b8d20) at gsignal.c:3290 #24 0x00000032b02287b5 in g_signal_emit_valist (instance=<value optimized out>, signal_id=<value optimized out>, detail=<value optimized out>, var_args=<value optimized out>) at gsignal.c:2983 #25 0x00000032b0228983 in g_signal_emit (instance=<value optimized out>, signal_id=<value optimized out>, detail=<value optimized out>) at gsignal.c:3040 #26 0x00000032b889cd3d in _gtk_window_unset_focus_and_default (window=0x161ee20 [GtkWindow], widget=0x1719490 [GtkScrolledWindow]) at gtkwindow.c:5590 #27 0x00000032b888e663 in IA__gtk_widget_hide (widget=0x1719490 [GtkScrolledWindow]) at gtkwidget.c:3303 #28 0x00007ffff63d567d in wxWindow::Show(bool) () from /usr/local/lib/libwx_gtk2u_core-2.9.so.2 #29 0x00007ffff6b1df92 in wxGridCellEditor::Show(bool, wxGridCellAttr*) () from /usr/local/lib/libwx_gtk2u_adv-2.9.so.2 #30 0x00007ffff6afb225 in wxGrid::HideCellEditControl() () from /usr/local/lib/libwx_gtk2u_adv-2.9.so.2 #31 0x00000000005d2677 in frmEditGrid::DoSave (this=0x17b80f0) at ./frm/frmEditGrid.cpp:1047 #32 0x00000000005d2656 in frmEditGrid::OnSave (this=0x17b80f0, event=...) at ./frm/frmEditGrid.cpp:1042 #33 0x00000000005d1c8f in frmEditGrid::OnKey (this=0x17b80f0, event=...) at ./frm/frmEditGrid.cpp:921 #34 0x00007ffff586066d in wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const () from /usr/local/lib/libwx_baseu-2.9.so.2 #35 0x00007ffff5a3b2c1 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from /usr/local/lib/libwx_baseu-2.9.so.2 #36 0x00007ffff5a3b41c in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from /usr/local/lib/libwx_baseu-2.9.so.2 #37 0x00007ffff5a3b4d3 in wxEvtHandler::DoTryChain(wxEvent&) () from /usr/local/lib/libwx_baseu-2.9.so.2 #38 0x00007ffff5a3b781 in wxEvtHandler::ProcessEvent(wxEvent&) () from /usr/local/lib/libwx_baseu-2.9.so.2 #39 0x00007ffff6b0956e in wxGrid::OnKeyDown(wxKeyEvent&) () from /usr/local/lib/libwx_gtk2u_adv-2.9.so.2 #40 0x00007ffff586066d in wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const () from /usr/local/lib/libwx_baseu-2.9.so.2 #41 0x00007ffff5a3b2c1 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from /usr/local/lib/libwx_baseu-2.9.so.2 #42 0x00007ffff5a3b41c in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from /usr/local/lib/libwx_baseu-2.9.so.2 #43 0x00007ffff5a3b713 in wxEvtHandler::ProcessEventLocally(wxEvent&) () from /usr/local/lib/libwx_baseu-2.9.so.2 #44 0x00007ffff5a3b781 in wxEvtHandler::ProcessEvent(wxEvent&) () from /usr/local/lib/libwx_baseu-2.9.so.2 #45 0x00007ffff663eb6f in wxScrollHelperEvtHandler::ProcessEvent(wxEvent&) () from /usr/local/lib/libwx_gtk2u_core-2.9.so.2 ---Type <return> to continue, or q <return> to quit--- I also see errors like this, but only on the release build: An error has occurred: XRC error: memory:XRC_resource/xrcDialogs.cpp$frmHint.xrc:6: unknown style flag "wxRESIZE_BOX" An error has occurred: XRC error: memory:XRC_resource/xrcDialogs.cpp$frmHint.xrc:6: unknown style flag "wxTHICK_FRAME" I've already removed all wxRESIZE_BOX and wxTHICK_FRAME flags, which fixed lots of these errors on the debug build, so I've currently no idea why this happens. -- Regards, Peter Geoghegan
Not sure about the first error offhand, but to get you going, the second one is probably the result of not regenerating xrcdialogs.cpp using the embed-xrc script. On Mon, Feb 14, 2011 at 10:50 PM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > I've found more problems with wx 2.9. Specifically, I seem to be > having some problems with the table editor. Segfaults occur when I > edit columns of specific datatypes. I'm using the dellstore2 sample > database, available from http://pgfoundry.org/projects/dbsamples/. > > The following datatypes segfault when I press return to commit changes: > > SERIAL (though, curiously, not integer, even when it's our PK) > text/varchar(n) > date > > The following do not: > integer > numeric > > This occurs on the debug and release builds. > > Here's a stacktrace from when I modify a varchar(50) field, country, > from dellstore2's customers table: > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000000000 in ?? () > (gdb) bt > #0 0x0000000000000000 in ?? () > #1 0x00007ffff6b1f710 in wxGridCellTextEditor::EndEdit(int, int, > wxGrid const*, wxString const&, wxString*) () from > /usr/local/lib/libwx_gtk2u_adv-2.9.so.2 > #2 0x00007ffff6b050b2 in wxGrid::SaveEditControlValue() () from > /usr/local/lib/libwx_gtk2u_adv-2.9.so.2 > #3 0x00007ffff6b06083 in wxGrid::EnableCellEditControl(bool) () from > /usr/local/lib/libwx_gtk2u_adv-2.9.so.2 > #4 0x00007ffff586066d in > wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, > wxEvent&) const () from /usr/local/lib/libwx_baseu-2.9.so.2 > #5 0x00007ffff5a3b2c1 in > wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, > wxEvtHandler*, wxEvent&) () > from /usr/local/lib/libwx_baseu-2.9.so.2 > #6 0x00007ffff5a3b41c in wxEventHashTable::HandleEvent(wxEvent&, > wxEvtHandler*) () from /usr/local/lib/libwx_baseu-2.9.so.2 > #7 0x00007ffff5a3b713 in wxEvtHandler::ProcessEventLocally(wxEvent&) > () from /usr/local/lib/libwx_baseu-2.9.so.2 > #8 0x00007ffff5a3b781 in wxEvtHandler::ProcessEvent(wxEvent&) () from > /usr/local/lib/libwx_baseu-2.9.so.2 > #9 0x00007ffff5a3b527 in wxEvtHandler::SafelyProcessEvent(wxEvent&) > () from /usr/local/lib/libwx_baseu-2.9.so.2 > #10 0x00007ffff63d6cbb in wxWindow::GTKHandleFocusOutNoDeferring() () > from /usr/local/lib/libwx_gtk2u_core-2.9.so.2 > #11 0x00007ffff63d6d60 in wxWindow::GTKHandleFocusOut() () from > /usr/local/lib/libwx_gtk2u_core-2.9.so.2 > #12 0x00007ffff63d6d7c in gtk_window_focus_out_callback () from > /usr/local/lib/libwx_gtk2u_core-2.9.so.2 > #13 0x00000032b874e223 in _gtk_marshal_BOOLEAN__BOXED > (closure=0x184e5f0, return_value=0x7fffffffc470, n_param_values=<value > optimized out>, param_values= > 0x18418a0, invocation_hint=<value optimized out>, > marshal_data=<value optimized out>) at gtkmarshalers.c:86 > #14 0x00000032b020e03e in g_closure_invoke (closure=0x184e5f0, > return_value=0x7fffffffc470, n_param_values=2, param_values=0x18418a0, > invocation_hint= > 0x7fffffffc430) at gclosure.c:766 > #15 0x00000032b021ee87 in signal_emit_unlocked_R (node=<value > optimized out>, detail=0, instance=0x1698290, > emission_return=0x7fffffffc5e0, > instance_and_params=0x18418a0) at gsignal.c:3252 > #16 0x00000032b0228555 in g_signal_emit_valist (instance=<value > optimized out>, signal_id=<value optimized out>, detail=<value > optimized out>, > var_args=<value optimized out>) at gsignal.c:2993 > #17 0x00000032b0228983 in g_signal_emit (instance=<value optimized > out>, signal_id=<value optimized out>, detail=<value optimized out>) > at gsignal.c:3040 > #18 0x00000032b8885aef in gtk_widget_event_internal (widget=0x1698290 > [wxPizza], event=0x181df30) at gtkwidget.c:4992 > #19 0x00000032b8893cf1 in IA__gtk_widget_send_focus_change > (widget=0x1698290 [wxPizza], event=0x181df30) at gtkwidget.c:11416 > #20 0x00000032b8893ef2 in do_focus_change (widget=0x1698290 [wxPizza], > in=0) at gtkwindow.c:5304 > #21 0x00000032b88957ea in gtk_window_real_set_focus (window=0x161ee20 > [GtkWindow], focus=0x0) at gtkwindow.c:5508 > #22 0x00000032b020e03e in g_closure_invoke (closure=0xf3aef0, > return_value=0x0, n_param_values=2, param_values=0x16b8d20, > invocation_hint=0x7fffffffc910) > at gclosure.c:766 > #23 0x00000032b021ec98 in signal_emit_unlocked_R (node=<value > optimized out>, detail=0, instance=0x161ee20, emission_return=0x0, > instance_and_params= > 0x16b8d20) at gsignal.c:3290 > #24 0x00000032b02287b5 in g_signal_emit_valist (instance=<value > optimized out>, signal_id=<value optimized out>, detail=<value > optimized out>, > var_args=<value optimized out>) at gsignal.c:2983 > #25 0x00000032b0228983 in g_signal_emit (instance=<value optimized > out>, signal_id=<value optimized out>, detail=<value optimized out>) > at gsignal.c:3040 > #26 0x00000032b889cd3d in _gtk_window_unset_focus_and_default > (window=0x161ee20 [GtkWindow], widget=0x1719490 [GtkScrolledWindow]) > at gtkwindow.c:5590 > #27 0x00000032b888e663 in IA__gtk_widget_hide (widget=0x1719490 > [GtkScrolledWindow]) at gtkwidget.c:3303 > #28 0x00007ffff63d567d in wxWindow::Show(bool) () from > /usr/local/lib/libwx_gtk2u_core-2.9.so.2 > #29 0x00007ffff6b1df92 in wxGridCellEditor::Show(bool, > wxGridCellAttr*) () from /usr/local/lib/libwx_gtk2u_adv-2.9.so.2 > #30 0x00007ffff6afb225 in wxGrid::HideCellEditControl() () from > /usr/local/lib/libwx_gtk2u_adv-2.9.so.2 > #31 0x00000000005d2677 in frmEditGrid::DoSave (this=0x17b80f0) at > ./frm/frmEditGrid.cpp:1047 > #32 0x00000000005d2656 in frmEditGrid::OnSave (this=0x17b80f0, > event=...) at ./frm/frmEditGrid.cpp:1042 > #33 0x00000000005d1c8f in frmEditGrid::OnKey (this=0x17b80f0, > event=...) at ./frm/frmEditGrid.cpp:921 > #34 0x00007ffff586066d in > wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, > wxEvent&) const () from /usr/local/lib/libwx_baseu-2.9.so.2 > #35 0x00007ffff5a3b2c1 in > wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, > wxEvtHandler*, wxEvent&) () > from /usr/local/lib/libwx_baseu-2.9.so.2 > #36 0x00007ffff5a3b41c in wxEventHashTable::HandleEvent(wxEvent&, > wxEvtHandler*) () from /usr/local/lib/libwx_baseu-2.9.so.2 > #37 0x00007ffff5a3b4d3 in wxEvtHandler::DoTryChain(wxEvent&) () from > /usr/local/lib/libwx_baseu-2.9.so.2 > #38 0x00007ffff5a3b781 in wxEvtHandler::ProcessEvent(wxEvent&) () from > /usr/local/lib/libwx_baseu-2.9.so.2 > #39 0x00007ffff6b0956e in wxGrid::OnKeyDown(wxKeyEvent&) () from > /usr/local/lib/libwx_gtk2u_adv-2.9.so.2 > #40 0x00007ffff586066d in > wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, > wxEvent&) const () from /usr/local/lib/libwx_baseu-2.9.so.2 > #41 0x00007ffff5a3b2c1 in > wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, > wxEvtHandler*, wxEvent&) () > from /usr/local/lib/libwx_baseu-2.9.so.2 > #42 0x00007ffff5a3b41c in wxEventHashTable::HandleEvent(wxEvent&, > wxEvtHandler*) () from /usr/local/lib/libwx_baseu-2.9.so.2 > #43 0x00007ffff5a3b713 in wxEvtHandler::ProcessEventLocally(wxEvent&) > () from /usr/local/lib/libwx_baseu-2.9.so.2 > #44 0x00007ffff5a3b781 in wxEvtHandler::ProcessEvent(wxEvent&) () from > /usr/local/lib/libwx_baseu-2.9.so.2 > #45 0x00007ffff663eb6f in > wxScrollHelperEvtHandler::ProcessEvent(wxEvent&) () from > /usr/local/lib/libwx_gtk2u_core-2.9.so.2 > ---Type <return> to continue, or q <return> to quit--- > > > I also see errors like this, but only on the release build: > > An error has occurred: > > XRC error: memory:XRC_resource/xrcDialogs.cpp$frmHint.xrc:6: unknown > style flag "wxRESIZE_BOX" > > An error has occurred: > > XRC error: memory:XRC_resource/xrcDialogs.cpp$frmHint.xrc:6: unknown > style flag "wxTHICK_FRAME" > > > I've already removed all wxRESIZE_BOX and wxTHICK_FRAME flags, which > fixed lots of these errors on the debug build, so I've currently no > idea why this happens. > > -- > Regards, > Peter Geoghegan > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 15 February 2011 08:39, Dave Page <dpage@pgadmin.org> wrote: > Not sure about the first error offhand, but to get you going, the > second one is probably the result of not regenerating xrcdialogs.cpp > using the embed-xrc script. Ah yes, that's fixed it. -- Regards, Peter Geoghegan
I'm seeing a lot of these sorts of warnings:
In file included from ../pgadmin/include/wx/ogl/ogl.h:25:0,
from ./pgAdmin3.cpp:27:
../pgadmin/include/wx/ogl/basicp.h:44:31: warning: type attributes
ignored after type is already defined
../pgadmin/include/wx/ogl/basicp.h:45:31: warning: type attributes
ignored after type is already defined
../pgadmin/include/wx/ogl/basicp.h:87:23: warning: type attributes
ignored after type is already defined
../pgadmin/include/wx/ogl/basicp.h:91:32: warning: type attributes
ignored after type is already defined
In file included from ../pgadmin/include/wx/ogl/ogl.h:27:0,
from ./pgAdmin3.cpp:27:
../pgadmin/include/wx/ogl/linesp.h:15:23: warning: type attributes
ignored after type is already defined
../pgadmin/include/wx/ogl/linesp.h:19:32: warning: type attributes
ignored after type is already defined
mv -f .deps/pgAdmin3.Tpo .deps/pgAdmin3.Po
I'm not sure what to do, because I don't think that they should be
emitted at all, and it doesn't occur to me how they can be safely and
easily fixed. Some of those declarations are friend declarations. See
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39159 for more
information. Pity that g++ doesn't have a facility for suppressing
particular warnings. I hesitate to suppress g++ warnings at a coarser
granularity than suppressing a particular troublesome warning,
particularly because these are header files.
I've fixed all other OGL related warnings, which was quite straightforward.
Attached patch will bring you up to speed. None of the extant 2.9
problems I've described appear when built against 2.8.
Apologies for the wxrc crud.
I suggest we commit this to draw a line under what I've done. The more
eyeballs on the 2.9 AUI problems and the 2.9 table editor segfaults
the better, because they are likely to be tricky to fix. I can see us
reporting more bugs to the wx guys.
--
Regards,
Peter Geoghegan
Вложения
I've attached a new patch that applies cleanly. All existing patches from me that have not been applied yet should not be applied, including the one I sent last night. Apologies once again for the wxrc crud. This addresses the "guru hints" issue reported today in a way that I think is better than adding another overload of sysSettings::Write(), and is consistent with something I've done before in a similar situation with ctlListView. As with the patch I sent last night, 2.9 related issues remain, but we should still commit this because, as I've said, 2.8 is unaffected, and the more eyeballs on the 2.9 problems the better. They are probably specifically wxWidget problems. I can't see us distributing binaries built against 2.9 any time soon, but I think I've given us a good headstart for wx 3.0. -- Regards, Peter Geoghegan
Вложения
Thanks applied - and then fixed on Windows :-) Next step - try a build with 2.9! On Wed, Feb 16, 2011 at 6:34 PM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > I've attached a new patch that applies cleanly. All existing patches > from me that have not been applied yet should not be applied, > including the one I sent last night. > > Apologies once again for the wxrc crud. > > This addresses the "guru hints" issue reported today in a way that I > think is better than adding another overload of sysSettings::Write(), > and is consistent with something I've done before in a similar > situation with ctlListView. > > As with the patch I sent last night, 2.9 related issues remain, but we > should still commit this because, as I've said, 2.8 is unaffected, and > the more eyeballs on the 2.9 problems the better. They are probably > specifically wxWidget problems. > > I can't see us distributing binaries built against 2.9 any time soon, > but I think I've given us a good headstart for wx 3.0. > > -- > Regards, > Peter Geoghegan > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 16 February 2011 19:59, Dave Page <dpage@pgadmin.org> wrote: > Thanks applied - and then fixed on Windows :-) > > Next step - try a build with 2.9! > Cool. Don't forget - you need to build against wx SVN head. -- Regards, Peter Geoghegan
On Wed, Feb 16, 2011 at 8:04 PM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > On 16 February 2011 19:59, Dave Page <dpage@pgadmin.org> wrote: >> Thanks applied - and then fixed on Windows :-) >> >> Next step - try a build with 2.9! >> > > Cool. Don't forget - you need to build against wx SVN head. I did - the one I checked out last week. Fell over on the combo box thing though :-(. Just rebuilding with the latest code now... -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Do you think you can produce a Cocoa build? How much of a difference will that have on pgAdmin's look and feel on Mac? It would be nice to see a few screenshots of that. -- Regards, Peter Geoghegan
On Wed, Feb 16, 2011 at 10:41 PM, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > Do you think you can produce a Cocoa build? How much of a difference > will that have on pgAdmin's look and feel on Mac? It would be nice to > see a few screenshots of that. Seems like SVN Trunk of wxWidgets is broken :-(. I haven't had a chance to look into it yet: /Users/dpage/SVN-Trees/wxWidgets/bk-deps ccache g++ -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -c -o corelib_cocoa_nonownedwnd.o -D__WXOSX_COCOA__ -DWXBUILDING -I/Users/dpage/SVN-Trees/wxWidgets/src/tiff/libtiff -I./src/tiff/libtiff -I./src/jpeg -I./src/png -I./src/regex -DwxUSE_BASE=0 -D_FILE_OFFSET_BITS=64 -DwxDEBUG_LEVEL=0 -I/Users/dpage/SVN-Trees/wxWidgets/lib/wx/include/osx_cocoa-unicode-static-2.9 -I./include -O2 -fno-strict-aliasing -arch ppc -arch i386 -arch x86_64 ./src/osx/cocoa/nonownedwnd.mm ./src/osx/cocoa/nonownedwnd.mm: In function ‘BOOL -[wxNonOwnedWindowController triggerMenu:](wxNonOwnedWindowController*, objc_selector*, objc_selector*)’: ./src/osx/cocoa/nonownedwnd.mm:278: error: incomplete type ‘wxMenuBar’ used in nested name specifier ./src/osx/cocoa/nonownedwnd.mm:282: error: invalid use of incomplete type ‘struct wxMenuBar’ ./include/wx/frame.h:27: error: forward declaration of ‘struct wxMenuBar’ ./src/osx/cocoa/nonownedwnd.mm:284: error: invalid use of incomplete type ‘struct wxMenu’ ./include/wx/event.h:44: error: forward declaration of ‘struct wxMenu’ ./src/osx/cocoa/nonownedwnd.mm: In function ‘BOOL -[wxNonOwnedWindowController validateMenuItem:](wxNonOwnedWindowController*, objc_selector*, NSMenuItem*)’: ./src/osx/cocoa/nonownedwnd.mm:293: error: incomplete type ‘wxMenuBar’ used in nested name specifier ./src/osx/cocoa/nonownedwnd.mm:297: error: invalid use of incomplete type ‘struct wxMenuBar’ ./include/wx/frame.h:27: error: forward declaration of ‘struct wxMenuBar’ ./src/osx/cocoa/nonownedwnd.mm:300: error: invalid use of incomplete type ‘struct wxMenu’ ./include/wx/event.h:44: error: forward declaration of ‘struct wxMenu’ ./src/osx/cocoa/nonownedwnd.mm:301: error: invalid use of incomplete type ‘struct wxMenuItem’ ./include/wx/accel.h:22: error: forward declaration of ‘struct wxMenuItem’ ./src/osx/cocoa/nonownedwnd.mm: In function ‘BOOL -[wxNonOwnedWindowController triggerMenu:](wxNonOwnedWindowController*, objc_selector*, objc_selector*)’: ./src/osx/cocoa/nonownedwnd.mm:278: error: incomplete type ‘wxMenuBar’ used in nested name specifier ./src/osx/cocoa/nonownedwnd.mm:282: error: invalid use of incomplete type ‘struct wxMenuBar’ ./include/wx/frame.h:27: error: forward declaration of ‘struct wxMenuBar’ ./src/osx/cocoa/nonownedwnd.mm:284: error: invalid use of incomplete type ‘struct wxMenu’ ./include/wx/event.h:44: error: forward declaration of ‘struct wxMenu’ ./src/osx/cocoa/nonownedwnd.mm: In function ‘BOOL -[wxNonOwnedWindowController validateMenuItem:](wxNonOwnedWindowController*, objc_selector*, NSMenuItem*)’: ./src/osx/cocoa/nonownedwnd.mm:293: error: incomplete type ‘wxMenuBar’ used in nested name specifier ./src/osx/cocoa/nonownedwnd.mm:297: error: invalid use of incomplete type ‘struct wxMenuBar’ ./include/wx/frame.h:27: error: forward declaration of ‘struct wxMenuBar’ ./src/osx/cocoa/nonownedwnd.mm:300: error: invalid use of incomplete type ‘struct wxMenu’ ./include/wx/event.h:44: error: forward declaration of ‘struct wxMenu’ ./src/osx/cocoa/nonownedwnd.mm:301: error: invalid use of incomplete type ‘struct wxMenuItem’ ./include/wx/accel.h:22: error: forward declaration of ‘struct wxMenuItem’ ./src/osx/cocoa/nonownedwnd.mm: In function ‘BOOL -[wxNonOwnedWindowController triggerMenu:](wxNonOwnedWindowController*, _message_ref_t*, objc_selector*)’: ./src/osx/cocoa/nonownedwnd.mm:278: error: incomplete type ‘wxMenuBar’ used in nested name specifier ./src/osx/cocoa/nonownedwnd.mm:282: error: invalid use of incomplete type ‘struct wxMenuBar’ ./include/wx/frame.h:27: error: forward declaration of ‘struct wxMenuBar’ ./src/osx/cocoa/nonownedwnd.mm:284: error: invalid use of incomplete type ‘struct wxMenu’ ./include/wx/event.h:44: error: forward declaration of ‘struct wxMenu’ ./src/osx/cocoa/nonownedwnd.mm: In function ‘BOOL -[wxNonOwnedWindowController validateMenuItem:](wxNonOwnedWindowController*, _message_ref_t*, NSMenuItem*)’: ./src/osx/cocoa/nonownedwnd.mm:293: error: incomplete type ‘wxMenuBar’ used in nested name specifier ./src/osx/cocoa/nonownedwnd.mm:297: error: invalid use of incomplete type ‘struct wxMenuBar’ ./include/wx/frame.h:27: error: forward declaration of ‘struct wxMenuBar’ ./src/osx/cocoa/nonownedwnd.mm:300: error: invalid use of incomplete type ‘struct wxMenu’ ./include/wx/event.h:44: error: forward declaration of ‘struct wxMenu’ ./src/osx/cocoa/nonownedwnd.mm:301: error: invalid use of incomplete type ‘struct wxMenuItem’ ./include/wx/accel.h:22: error: forward declaration of ‘struct wxMenuItem’ lipo: can't figure out the architecture type of: /var/folders/w3/w3pWkaA1HXu6YdlU06kyuU+++TI/-Tmp-//ccNy51JF.out make: *** [corelib_cocoa_nonownedwnd.o] Error 1 -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company