Thread: build error pgadmin3-src-20040805.tar.gz
Hi friends,
hourra! My DSL connection is now functional :)
I surely missed some of the things which were done recently, but just in
case, I had a quick look to this morning build and it fails like this:
if i386-linux-g++ -DHAVE_CONFIG_H -I. -I. -I..
-DDATA_DIR=\"/usr/share/pgadmin3/\" -Wall -g -I../src/include
-I../src/agent/include -I/usr/include/postgresql -I./include -DSSL
-I/usr/lib/wx/include/gtk2ud-2.5 -D__WXDEBUG__ -D__WXGTK__
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/usr/include
-DDATA_DIR=\"/usr/share/pgadmin3/\" -Wall -g -I../src/include
-I../src/agent/include -g -O2 -MT frmQuery.o -MD -MP -MF
".deps/frmQuery.Tpo" \
-c -o frmQuery.o `test -f 'ui/frmQuery.cpp' || echo
'./'`ui/frmQuery.cpp; \
then mv -f ".deps/frmQuery.Tpo" ".deps/frmQuery.Po"; \
else rm -f ".deps/frmQuery.Tpo"; exit 1; \
fi
ui/frmQuery.cpp: In member function `void frmQuery::execQuery(const
wxString&,
int, bool, int, bool)':
ui/frmQuery.cpp:1004: error: `wxMilliSleep' undeclared (first use this
function)
ui/frmQuery.cpp:1004: error: (Each undeclared identifier is reported
only once
for each function it appears in.)
make[3]: *** [frmQuery.o] Error 1
make[3]: Leaving directory
`/BUILD/MY_PGADMIN3/AUTO_PGADMIN/build/debian/pgadmin3-1.1.0/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/BUILD/MY_PGADMIN3/AUTO_PGADMIN/build/debian/pgadmin3-1.1.0'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/BUILD/MY_PGADMIN3/AUTO_PGADMIN/build/debian/pgadmin3-1.1.0'
make: *** [build-stamp] Error 2
Regards,
Raphaël
> -----Original Message----- > From: pgadmin-hackers-owner@postgresql.org > [mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of > Raphaël Enrici > Sent: 05 August 2004 22:24 > To: pgadmin-hackers@postgresql.org > Subject: [pgadmin-hackers] build error pgadmin3-src-20040805.tar.gz > > Hi friends, > > hourra! My DSL connection is now functional :) > > I surely missed some of the things which were done recently, > but just in case, I had a quick look to this morning build > and it fails like this: Have you updated to our latest wx snapshot? Iirc, the wxMilliSleep function is in there... /D
----Message d'origine---- >De: "Dave Page" <dpage@vale-housing.co.uk> > >Have you updated to our latest wx snapshot? Iirc, the wxMilliSleep function is in there... Not at all. I'll check this asap and give feedback. Regards, Raphaël
blacknoz@club-internet.fr wrote: > ----Message d'origine---- > >>De: "Dave Page" <dpage@vale-housing.co.uk> >> >>Have you updated to our latest wx snapshot? Iirc, the wxMilliSleep function is in there... > > > Not at all. I'll check this asap and give feedback. mmmh... I'm currently trying to build the snapshot and face very bad issue: the snap fails to build with an internal compiler error. Which version of gcc suite are you using ? (there are bugs reporting such problems in debian, for example #246031, but I can't tell if we face the exact same problem). ./bk-deps g++ -c -o corelib_prntdlgg.o -D__WXGTK__ -I./src/regex -I./src/ expat/lib -DwxUSE_BASE=0 -D__WXDEBUG__ -Ilib/wx/include/gtk2ud-2.5 -I./include - pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/X11R6/include -I/usr/i nclude/glib-2.0 -I/usr/lib/glib-2.0/include -D_FILE_OFFSET_BITS=64 -D_LARGE_FILE S -g -O0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2 .0 -I/usr/lib/glib-2.0/include -pthread -Wall src/generic/prntdlgg.cpp g++: Internal error: Segmentation fault (program cc1plus) Please submit a full bug report. See <URL:http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see <URL:file:///usr/share/doc/gcc-3.3/README.Bugs>. make[1]: *** [corelib_prntdlgg.o] Error 1 make[1]: Leaving directory `/BUILD/MY_WXWINDOWS/AUTO_WXWINDOWS/build/debian/wxwi dgets-pgadmin3-2.5.0' make: *** [build-stamp] Error 2 The actual g++ for sarge is 3.3.4... Can all of you report versions of gcc which were successful in building this snapshot ? BTW, I'm gonna do some cleaning and recheck for any mistake I may have done. Regards, Raphaël
Raphaël Enrici wrote: > blacknoz@club-internet.fr wrote: > >> ----Message d'origine---- >> >>> De: "Dave Page" <dpage@vale-housing.co.uk> >>> >>> Have you updated to our latest wx snapshot? Iirc, the wxMilliSleep >>> function is in there... >> >> >> >> Not at all. I'll check this asap and give feedback. > > > > mmmh... I'm currently trying to build the snapshot and face very bad issue: > the snap fails to build with an internal compiler error. Which version > of gcc suite are you using ? > (there are bugs reporting such problems in debian, for example #246031, > but I can't tell if we face the exact same problem). > > ../bk-deps g++ -c -o corelib_prntdlgg.o -D__WXGTK__ -I./src/regex > -I./src/ > expat/lib -DwxUSE_BASE=0 -D__WXDEBUG__ -Ilib/wx/include/gtk2ud-2.5 > -I./include - > pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include > -I/usr/include/atk-1.0 > -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/X11R6/include > -I/usr/i > nclude/glib-2.0 -I/usr/lib/glib-2.0/include -D_FILE_OFFSET_BITS=64 > -D_LARGE_FILE > S -g -O0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 > -I/usr/include/glib-2 > ..0 -I/usr/lib/glib-2.0/include -pthread -Wall src/generic/prntdlgg.cpp > g++: Internal error: Segmentation fault (program cc1plus) > Please submit a full bug report. > See <URL:http://gcc.gnu.org/bugs.html> for instructions. > For Debian GNU/Linux specific bug reporting instructions, > see <URL:file:///usr/share/doc/gcc-3.3/README.Bugs>. > > make[1]: *** [corelib_prntdlgg.o] Error 1 > make[1]: Leaving directory > `/BUILD/MY_WXWINDOWS/AUTO_WXWINDOWS/build/debian/wxwi > dgets-pgadmin3-2.5.0' > make: *** [build-stamp] Error 2 Ok, I just went a little bit further... the snap we use has prntdlgg.cpp rev 1.61, I checked out 1.62 and it now builds. I fails a little bit further on statusbr.cpp. We use 1.59 and 1.60 has a similar log to what's filled for 1.61->1.62 of prntdlgg.cpp. pga3@anaconda:/BUILD/MY_WXWINDOWS/AUTO_WXWINDOWS/build/debian/wxwidgets-pgadmin3-2.5.0/src/generic$ diff statusbr.cpp statusbr.cpp\?rev\=1.60 7c7 < // RCS-ID: $Id: statusbr.cpp,v 1.59 2004/06/23 16:41:05 VS Exp $ --- > // RCS-ID: $Id: statusbr.cpp,v 1.60 2004/07/20 10:09:30 ABX Exp $ 107c107 < SetSize(wxDefaultPosition.x, wxDefaultPosition.y, wxDefaultSize.x, height); --- > SetSize(wxDefaultCoord, wxDefaultCoord, wxDefaultCoord, height); 398c398 < SetSize(wxDefaultPosition.x, wxDefaultPosition.y, wxDefaultSize.x, height + 2*m_borderY); --- > SetSize(wxDefaultCoord, wxDefaultCoord, wxDefaultCoord, height + 2*m_borderY); It now fails a little bit further in src/gtk/combobox.cpp but we are using the latest rev for this file. So, it seems something was partly fixed in wxWid source... Maybe we should move to wxWid-hackers although it seems to be a gcc-3.3.4 bug. Regards, Raphaël
Raphaël Enrici wrote: >> mmmh... I'm currently trying to build the snapshot and face very bad >> issue: >> the snap fails to build with an internal compiler error. Which version >> of gcc suite are you using ? >> (there are bugs reporting such problems in debian, for example >> #246031, but I can't tell if we face the exact same problem). >> >> ../bk-deps g++ -c -o corelib_prntdlgg.o -D__WXGTK__ >> -I./src/regex -I./src/ >> expat/lib -DwxUSE_BASE=0 -D__WXDEBUG__ -Ilib/wx/include/gtk2ud-2.5 >> -I./include - >> pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include >> -I/usr/include/atk-1.0 >> -I/usr/include/pango-1.0 -I/usr/include/freetype2 >> -I/usr/X11R6/include -I/usr/i >> nclude/glib-2.0 -I/usr/lib/glib-2.0/include -D_FILE_OFFSET_BITS=64 >> -D_LARGE_FILE >> S -g -O0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 >> -I/usr/include/glib-2 >> ..0 -I/usr/lib/glib-2.0/include -pthread -Wall src/generic/prntdlgg.cpp >> g++: Internal error: Segmentation fault (program cc1plus) >> Please submit a full bug report. >> See <URL:http://gcc.gnu.org/bugs.html> for instructions. >> For Debian GNU/Linux specific bug reporting instructions, >> see <URL:file:///usr/share/doc/gcc-3.3/README.Bugs>. >> >> make[1]: *** [corelib_prntdlgg.o] Error 1 >> make[1]: Leaving directory >> `/BUILD/MY_WXWINDOWS/AUTO_WXWINDOWS/build/debian/wxwi >> dgets-pgadmin3-2.5.0' >> make: *** [build-stamp] Error 2 good news, gcc-3.4 and g++-3.4 are available in debian/sarge. It seems the build goes straight. I'll recheck and provide something quickly. Regards, Raphaël
> -----Original Message----- > From: Raphaël Enrici [mailto:blacknoz@club-internet.fr] > Sent: 12 August 2004 23:02 > To: Andreas Pflug; Dave Page > Cc: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] build error > pgadmin3-src-20040805.tar.gz > > good news, gcc-3.4 and g++-3.4 are available in debian/sarge. > It seems the build goes straight. I'll recheck and provide something > quickly. Wahooo :-) 'Night! /D
Dave Page wrote: >>-----Original Message----- >>From: Raphaël Enrici [mailto:blacknoz@club-internet.fr] >>Sent: 12 August 2004 23:02 >>To: Andreas Pflug; Dave Page >>Cc: pgadmin-hackers@postgresql.org >>Subject: Re: [pgadmin-hackers] build error >>pgadmin3-src-20040805.tar.gz >> >>good news, gcc-3.4 and g++-3.4 are available in debian/sarge. >>It seems the build goes straight. I'll recheck and provide something >>quickly. > > > Wahooo :-) I talked too fast :( > 'Night! I had a good one ;) Hope this one will be ok. g++-3.4 build the wxWid correctly but not pgAdmin III. I believe I face the issue reported by Thomas Trepl about 3 weeks ago: http://www.mail-archive.com/pgadmin-hackers@postgresql.org/msg03746.html if g++-3.4 -DHAVE_CONFIG_H -I. -I. -I.. -DDATA_DIR=\"/usr/share/pgadmin3/\" - Wall -g -I../src/include -I../src/agent/include -I/usr/include/postgresql -I./ include -DSSL -I/usr/lib/wx/include/gtk2ud-2.5 -D__WXDEBUG__ -D__WXGTK__ -D_FI LE_OFFSET_BITS=64 -D_LARGE_FILES -DWX_PRECOMP -DNO_GCC_PRAGMA -I/usr/include - DDATA_DIR=\"/usr/share/pgadmin3/\" -Wall -g -I../src/include -I../src/agent/in clude -g -O2 -MT dlgJob.o -MD -MP -MF ".deps/dlgJob.Tpo" \ -c -o dlgJob.o `test -f 'agent/dlgJob.cpp' || echo './'`agent/dlgJob.cpp; \ then mv -f ".deps/dlgJob.Tpo" ".deps/dlgJob.Po"; \ else rm -f ".deps/dlgJob.Tpo"; exit 1; \ fi ../src/include/dlgProperty.h:69: error: `void dlgProperty::OnChange(wxCommandE vent&)' is protected agent/dlgJob.cpp:51: error: within this context ../src/include/dlgProperty.h:69: error: `void dlgProperty::OnChange(wxCommandE vent&)' is protected agent/dlgJob.cpp:52: error: within this context make[3]: *** [dlgJob.o] Error 1 make[3]: Leaving directory `/BUILD/MY_PGADMIN3/AUTO_PGADMIN/build/debian/pgadm in3-1.1.0/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/BUILD/MY_PGADMIN3/AUTO_PGADMIN/build/debian/pgadm in3-1.1.0' make[1]: *** [all] Error 2 make[1]: Leaving directory `/BUILD/MY_PGADMIN3/AUTO_PGADMIN/build/debian/pgadm in3-1.1.0' make: *** [build-stamp] Error 2 Andreas, did you get time to take a look at this ? I found some ref to this on the web but I admit I don't understand a word of it... :( Good night guys. I'll try to go further later... :( Raphaël
Raphaël Enrici wrote:
> Dave Page wrote:
>
>>> -----Original Message-----
>>> From: Raphaël Enrici [mailto:blacknoz@club-internet.fr] Sent: 12
>>> August 2004 23:02
>>> To: Andreas Pflug; Dave Page
>>> Cc: pgadmin-hackers@postgresql.org
>>> Subject: Re: [pgadmin-hackers] build error pgadmin3-src-20040805.tar.gz
>>>
>>> good news, gcc-3.4 and g++-3.4 are available in debian/sarge.
>>> It seems the build goes straight. I'll recheck and provide something
>>> quickly.
>>
> Andreas, did you get time to take a look at this ?
> I found some ref to this on the web but I admit I don't understand a
> word of it... :(
>
I tried to go further but definitely does not have enough skill in C++.
The problem comes from all references to xxx:OnChange when xxx is not
the class name declared in BEGIN_EVENT_TABLE
For example in dlgJob.cpp, the following "patch" makes it build although
it surely make no logical sense.
===================================================================
RCS file: /projects/pgadmin3/src/agent/dlgJob.cpp,v
retrieving revision 1.10
diff -r1.10 dlgJob.cpp
51,52c51,54
< EVT_CHECKBOX(XRCID("chkEnabled"), dlgProperty::OnChange)
< EVT_COMBOBOX(XRCID("cbJobclass"), dlgProperty::OnChange)
---
> // EVT_CHECKBOX(XRCID("chkEnabled"),
dlgProperty::OnChange)
> // EVT_COMBOBOX(XRCID("cbJobclass"),
dlgProperty::OnChange)
> EVT_CHECKBOX(XRCID("chkEnabled"), dlgJob::OnChange)
> EVT_COMBOBOX(XRCID("cbJobclass"), dlgJob::OnChange)
As far as I understand, we sometime refer directly to a method declared
as protected in dlgProperty although we sometime (not always) inherit
from it. Declaring friends classes or public method would solve the
problem, but I'm quite sure that it was not made for some good reason.
I've found some information in the changes from gcc 3.4 which tend to
tell that the compiler has changed the way it handles such situation and
ask to refer to the subclass and not the top class. Maybe it's a way
to follow ?
(I've seen that it talks about pointer, but isn't BEGIN_EVENT_TABLE
playing with pointer internally ?)
http://gcc.gnu.org/gcc-3.4/changes.html
<------ cut ---------->
When forming a pointer to member or a pointer to member function, access
checks for class visibility (public, protected, private) are now
performed using the qualifying scope of the name itself. This is better
explained with an example:
class A
{
public:
void pub_func();
protected:
void prot_func();
private:
void priv_func();
};
class B : public A
{
public:
void foo()
{
&A::pub_func; // OK, pub_func is accessible through A
&A::prot_func; // error, cannot access prot_func through A
&A::priv_func; // error, cannot access priv_func through A
&B::pub_func; // OK, pub_func is accessible through B
&B::prot_func; // OK, can access prot_func through B (within B)
&B::priv_func; // error, cannot access priv_func through B
}
};
<------- cut ------->
As you've all noticed, I'm totally lost with this issue. I really need
to refresh my C++, then to learn wxWid and then to read pgAdmin III
source entirely... Approximately 50 years to pass on it for my poor brain...
Hope I didn't make too much noise... I just want to make the build
succeed! ;)
'night
(lost)Raphaël
Well,
seems GCC 3.4 isn't compliant with C++...
Raphaël Enrici wrote:
> > EVT_CHECKBOX(XRCID("chkEnabled"), dlgJob::OnChange)
> > EVT_COMBOBOX(XRCID("cbJobclass"), dlgJob::OnChange)
>
There's no dlgJob::OnChange. I'd consider it accidentially if a compiler
accepts that or not. If I'd like the compiler to take "the nearest
method accessible in this context" I wouldn't specify the classname.
> As far as I understand, we sometime refer directly to a method declared
> as protected in dlgProperty although we sometime (not always) inherit
> from it. Declaring friends classes or public method would solve the
> problem, but I'm quite sure that it was not made for some good reason.
We *always* inherit property dialogs from dlgProperty. OnChange is to be
used by dlgProperty and classes derived from it only, so it's very
correct to declare it protected.
>
> I've found some information in the changes from gcc 3.4 which tend to
> tell that the compiler has changed the way it handles such situation and
> ask to refer to the subclass and not the top class. Maybe it's a way to
> follow ?
> (I've seen that it talks about pointer, but isn't BEGIN_EVENT_TABLE
> playing with pointer internally ?)
Yes.
> class A
> {
> public:
> void pub_func();
> protected:
> void prot_func();
> private:
> void priv_func();
> };
>
> class B : public A
> {
> public:
> void foo()
> {
> &A::pub_func; // OK, pub_func is accessible through A
> &A::prot_func; // error, cannot access prot_func through A
> &A::priv_func; // error, cannot access priv_func through A
>
> &B::pub_func; // OK, pub_func is accessible through B
> &B::prot_func; // OK, can access prot_func through B (within B)
> &B::priv_func; // error, cannot access priv_func through B
> }
> };
This is plain crazy. So I may call A::prot_func(), but not retrieve it's
address? What if I also have a B::prot_func?
Sorry, this is a *bug*.
Regards,
Andreas
Andreas Pflug wrote:
> Well,
>
> seems GCC 3.4 isn't compliant with C++...
:)
> Raphaël Enrici wrote:
>
>> > EVT_CHECKBOX(XRCID("chkEnabled"), dlgJob::OnChange)
>> > EVT_COMBOBOX(XRCID("cbJobclass"), dlgJob::OnChange)
>>
> <snip>
>> class A
>> {
>> public:
>> void pub_func();
>> protected:
>> void prot_func();
>> private:
>> void priv_func();
>> };
>>
>> class B : public A
>> {
>> public:
>> void foo()
>> {
>> &A::pub_func; // OK, pub_func is accessible through A
>> &A::prot_func; // error, cannot access prot_func through A
>> &A::priv_func; // error, cannot access priv_func through A
>>
>> &B::pub_func; // OK, pub_func is accessible through B
>> &B::prot_func; // OK, can access prot_func through B (within B)
>> &B::priv_func; // error, cannot access priv_func through B
>> }
>> };
>
>
> This is plain crazy. So I may call A::prot_func(), but not retrieve it's
> address? What if I also have a B::prot_func?
> Sorry, this is a *bug*.
Seems gcc team does not agree...
Can you take a look at these please and tell what you understand ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15308
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11174
They are the ones coming to the conclusion quoted before.
Can you tell me where I can find the C++ spec they are all talking about
please ?
Regards,
Raphaël
Raphaël Enrici wrote: > > > Seems gcc team does not agree... > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11174 > They are the ones coming to the conclusion quoted before. > > Can you tell me where I can find the C++ spec they are all talking about > please ? http://www.csci.csusb.edu/dick/c++std/cd2/index.html AFAIK the original ansi specs are not available without horrible fees, I hope the link above contains accurate data. Apparently, the spec *does* specify this brain dead restriction. We have three alternatives to fix that: - declare OnChange public. Maybe I should rearrange my knowledge to drop the 'protected' keyword completely. - Invent an intermediate class empty class above the current dlgProperty without any methods just to create an accessible target. - deny 3.4 support Regards, Andreas
Andreas Pflug wrote: > Raphaël Enrici wrote: > >> >> >> Seems gcc team does not agree... >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11174 >> They are the ones coming to the conclusion quoted before. >> >> Can you tell me where I can find the C++ spec they are all talking >> about please ? > > > http://www.csci.csusb.edu/dick/c++std/cd2/index.html thanks. > AFAIK the original ansi specs are not available without horrible fees, I > hope the link above contains accurate data. ah... I forgot we were not all "free". ;) > > Apparently, the spec *does* specify this brain dead restriction. oh. > We have three alternatives to fix that: > - declare OnChange public. Maybe I should rearrange my knowledge to drop > the 'protected' keyword completely. > - Invent an intermediate class empty class above the current dlgProperty > without any methods just to create an accessible target. They are both solutions I've seen in other projects where they faced this issue. > - deny 3.4 support Impossible for me! Our wxWid does not build with gcc 3.3.x due to a compiler issue fixed in 3.4.x branch. g++ 3.4.x is the only solution I have to get actual pgAdmin III into debian... unless I move back to 2.95 series but IIRC there was problem with it. Regards, Raphaël
Raphaël Enrici wrote: >> We have three alternatives to fix that: >> - declare OnChange public. Maybe I should rearrange my knowledge to >> drop the 'protected' keyword completely. >> - Invent an intermediate class empty class above the current >> dlgProperty without any methods just to create an accessible target. > > > They are both solutions I've seen in other projects where they faced > this issue. Both not completely satisfying. >> - deny 3.4 support > > > Impossible for me! Our wxWid does not build with gcc 3.3.x due to a > compiler issue fixed in 3.4.x branch. g++ 3.4.x is the only solution I > have to get actual pgAdmin III into debian... unless I move back to 2.95 > series but IIRC there was problem with it. You can wait for a better spec and gcc 5.6 :-) Try the new dlgProperty.h. Regards, Andreas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Pflug wrote: | Raphaël Enrici wrote: | |> They are both solutions I've seen in other projects where they faced |> this issue. | | | Both not completely satisfying. yep. |>> - deny 3.4 support |> |> Impossible for me! Our wxWid does not build with gcc 3.3.x due to a |> compiler issue fixed in 3.4.x branch. g++ 3.4.x is the only solution I |> have to get actual pgAdmin III into debian... unless I move back to |> 2.95 series but IIRC there was problem with it. | | | You can wait for a better spec and gcc 5.6 :-) Shame on me! I forgot about gcc 5.6 ;) | Try the new dlgProperty.h. It works, but I had another error which the patch attached corrects (based on what you submitted last time): if g++-3.4 -DHAVE_CONFIG_H -I. -I. -I.. - -DDATA_DIR=\"/usr/share/pgadmin3/\" -Wa ll -g -I../src/include -I../src/agent/include -I/usr/include/postgresql - -I./incl ude -DSSL -I/usr/lib/wx/include/gtk2ud-2.5 -D__WXDEBUG__ -D__WXGTK__ - -D_FILE_OFF SET_BITS=64 -D_LARGE_FILES -DWX_PRECOMP -DNO_GCC_PRAGMA -I/usr/include - -DDATA_DI R=\"/usr/share/pgadmin3/\" -Wall -g -I../src/include - -I../src/agent/include -g - O2 -MT frmBackup.o -MD -MP -MF ".deps/frmBackup.Tpo" \ ~ -c -o frmBackup.o `test -f 'ui/frmBackup.cpp' || echo './'`ui/frmBackup.cpp; \ then mv -f ".deps/frmBackup.Tpo" ".deps/frmBackup.Po"; \ else rm -f ".deps/frmBackup.Tpo"; exit 1; \ fi ../src/include/dlgClasses.h:116: error: `void ExternProcessDialog::OnClose(wxClo seEvent&)' is protected ui/frmBackup.cpp:53: error: within this context make[3]: *** [frmBackup.o] Error 1 make[3]: Leaving directory `/BUILD/MY_PGADMIN3/AUTO_PGADMIN/build/debian/pgadmin 3-1.1.0/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/BUILD/MY_PGADMIN3/AUTO_PGADMIN/build/debian/pgadmin 3-1.1.0' make[1]: *** [all] Error 2 make[1]: Leaving directory `/BUILD/MY_PGADMIN3/AUTO_PGADMIN/build/debian/pgadmin 3-1.1.0' make: *** [build-stamp] Error 2 Please recheck the patch, I was not really sure of what should really become public or not. I saw you made public all the onXX methods in your last patch although the one really embarassing is the onChange one, so I tried to copy you ;) Regards, Raphaël -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBIMFux3NpDPptARMRAptLAJ9wPCohSdPSObNL6i7A7nMJ/Ru66gCfcPt+ T5p34ai6jBnxOo+biGhly1s= =g4lq -----END PGP SIGNATURE----- *** dlgClasses.h.old Wed Aug 11 23:20:08 2004 --- dlgClasses.h Mon Aug 16 16:04:31 2004 *************** *** 111,122 **** --- 111,132 ---- int pid; bool done, final; + #if __GNUC__ >= 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4) + // ANSI spec 11.5 is quite brain dead about pointers of protected members: In order to access + // them using the base class name, they can't be protected. + // apparently, only gcc 3.4 knows that; other compilers take protected as protected. + public: + + #endif + void OnOK(wxCommandEvent& ev); void OnCancel(wxCommandEvent& ev); void OnClose(wxCloseEvent& event); void OnEndProcess(wxProcessEvent& event); void OnPollProcess(wxTimerEvent& event); + + protected: void checkStreams(); void readStream(wxInputStream *input);
Raphaël Enrici wrote: > > Please recheck the patch, I was not really sure of what should really > become public or not. I saw you made public all the onXX methods in your > last patch although the one really embarassing is the onChange one, so I > tried to copy you ;) You can't copy me, I'm unique :-) Making those methods public which are candidates for EVENT_TABLE usage is sufficient. Patch committed. Regards, Andreas
Andreas Pflug wrote:
> Raphaël Enrici wrote:
>
>>
>> Please recheck the patch, I was not really sure of what should really
>> become public or not. I saw you made public all the onXX methods in your
>> last patch although the one really embarassing is the onChange one, so I
>> tried to copy you ;)
>
>
> You can't copy me, I'm unique :-)
But I did it (I was helped by the power of gcc-5.6beta12)! ;)
Howerever, don't be too anxious, it tooks me about an hour where you
would have taken half a minute {8-)
> Making those methods public which are candidates for EVENT_TABLE usage
> is sufficient.
> Patch committed.
Thanks. <song>WE ARE COMPLIANT, weeeeeeeeee are compliiiianttttt </song
based on the fabulous Queen song>
R.