Обсуждение: solaris 10 with gcc 3.3.2
Should I be able to compile with gcc 3.3.2 (from sunfreeware) on solaris 10?
I'm using sparc, and am getting some strange looking compiler errors when
trying to do the make.
I'm getting some compiler parse errors when compiling exec.c.
make -C doc all
make[1]: Entering directory
`/export/home/pbelbin/projects/postgresql-8.0.0beta5/doc'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/export/home/pbelbin/projects/postgresql-8.0.0beta5/doc'
make -C src all
make[1]: Entering directory
`/export/home/pbelbin/projects/postgresql-8.0.0beta5/src'
make -C port all
make[2]: Entering directory
`/export/home/pbelbin/projects/postgresql-8.0.0beta5/src/port'
gcc -DPOSIX -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels
-fno-strict-aliasing -I../../src/port -DFRONTEND -I../../src/include -c -o
exec.o exec.c
In file included from /usr/include/sys/wait.h:24,
from exec.c:26:
/usr/include/sys/siginfo.h:259: error: parse error before "ctid_t"
/usr/include/sys/siginfo.h:292: error: parse error before '}' token
/usr/include/sys/siginfo.h:294: error: parse error before '}' token
/usr/include/sys/siginfo.h:390: error: parse error before "ctid_t"
/usr/include/sys/siginfo.h:392: error: conflicting types for `__proc'
/usr/include/sys/siginfo.h:261: error: previous declaration of `__proc'
/usr/include/sys/siginfo.h:398: error: conflicting types for `__fault'
/usr/include/sys/siginfo.h:267: error: previous declaration of `__fault'
/usr/include/sys/siginfo.h:404: error: conflicting types for `__file'
/usr/include/sys/siginfo.h:273: error: previous declaration of `__file'
/usr/include/sys/siginfo.h:420: error: conflicting types for `__prof'
/usr/include/sys/siginfo.h:287: error: previous declaration of `__prof'
/usr/include/sys/siginfo.h:424: error: conflicting types for `__rctl'
/usr/include/sys/siginfo.h:291: error: previous declaration of `__rctl'
/usr/include/sys/siginfo.h:426: error: parse error before '}' token
/usr/include/sys/siginfo.h:428: error: parse error before '}' token
/usr/include/sys/siginfo.h:432: error: parse error before "k_siginfo_t"
/usr/include/sys/siginfo.h:437: error: parse error before '}' token
In file included from /usr/include/sys/procset.h:24,
from /usr/include/sys/wait.h:25,
from exec.c:26:
/usr/include/sys/signal.h:85: error: parse error before "siginfo_t"
In file included from exec.c:26:
/usr/include/sys/wait.h:86: error: parse error before "siginfo_t"
make[2]: *** [exec.o] Error 1
make[2]: Leaving directory
`/export/home/pbelbin/projects/postgresql-8.0.0beta5/src/port'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/export/home/pbelbin/projects/postgresql-8.0.0beta5/src'
make: *** [all] Error 2
NOTICE: This electronic mail transmission may contain confidential
information and is intended only for the person(s) named. Any use, copying
or disclosure by any other person is strictly prohibited. If you have
received this transmission in error, please notify the sender via e-mail.
"Belbin, Peter" <PBelbin@McLeodUSA.com> writes:
> Should I be able to compile with gcc 3.3.2 (from sunfreeware) on solaris 10?
Yes ...
> gcc -DPOSIX -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels
> -fno-strict-aliasing -I../../src/port -DFRONTEND -I../../src/include -c -o
> exec.o exec.c
> In file included from /usr/include/sys/wait.h:24,
> from exec.c:26:
> /usr/include/sys/siginfo.h:259: error: parse error before "ctid_t"
> /usr/include/sys/siginfo.h:292: error: parse error before '}' token
This looks like your platform's <sys/wait.h> is not designed to be
included free-standing, but requires certain other system headers to be
included first. (This is poor practice, but seen all too often :-()
A fairly likely guess is that the missing header is <sys/types.h>.
You might be able to find out for sure by checking the man page for
waitpid() and related system calls ... or just try hacking exec.c till
it compiles.
It's likely that exec.c is not the only place missing the extra
include(s). Please send a patch after you get it all to build.
regards, tom lane
It seems that rather than using the /usr/include/sys/types.h, gcc 3.3.2 is
instead, using a version of the same file, located at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.10/3.3.2/include/sys, which does
not have a definition for ctid_t
Presumedly there's either something bogus about the gcc for solaris 10, or
perhaps there's a way to get gcc to ignore the gcc version, and use the
'normal' version......?
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Sunday, December 12, 2004 12:04 AM
To: Belbin, Peter
Cc: pgsql-bugs@postgreSQL.org
Subject: Re: [BUGS] solaris 10 with gcc 3.3.2
"Belbin, Peter" <PBelbin@McLeodUSA.com> writes:
> Should I be able to compile with gcc 3.3.2 (from sunfreeware) on solaris
10?
Yes ...
> gcc -DPOSIX -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels
> -fno-strict-aliasing -I../../src/port -DFRONTEND -I../../src/include -c
-o
> exec.o exec.c
> In file included from /usr/include/sys/wait.h:24,
> from exec.c:26:
> /usr/include/sys/siginfo.h:259: error: parse error before "ctid_t"
> /usr/include/sys/siginfo.h:292: error: parse error before '}' token
This looks like your platform's <sys/wait.h> is not designed to be included
free-standing, but requires certain other system headers to be included
first. (This is poor practice, but seen all too often :-() A fairly likely
guess is that the missing header is <sys/types.h>.
You might be able to find out for sure by checking the man page for
waitpid() and related system calls ... or just try hacking exec.c till it
compiles.
It's likely that exec.c is not the only place missing the extra include(s).
Please send a patch after you get it all to build.
regards, tom lane
NOTICE: This electronic mail transmission may contain confidential
information and is intended only for the person(s) named. Any use, copying
or disclosure by any other person is strictly prohibited. If you have
received this transmission in error, please notify the sender via e-mail.
"Belbin, Peter" <PBelbin@McLeodUSA.com> writes:
> It seems that rather than using the /usr/include/sys/types.h, gcc 3.3.2 is
> instead, using a version of the same file, located at
> /usr/local/lib/gcc-lib/sparc-sun-solaris2.10/3.3.2/include/sys, which does
> not have a definition for ctid_t
This is standard practice for gcc: it tries to use "cleaned up" versions
of system headers that will not elicit useless warnings from gcc. It's
a good idea, actually, because the degree of insanity in vendor-supplied
system headers is pretty depressing. But if the gcc install process
generated an invalid "cleanup" file then you need to take that up with
the gcc boys, not us.
regards, tom lane
I wrote:
> This is standard practice for gcc: it tries to use "cleaned up" versions
> of system headers that will not elicit useless warnings from gcc. It's
> a good idea, actually, because the degree of insanity in vendor-supplied
> system headers is pretty depressing. But if the gcc install process
> generated an invalid "cleanup" file then you need to take that up with
> the gcc boys, not us.
On rereading this, a nearly-dead neuron fired --- I have seen problems
of this sort arise when someone took a gcc installation generated on
NiftyVendorUnix M.N and copied it verbatim to NiftyVendorUnix M.N+1,
or indeed any release other than M.N. Then you have a situation where
gcc is inserting cleaned-up versions of some system headers but not
others (because it doesn't force the issue when it doesn't have to),
and if the vendor did something like move a typedef from one header
to another, you lose, because the cleaned-up headers are not in sync
with the others.
In short ... where'd you get your gcc installation from?
regards, tom lane
Tom Lane wrote: >I wrote: > > >>This is standard practice for gcc: it tries to use "cleaned up" versions >>of system headers that will not elicit useless warnings from gcc. It's >>a good idea, actually, because the degree of insanity in vendor-supplied >>system headers is pretty depressing. But if the gcc install process >>generated an invalid "cleanup" file then you need to take that up with >>the gcc boys, not us. >> >> > >On rereading this, a nearly-dead neuron fired --- I have seen problems >of this sort arise when someone took a gcc installation generated on >NiftyVendorUnix M.N and copied it verbatim to NiftyVendorUnix M.N+1, >or indeed any release other than M.N. > > That nearly-dead neuron has value. The problem is that most people are getting the Solaris 10 beta builds whose headers conflict with the gcc 3.3.2 package's 'adapted' headers they are acquiring from sunfreeware.com, which, along with distributing other binary packages, is the place referred to by gcc.gnu.org for pre-built Solaris binaries. All the original poster needs to do is rebuild the gcc's 'adapted' headers with: # cd /usr/local/lib/gcc-lib/i386-pc-solaris2.10/3.3.2/install-tools # ./mkheaders and they should be good to go.... Mike Mascari
Mike Mascari wrote: > Tom Lane wrote: > >> I wrote: >> >> >>> This is standard practice for gcc: it tries to use "cleaned up" >>> versions >>> of system headers that will not elicit useless warnings from gcc. It's >>> a good idea, actually, because the degree of insanity in >>> vendor-supplied >>> system headers is pretty depressing. But if the gcc install process >>> generated an invalid "cleanup" file then you need to take that up with >>> the gcc boys, not us. >>> >> >> >> On rereading this, a nearly-dead neuron fired --- I have seen problems >> of this sort arise when someone took a gcc installation generated on >> NiftyVendorUnix M.N and copied it verbatim to NiftyVendorUnix M.N+1, >> or indeed any release other than M.N. >> > That nearly-dead neuron has value. The problem is that most people are > getting the Solaris 10 beta builds whose headers conflict with the gcc > 3.3.2 package's 'adapted' headers they are acquiring from > sunfreeware.com, which, along with distributing other binary packages, > is the place referred to by gcc.gnu.org for pre-built Solaris > binaries. All the original poster needs to do is rebuild the gcc's > 'adapted' headers with: > > # cd /usr/local/lib/gcc-lib/i386-pc-solaris2.10/3.3.2/install-tools > # ./mkheaders > > and they should be good to go.... Actually, I see the original poster is on SPARC, so the correct path to the 'mkheaders' utility is probably going to be: # cd /usr/local/lib/gcc-lib/sparc-sun-solaris2.10/3.3.2/install-tools # ./mkheaders Mike Mascari
Tom,
Yeah, I've already fired off a query about this gcc build to the source.
In my case, I downloaded it from www.sunfreeware.com, and, for good measure,
I also tried gcc 3.4.2 for solaris 9, on a solaris 10 box, and, indeed, it
looks like the same problem is there.
So, it's entirely possible that the build they've got listed for 10 was
either built on a version of solaris 10 which was earlier than what I'm
using (b69), or, it could have been built on a solaris 9 box.
Either way, I'm asking about it, because it does seem, to me, to be a gcc
problem.
I could try building gcc myself, but, that won't fix the problem with the
version on the sunfreeware site, which a lot of people rely on, I expect.
Regards,
Peter.
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Saturday, December 18, 2004 12:00 AM
To: Belbin, Peter
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] solaris 10 with gcc 3.3.2
I wrote:
> This is standard practice for gcc: it tries to use "cleaned up"
> versions of system headers that will not elicit useless warnings from
> gcc. It's a good idea, actually, because the degree of insanity in
> vendor-supplied system headers is pretty depressing. But if the gcc
> install process generated an invalid "cleanup" file then you need to
> take that up with the gcc boys, not us.
On rereading this, a nearly-dead neuron fired --- I have seen problems of
this sort arise when someone took a gcc installation generated on
NiftyVendorUnix M.N and copied it verbatim to NiftyVendorUnix M.N+1, or
indeed any release other than M.N. Then you have a situation where gcc is
inserting cleaned-up versions of some system headers but not others (because
it doesn't force the issue when it doesn't have to), and if the vendor did
something like move a typedef from one header to another, you lose, because
the cleaned-up headers are not in sync with the others.
In short ... where'd you get your gcc installation from?
regards, tom lane
NOTICE: This electronic mail transmission may contain confidential
information and is intended only for the person(s) named. Any use, copying
or disclosure by any other person is strictly prohibited. If you have
received this transmission in error, please notify the sender via e-mail.
I got a response from Steve (of SunFreeware) and he also has put some info up on the site about regenerating the cleaned-up files. I've done this with the gcc 3.3.2 for solaris 10, and have now successfully built postgresql rc1. I haven't tried executing it yet, but at least it's built without complaints. Thank you for your help. regards, Peter. -----Original Message----- From: Mike Mascari [mailto:mascarm@mascari.com] Sent: Saturday, December 18, 2004 5:03 AM To: Tom Lane Cc: Belbin, Peter; pgsql-bugs@postgresql.org Subject: Re: [BUGS] solaris 10 with gcc 3.3.2 Mike Mascari wrote: > Tom Lane wrote: > >> I wrote: >> >> >>> This is standard practice for gcc: it tries to use "cleaned up" >>> versions >>> of system headers that will not elicit useless warnings from gcc. >>> It's a good idea, actually, because the degree of insanity in >>> vendor-supplied system headers is pretty depressing. But if the gcc >>> install process generated an invalid "cleanup" file then you need to >>> take that up with the gcc boys, not us. >>> >> >> >> On rereading this, a nearly-dead neuron fired --- I have seen >> problems of this sort arise when someone took a gcc installation >> generated on NiftyVendorUnix M.N and copied it verbatim to NiftyVendorUnix M.N+1, >> or indeed any release other than M.N. >> > That nearly-dead neuron has value. The problem is that most people are > getting the Solaris 10 beta builds whose headers conflict with the gcc > 3.3.2 package's 'adapted' headers they are acquiring from > sunfreeware.com, which, along with distributing other binary packages, > is the place referred to by gcc.gnu.org for pre-built Solaris > binaries. All the original poster needs to do is rebuild the gcc's > 'adapted' headers with: > > # cd /usr/local/lib/gcc-lib/i386-pc-solaris2.10/3.3.2/install-tools > # ./mkheaders > > and they should be good to go.... Actually, I see the original poster is on SPARC, so the correct path to the 'mkheaders' utility is probably going to be: # cd /usr/local/lib/gcc-lib/sparc-sun-solaris2.10/3.3.2/install-tools # ./mkheaders Mike Mascari NOTICE: This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.