Thread: C++ interface build on FreeBSD 4.2 broken?
It is reported that building C++ interface on FreeBSD 4.2 fails. Can someone comment on this? c++ -pipe -O3 -mpentiumpro -Wall -fpic -DPIC -I/usr/local/ssl/include -I../../../src/include -I../../../src/interfaces/libpq -c -o pgconnec tion.o pgconnection.cc In file included from ../../../src/include/postgres.h:40, from pgconnection.h:41, from pgconnection.cc:18: ../../../src/include/c.h:997: conflicting types for `int sys_nerr' /usr/include/stdio.h:224: previous declaration as `const int sys_nerr' gmake[3]: *** [pgconnection.o] Error 1 gmake[3]: Leaving directory `/home/ichimura/Work/postgresql-snapshot/s rc/interfaces/libpq++' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/ichimura/Work/postgresql-snapshot/s rc/interfaces' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/ichimura/Work/postgresql-snapshot/s rc' gmake: *** [all] Error 2
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> It is reported that building C++ interface on FreeBSD 4.2 fails.
> Can someone comment on this?
> In file included from ../../../src/include/postgres.h:40,
> from pgconnection.h:41,
> from pgconnection.cc:18:
> ../../../src/include/c.h:997: conflicting types for `int sys_nerr'
> /usr/include/stdio.h:224: previous declaration as `const int sys_nerr'
> gmake[3]: *** [pgconnection.o] Error 1
A quick look at hub.org confirms:
> uname -a
FreeBSD hub.org 4.2-STABLE FreeBSD 4.2-STABLE #0: Tue Dec 19 07:52:31 EST 2000
root@hub.org:/home/projects/pgsql/operating_system/obj/home/projects/pgsql/operating_system/src/sys/kernel i386
> grep sys_nerr /usr/include/*.h
/usr/include/stdio.h:extern __const int sys_nerr; /* perror(3) external variables */
Sigh. Looks like we need yet another configure test. Or maybe it's
better to just cut and run on the check for in-range errno; although
I put that in to begin with, I'm certainly starting to wonder if it's
worth the trouble. Comments anyone?
regards, tom lane
Tatsuo Ishii writes: > c++ -pipe -O3 -mpentiumpro -Wall -fpic -DPIC -I/usr/local/ssl/include > -I../../../src/include -I../../../src/interfaces/libpq -c -o pgconnec > tion.o pgconnection.cc > In file included from ../../../src/include/postgres.h:40, > from pgconnection.h:41, > from pgconnection.cc:18: > ../../../src/include/c.h:997: conflicting types for `int sys_nerr' > /usr/include/stdio.h:224: previous declaration as `const int sys_nerr' > gmake[3]: *** [pgconnection.o] Error 1 C++ apparently doesn't allow this, but C does. So you have to put #ifndef __cplusplus at the appropriate place in c.h. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
>> ../../../src/include/c.h:997: conflicting types for `int sys_nerr'
>> /usr/include/stdio.h:224: previous declaration as `const int sys_nerr'
> C++ apparently doesn't allow this, but C does. So you have to put #ifndef
> __cplusplus at the appropriate place in c.h.
Er, what will you ifdef exactly, and what are the odds that it will fail
on some other platform? (On my machine, for example, sys_nerr is
definitely NOT declared const by the system header files, and so adding
a const decoration to our declaration would fail.)
I think our choices are to do a configure test or to stop using sys_nerr
altogether. At the moment I'm kind of leaning towards the latter.
I suspect machines whose strerror() is without a rangecheck are history,
and even if they're not, it's unproven that we ever pass a bogus errno
to strerror anyway.
regards, tom lane
Tom Lane writes: > Peter Eisentraut <peter_e@gmx.net> writes: > >> ../../../src/include/c.h:997: conflicting types for `int sys_nerr' > >> /usr/include/stdio.h:224: previous declaration as `const int sys_nerr' > > > C++ apparently doesn't allow this, but C does. So you have to put #ifndef > > __cplusplus at the appropriate place in c.h. > > Er, what will you ifdef exactly, + #ifdef __cplusplus #ifdef HAVE_SYS_NERR extern int sys_nerr; #endif + #endif > and what are the odds that it will fail on some other platform? I don't see how it would fail. At least it won't add more possible failure cases. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Er, what will you ifdef exactly,
> + #ifdef __cplusplus
> #ifdef HAVE_SYS_NERR
> extern int sys_nerr;
> #endif
> + #endif
>> and what are the odds that it will fail on some other platform?
> I don't see how it would fail. At least it won't add more possible
> failure cases.
If that can't fail, why do we need to provide a declaration of sys_nerr
at all?
regards, tom lane
Tom Lane writes: > Peter Eisentraut <peter_e@gmx.net> writes: > > Tom Lane writes: > >> Er, what will you ifdef exactly, > > > + #ifdef __cplusplus #ifndef, I meant. I.e., only declare it when in C, since libpq++ does not use it. libpq doesn't use it either, but it uses tons of strerror(). > > #ifdef HAVE_SYS_NERR > > extern int sys_nerr; > > #endif > > + #endif > > >> and what are the odds that it will fail on some other platform? > > > I don't see how it would fail. At least it won't add more possible > > failure cases. > > If that can't fail, why do we need to provide a declaration of sys_nerr > at all? > > regards, tom lane > > -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> libpq doesn't use it either, but it uses tons of strerror().
And also there are quite a few places in the backend that use strerror()
directly. This lack of consistency seems like another reason to forget
about testing errno against sys_nerr in elog() ...
regards, tom lane
On Sat, Jan 20, 2001 at 02:18:55PM -0500, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > libpq doesn't use it either, but it uses tons of strerror(). > > And also there are quite a few places in the backend that use strerror() > directly. This lack of consistency seems like another reason to forget > about testing errno against sys_nerr in elog() ... All relevant standards discourage use of sys_nerr too. There was a discussion on cygwin lists once ... *searching* in <http://cygwin.com/ml/cygwin/1999-11/msg00097.html> From: "J. J. Farrell" <jjf at bcs dot org dot uk> [ about using sys_nerr & sys_errlist ] > Nothing written in the last 10 years or so should be using these > anyway; strerror() was introduced in C89 and POSIX.1 to replace > them, as Mumit pointed out. ... -- marko
What I've done to solve the immediate C++ problem is to take the
declaration of sys_nerr out of c.h entirely, and put it into the
two C modules that actually need it. However, I'm still wondering
whether we should not drop the rangecheck on errno completely.
One interesting thing I discovered while wandering the web is that
on at least some flavors of Windows, there are valid negative values
of errno --- which our code will not convert to a useful string,
as it stands...
regards, tom lane
On Sat, Jan 20, 2001 at 08:06:51PM -0500, Tom Lane wrote: > What I've done to solve the immediate C++ problem is to take the > declaration of sys_nerr out of c.h entirely, and put it into the > two C modules that actually need it. However, I'm still wondering > whether we should not drop the rangecheck on errno completely. Probably not useful, but in our <errno.h>, sys_nerr is defined #if !defined(_ANSI_SOURCE) && !defined(_POSIX_C_SOURCE) && \ !defined(_XOPEN_SOURCE) P