Thread: Cannot build latest CVS
Hello, When I try latest CVS: /usr/include/wx/generic/calctrl.h: In member function `bool wxCalendarBox::Create(wxWindow*, int, const wxDateTime&, const wxPoint&, const wxSize&, long int, const wxString&)': /usr/include/wx/generic/calctrl.h:247: `wxControl* wxCalendarCtrl::GetYearControl() const' is private ui/calbox.cpp:107: within this context /usr/include/wx/generic/calctrl.h:246: `wxControl* wxCalendarCtrl::GetMonthControl() const' is private ui/calbox.cpp:139: within this context ui/calbox.cpp: In member function `void wxCalendarBox::OnText(wxCommandEvent&)': ui/calbox.cpp:413: no matching function for call to `wxCalendarEvent::SetDate( wxDateTime&)' make[2]: *** [calbox.o] Error 1 make[2]: Leaving directory `/home/troels/cvs-co/pgadmin3/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/troels/cvs-co/pgadmin3' make: *** [all] Error 2 I'm using wxGTK2ud-2.5-20031010.3 from http://snake.pgadmin.org/snapshots/wxwindows/ -- Greetings from Troels Arvin, Copenhagen, Denmark
Hi Troels. There was a new update to the wx tarball this morning, though Jean-Michel may not have produced RPMs yet. You need the -4 version which is on Snake in tar.bz2 format. Regards, Dave. > -----Original Message----- > From: Troels Arvin [mailto:troels@arvin.dk] > Sent: 22 October 2003 13:28 > To: pgadmin-hackers > Subject: [pgadmin-hackers] Cannot build latest CVS > > Hello, > > When I try latest CVS: > > /usr/include/wx/generic/calctrl.h: In member function `bool > wxCalendarBox::Create(wxWindow*, int, const wxDateTime&, > const wxPoint&, > const wxSize&, long int, const wxString&)': > /usr/include/wx/generic/calctrl.h:247: `wxControl* > wxCalendarCtrl::GetYearControl() const' is private > ui/calbox.cpp:107: within this context > /usr/include/wx/generic/calctrl.h:246: `wxControl* > wxCalendarCtrl::GetMonthControl() const' is private > ui/calbox.cpp:139: within this context > ui/calbox.cpp: In member function `void > wxCalendarBox::OnText(wxCommandEvent&)': > ui/calbox.cpp:413: no matching function for call to > `wxCalendarEvent::SetDate( > wxDateTime&)' > make[2]: *** [calbox.o] Error 1 > make[2]: Leaving directory `/home/troels/cvs-co/pgadmin3/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/troels/cvs-co/pgadmin3' > make: *** [all] Error 2 > > I'm using wxGTK2ud-2.5-20031010.3 from > http://snake.pgadmin.org/snapshots/wxwindows/ > > -- > Greetings from Troels Arvin, Copenhagen, Denmark > > > ---------------------------(end of > broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so > that your > message can get through to the mailing list cleanly >
Hello, On Wed, 2003-10-22 at 14:38, Dave Page wrote: > There was a new update to the wx tarball this morning, though > Jean-Michel may not have produced RPMs yet. You need the -4 version > which is on Snake in tar.bz2 format. OK; thanks. I'll build a new set of RPMS locally. As long as pgadmin3 is so dependent on certain changes in wxWindows, then wouldn't it be nice to keep the needed patch(es) somewhere in pgadmin3's CVS tree? - For example a patch agains current wxWindows CVS HEAD? Of course, that patch would sometimes need an update because of changes in wxWindows' CVS-HEAD, and when new features/fixes are introduced because of pgadmin3. -- Greetings from Troels Arvin, Copenhagen, Denmark
Le Mercredi 22 Octobre 2003 14:27, Troels Arvin a écrit : > I'm using wxGTK2ud-2.5-20031010.3 from > http://snake.pgadmin.org/snapshots/wxwindows/ I am currently compiling wxGTK2ud-2.5-20031010.4. Wait a few hours before everything is publised. Are you working days and nights on pgAdmin3? As you know RH packaging well, I would like to know how to disable stripping, which is RH default behavior. This will enable me to produce full debug RPMs. Any idea? Cheers, Jean-Michel
Hello, On Wed, 2003-10-22 at 15:18, Jean-Michel POURE wrote: > Are you working days and nights on pgAdmin3? Certainly not ;-) - But I found a bug in the query window (cannot see curser), and I wanted to be sure that the bug still exists in current CVS before reporting it. > As you know RH packaging well, I would like to know how to disable stripping, > which is RH default behavior. I'm not so sure that your RPMs contain stripped binary code. When I extract the .o files contained in libwx_gtk2ud-2.5.a and run "file" on them, file tells me that only 20 out of 290 object files are stripped. Strange; either the "file" utility is wrong, or only a small subset of the object files are stripped, for some reason. Anyways, a hack prevent RPM from stripping (:-)) might be to put this in the head of the spec-file?: %define __strip /bin/true Hopefully, there is a cleaner way of doing it, but I don't know of any. -- Greetings from Troels Arvin, Copenhagen, Denmark
Le Mercredi 22 Octobre 2003 15:35, Troels Arvin a écrit : > %define __strip /bin/true Thanks, added to spec.
Hello,
On Wed, 2003-10-22 at 15:35, I wrote (subject "Re: [pgadmin-hackers]
Cannot build latest CVS"):
> Anyways, a hack prevent RPM from stripping (:-)) might be to put this in
> the head of the spec-file?:
> %define __strip /bin/true
Doesn't work. This does:
%define debug_package %{nil}
%define __os_install_post /usr/lib/rpm/brp-compress
First line disables building of separate -debuginfo packages (default on
Red Hat 9). Second line cuts down on the default post-installation steps
(normally, there are four in stead of the one above), so that it only
boils down to compression of man-pages.
I also recommend adding the following two lines right after the "%build"
line, just before the "%configure ..."-line:
export CFLAGS=""
export CXXFLAGS=""
These two lines will unset whatever optimization environment variables
which might be part of the global environment.
Of course, I hope that such anti-optimization steps are not part of the
production-RPMs.
--
Greetings from Troels Arvin, Copenhagen, Denmark
Troels Arvin wrote: >Hello, > >On Wed, 2003-10-22 at 14:38, Dave Page wrote: > > >>There was a new update to the wx tarball this morning, though >>Jean-Michel may not have produced RPMs yet. You need the -4 version >>which is on Snake in tar.bz2 format. >> >> > >OK; thanks. I'll build a new set of RPMS locally. > >As long as pgadmin3 is so dependent on certain changes in wxWindows, >then wouldn't it be nice to keep the needed patch(es) somewhere in >pgadmin3's CVS tree? > We have the patches directory under http://snake.pgadmin.org/snapshots/wxwindows/patches, which includes all the stuff needed for a working wxWindows. This is nothing for pgadmin cvs. >- For example a patch agains current wxWindows CVS HEAD? > This would rise the problems to the power of 3 or 4.... We're glad we have a wx snapshot that's working for all needed platforms now. Besides, all fixes should apply to head also. Certainly, it would be a good idea if those patches would go into wx cvs head. You can check the (non-)progress on SourceForge, look at the case numbers in readme-patches.txt. Regards, Andreas