Thread: problem compiling 6.5 cvs (Linux, gcc 2.7.2, egcs 1.12)
Sereval days I can't compile 6.5 cvs sources under Linux,
I got sporadical errors so I suspected it's compiler/hardware
problem. I'm using egcs 1.12 release.
I moved to another Linux box, download cvs again, used gcc 2.7.2
and still has a problem:
make[2]: Entering directory /usr2/u/postgres/cvs/pgsql/src/backend/postmaster'
gcc -I../../include -I../../backend -O2 -m486 -Wall -Wmissing-prototypes -I.. -c postmaster.c -o postmaster.o
postmaster.c: In function erverLoop':
postmaster.c:665: too few arguments to function ettimeofday'
postmaster.c:704: too few arguments to function ettimeofday'
postmaster.c:663: warning: unused variable z'
postmaster.c: In function oBackend':
postmaster.c:1503: too few arguments to function ettimeofday'
postmaster.c:1456: warning: unused variable z'
make[2]: *** [postmaster.o] Error 1
Has anyone successfully compiled latest cvs sources under Linux or these
problems are just mine ?
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
On Tue, 11 May 1999, Oleg Bartunov wrote: > Sereval days I can't compile 6.5 cvs sources under Linux, > I got sporadical errors so I suspected it's compiler/hardware > problem. I'm using egcs 1.12 release. I have had no problems with redhat 5.2(gcc 2.7.2.3, glibc 2.0) But with redhat 6.0(egcs 1.1.2, glibc 2.1) I'm having one problem. psql doesn't compile :) psql.c:152: initializer element is not constant which is static FILE * cur_cmd_source = stdin; I don't believe I have ever seen that error, and I don't know why it has problems with that line. Other than that it works great here. Ole Gjerde
Something is weird for me. After posting my problems with compiling 6.5 cvs
I compiled the same cvs source at home using egcs-1.12 release.
Everything was ok and regression tests passed as usual with some of
them failed (int2,int4, triggers etc). At home I run Linux 2.2.7 while at
work I use Linux 2.0.36. Could this be a problem ?
Regards,
Oleg
On Tue, 11 May 1999 gjerde@icebox.org wrote:
> Date: Tue, 11 May 1999 04:24:50 -0500 (CDT)
> From: gjerde@icebox.org
> To: Oleg Bartunov <oleg@sai.msu.su>
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] problem compiling 6.5 cvs (Linux, gcc 2.7.2, egcs 1.12)
>
> On Tue, 11 May 1999, Oleg Bartunov wrote:
> > Sereval days I can't compile 6.5 cvs sources under Linux,
> > I got sporadical errors so I suspected it's compiler/hardware
> > problem. I'm using egcs 1.12 release.
>
> I have had no problems with redhat 5.2(gcc 2.7.2.3, glibc 2.0)
> But with redhat 6.0(egcs 1.1.2, glibc 2.1) I'm having one problem.
> psql doesn't compile :)
> psql.c:152: initializer element is not constant
> which is
> static FILE * cur_cmd_source = stdin;
>
> I don't believe I have ever seen that error, and I don't know why it has
> problems with that line.
>
> Other than that it works great here.
>
> Ole Gjerde
>
>
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
On Tue, 11 May 1999, Oleg Bartunov wrote: > Something is weird for me. After posting my problems with compiling 6.5 cvs > I compiled the same cvs source at home using egcs-1.12 release. > Everything was ok and regression tests passed as usual with some of > them failed (int2,int4, triggers etc). At home I run Linux 2.2.7 while at > work I use Linux 2.0.36. Could this be a problem ? Shouldn't be. However, have been using 2.2.x for a while, so I'm not sure. It unlikely tho, since I'm sure many people are still running 2.0.36.. Are you sure /usr/include/linux is a symlink to /usr/src/linux/include/linux? What glibc version are you running and when did you update your CVS source last? ---- I did find a solution to the psql.c compiling problem with glibc 2.1. If you change the static FILE * cur_cmd_source = stdin; to static FILE * cur_cmd_source; and then add cur_cmd_source = stdin; to main() it seems to both compile and work fine. Maybe I'm too tired to figure out that static is making a difference in this case :) Ole Gjerde
gjerde@icebox.org writes:
> But with redhat 6.0(egcs 1.1.2, glibc 2.1) I'm having one problem.
> psql doesn't compile :)
> psql.c:152: initializer element is not constant
> which is
> static FILE * cur_cmd_source = stdin;
> I don't believe I have ever seen that error, and I don't know why it has
> problems with that line.
You have a broken compiler IMHO --- on any reasonable system, stdin
should be a load-time constant address, and load-time constants are
required by the standard to be acceptable initializers for statics.
Either stdin is defined in a very peculiar way, or the compiler is
incapable of handling non-compile-time-constant initializers. In
either case it's gonna fail on a lot more things than just Postgres.
However, it's easy enough to work around it (as you noted in your
followup). I'll commit the change.
Re Oleg's original complaint: I'm not seeing any problem with a
CVS fileset that I pulled afresh on Saturday morning. I think
he somehow got a corrupted copy...
regards, tom lane
On Tue, 11 May 1999, Tom Lane wrote: > Date: Tue, 11 May 1999 10:35:55 -0400 > From: Tom Lane <tgl@sss.pgh.pa.us> > To: gjerde@icebox.org > Cc: Oleg Bartunov <oleg@sai.msu.su>, pgsql-hackers@postgreSQL.org > Subject: Re: [HACKERS] problem compiling 6.5 cvs (Linux, gcc 2.7.2, egcs 1.12) > > gjerde@icebox.org writes: > > But with redhat 6.0(egcs 1.1.2, glibc 2.1) I'm having one problem. > > psql doesn't compile :) > > psql.c:152: initializer element is not constant > > which is > > static FILE * cur_cmd_source = stdin; > > > I don't believe I have ever seen that error, and I don't know why it has > > problems with that line. > > You have a broken compiler IMHO --- on any reasonable system, stdin > should be a load-time constant address, and load-time constants are > required by the standard to be acceptable initializers for statics. > Either stdin is defined in a very peculiar way, or the compiler is > incapable of handling non-compile-time-constant initializers. In > either case it's gonna fail on a lot more things than just Postgres. > > However, it's easy enough to work around it (as you noted in your > followup). I'll commit the change. > I have no problem with that specific case, but I had a problem with compiling latest cvs which arises from wrong configure suggestion - I had to make change in config.h #define HAVE_GETTIMEOFDAY_2_ARGS 1 to compile cvs sources. This happens only recently because I've never seen this problem. > > Re Oleg's original complaint: I'm not seeing any problem with a > CVS fileset that I pulled afresh on Saturday morning. I think > he somehow got a corrupted copy... I too, at home :-) At work I still have sporadical errors in compiling on one of my machine (Linux 2.0.36, libc5 5.0.46, egcs 1.12 -release). On another machine (Linux 2.0.36, gcc 2.7.2.3, ibc5 5.0.46) after trivial change in config.h (see above) I got fully workablepostgres :-) All sources were identical. I did resync of cvs. So, actually I have weird problem only on one machine and I'll see what were changed in my setup. > > regards, tom lane > _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Oleg Bartunov <oleg@sai.msu.su> writes:
> I have no problem with that specific case, but I had a problem
> with compiling latest cvs which arises from wrong configure suggestion -
> I had to make change in config.h
> #define HAVE_GETTIMEOFDAY_2_ARGS 1
> to compile cvs sources. This happens only recently because
> I've never seen this problem.
Hmm, that's annoying isn't it? Would you please look at configure.in
and see if you can find out why it's making the wrong guess on your
system?
regards, tom lane