7.0RC2 compile error !

Hi all,

I am running mandrake 7.0 on an AMD450
when trying to complie 7.0RC2 I get the folowing error :-

In file included from pgconnection.cc:18:
pgconnection.h:84: syntax error before `('
pgconnection.cc:116: syntax error before `::'
...........

Well, seems it is in the libpq++ compile. I am confused why you are
having a problem at that point in the compile, though.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Yes:

g++ -v

--
Bruce Momjian                        |  http://www.op.net/~candle
pgman@candle.pha.pa.us               |  (610) 853-3000
+  If your life is a hard drive,     |  830 Blythe Avenue
+  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Reading specs from /usr/lib/gcc-lib/i586-mardrake-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)

Pretty recent. It certainly compiles under gcc version 2.7.2.1. Strange.

Maybe it is a buggy g++. Just a guess.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Pretty recent. It certainly compiles under gcc version 2.7.2.1. Strange.
Maybe it is a buggy g++. Just a guess.

I'm running the same distro/version and the current cvs tree (a bit
more recent than Frank's example afaik) compiles without errors.

I'll guess that it is a configuration issue on Frank's machine, or
that RC2 predates the last libpq++ code fixes.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

Thomas Lockhart wrote:

Pretty recent. It certainly compiles under gcc version 2.7.2.1. Strange.
Maybe it is a buggy g++. Just a guess.

I'm running the same distro/version and the current cvs tree (a bit
more recent than Frank's example afaik) compiles without errors.

I'll guess that it is a configuration issue on Frank's machine, or
that RC2 predates the last libpq++ code fixes.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

Well I just downloaded 7.0RC3 and it still produces
the same compiler errors :(
As far as my machine configuration, the machine I
just compiled this on is a new install Mandrake 7.0 no
fiddles, so I can only assume that everyone with this
distr can expect this problem.
BTW Mandrake just became #1 download distro.

Where do I go from here ? (be nice ;)

On Wed, 03 May 2000, frank wrote:

Thomas Lockhart wrote:

I'm running the same distro/version and the current cvs tree (a bit
more recent than Frank's example afaik) compiles without errors.

Well I just downloaded 7.0RC3 and it still produces
the same compiler errors :(
As far as my machine configuration, the machine I
just compiled this on is a new install Mandrake 7.0 no
fiddles, so I can only assume that everyone with this
distr can expect this problem.
BTW Mandrake just became #1 download distro.

Where do I go from here ? (be nice ;)

Thomas: rpm -qa >thomas.rpm-list
Frank: rpm -qa >frank.rpm-list

Thomas, send thomas.rpm-list to Frank.

Frank, diff thomas.rpm-list frank.rpm-list and see what development libraries
etc Thomas has that you don't.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Wed, May 03, 2000 at 09:32:53AM -0400, frank wrote:

Well I just downloaded 7.0RC3 and it still produces
the same compiler errors :(
As far as my machine configuration, the machine I
just compiled this on is a new install Mandrake 7.0 no
fiddles, so I can only assume that everyone with this
distr can expect this problem.
BTW Mandrake just became #1 download distro.

Where do I go from here ? (be nice ;)

Configuration details: did you feed ./configure any special switches?

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

Where do I go from here ? (be nice ;)

Configuration details: did you feed ./configure any special switches?

The output of configure would also be interesting. Also, I've forgotten
exactly what the error messages you got were? (Time for another whine
about the sad state of the pghackers archives :-()

regards, tom lane

frank <f.callaghan@ieee.org> writes:

Configuration details: did you feed ./configure any special switches?

The output of configure would also be interesting. Also, I've forgotten
exactly what the error messages you got were? (Time for another whine
about the sad state of the pghackers archives :-()

In file included from pgconnection.cc:18:
pgconnection.h:84: syntax error before `('
pgconnection.cc:116: syntax error before `::'

OK, both of those are pointing at uses of datatype "string". I suspect
that this code near the head of pgconnection.h is failing to fire:

#ifdef HAVE_CXX_STRING_HEADER
#include <string>
#endif

either because you indeed haven't got the C++ standard <string> header
(not to be confused with C's <string.h> --- is there a separate "devel"
RPM for C++ header files? if so, do you have it?), or because configure
got confused and failed to define HAVE_CXX_STRING_HEADER when it should.
Can't tell which though; the config.cache file you sent doesn't record
anything about HAVE_CXX_STRING_HEADER.

regards, tom lane

frank <f.callaghan@ieee.org> writes:

(on errors with Mandrake)

Well I just downloaded 7.0RC3 and it still produces
the same compiler errors :(

It compiles just fine on Red Hat Linux 6.2

This wouldn't be the first time Mandrake ship a bad compiler - try to
install the ones from Red Hat 6.2 (and libstdc++ w/headers) and see if
that works.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

On Wed, 3 May 2000, Tom Lane wrote:

Where do I go from here ? (be nice ;)

Configuration details: did you feed ./configure any special switches?

The output of configure would also be interesting. Also, I've forgotten
exactly what the error messages you got were? (Time for another whine
about the sad state of the pghackers archives :-()

wait, now I'm confused ... I just did a ... oops ... hold ... let me fix
that last archive file ... brb ...

okay, check it now ... just got the Apr stuff that was directed to the
wrong directory parsed back in, mhonarc'd and is currently indexing ...

On Wed, 3 May 2000, The Hermit Hacker wrote:

On Wed, 3 May 2000, Tom Lane wrote:

Where do I go from here ? (be nice ;)

Configuration details: did you feed ./configure any special switches?

The output of configure would also be interesting. Also, I've forgotten
exactly what the error messages you got were? (Time for another whine
about the sad state of the pghackers archives :-()

wait, now I'm confused ... I just did a ... oops ... hold ... let me fix
that last archive file ... brb ...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

frank <f.callaghan@ieee.org> writes:

Yup your dead right, the <string> include failed in the configure.
Isn't configure supposed to tell the user that something failed ?,
I have no idea what is an acceptable configuration for this s/w !

checking for namespace std in C++... yes
checking for include <string> in C++... no

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Yup, there's our problem. Your C++ setup is evidently pretty modern,
since it knows what namespace std is. My guess is that you don't have
the headers for libstdc++ installed.

It would probably be a good idea to add another configure test to see
whether class "string" is actually available, and disable building
libpq++ if not. (We shouldn't simply kill libpq++ if the "include
<string>" test fails, since older C++ installations may have class
string in <string.h>. But if we can't find a header that defines class
string at all, then libpq++ is definitely going to fall over.)

Any objections if I sneak in such a configure test? Should be a
low-risk change.

regards, tom lane

On Wed, 3 May 2000, Tom Lane wrote:

frank <f.callaghan@ieee.org> writes:

Yup your dead right, the <string> include failed in the configure.
Isn't configure supposed to tell the user that something failed ?,
I have no idea what is an acceptable configuration for this s/w !

checking for namespace std in C++... yes
checking for include <string> in C++... no

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Yup, there's our problem. Your C++ setup is evidently pretty modern,
since it knows what namespace std is. My guess is that you don't have
the headers for libstdc++ installed.

It would probably be a good idea to add another configure test to see
whether class "string" is actually available, and disable building
libpq++ if not. (We shouldn't simply kill libpq++ if the "include
<string>" test fails, since older C++ installations may have class
string in <string.h>. But if we can't find a header that defines class
string at all, then libpq++ is definitely going to fall over.)

Any objections if I sneak in such a configure test? Should be a
low-risk change.

go for it, I want to do up a quick RC4 with th efixes to the docs that I
did the other day, so let me know when, and I'll do it then ...

The Hermit Hacker <scrappy@hub.org> writes:

Any objections if I sneak in such a configure test? Should be a
low-risk change.

go for it, I want to do up a quick RC4 with th efixes to the docs that I
did the other day, so let me know when, and I'll do it then ...

OK, done.

regards, tom lane

done ... there is an RC4 there now, with just your configure changes and
the docs ones ...

This will be the release on Monday unless anyone has anything else major
to add ... :)

On Wed, 3 May 2000, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

Any objections if I sneak in such a configure test? Should be a
low-risk change.

go for it, I want to do up a quick RC4 with th efixes to the docs that I
did the other day, so let me know when, and I'll do it then ...

OK, done.

regards, tom lane

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

Tom Lane writes:

It would probably be a good idea to add another configure test to see
whether class "string" is actually available, and disable building
libpq++ if not. (We shouldn't simply kill libpq++ if the "include
<string>" test fails, since older C++ installations may have class
string in <string.h>. But if we can't find a header that defines class
string at all, then libpq++ is definitely going to fall over.)

As a short term solution, why not, it's already bad enough. But for the
future I'd like to suggest the adoption of a different principle: It's not
acceptable for parts of the tree to not be built based on the results of
configure tests. There are several reasons for that, the first and
foremost being that a configure script is not interactive. Users shouldn't
be required to monitor what flies by or, worse yet, deduce from cryptic
messages that stuff isn't going to be build at all. This is an incredible
can of worms for a package that interfaces to so many other software. For
the benefit of both users and maintainers, a configure run with the same
options must produce an installation that behaves the same on any
machine. I know this is slightly impractical in some cases, but only in
some.

In this particular case what ought to happen is this: When the package is
being configured to build libpq++ (whether by default or explicitly) and
some necessary feature is missing then the build must fail hard. Silently
ignoring build errors as has been suggested is equally problematic because
users will not sit in front of their terminal for 20 minutes and scan the
make output. In practice it might be preferrable to not make the C++ build
default because it's really no more special than say the Perl or Tcl
interface and exposes people that don't really care/know about C++ to
gratuitous problems. Also, the current configure run will fail if you
don't have a C++ compiler at all.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

Peter Eisentraut <peter_e@gmx.net> writes:

As a short term solution, why not, it's already bad enough. But for the
future I'd like to suggest the adoption of a different principle: It's not
acceptable for parts of the tree to not be built based on the results of
configure tests. There are several reasons for that, the first and
foremost being that a configure script is not interactive. Users shouldn't
be required to monitor what flies by or, worse yet, deduce from cryptic
messages that stuff isn't going to be build at all.

It currently says:

***
Disabling build of libpq++ because we cannot find class string in the
system's C++ header files.
***

Too cryptic for you?

I have a different take on the matter: it's not acceptable for a default
build of Postgres to fail hard because the local system's C++ compiler
is broken, libstdc++ is missing or incomplete, etc. There are too many
machines that fit that description and too few people using libpq++ to
justify treating libpq++ as an essential component.

Perhaps we could agree on a compromise that libpq++ ought not be built
at all unless specifically requested by a configure switch (eg,
"--with-libpq++"). If the user actually asked for it, then failing hard
is reasonable behavior. It's too late to make such a change for 7.0,
I think, but we could do it for 7.1.

Silently ignoring build errors as has been suggested is equally
problematic because users will not sit in front of their terminal for
20 minutes and scan the make output.

Right, I don't like that idea either.

Also, the current configure run will fail if you
don't have a C++ compiler at all.

Fail completely? I haven't tried that lately, but from the Autoconf
docs I'd expect it to set CXX=gcc and then all the C++ feature tests
would fail because gcc isn't there (or doesn't grok C++) --- which as
things currently stand would end in our deciding not to build libpq++.
Seems fairly reasonable. If configure actually falls over in that case
then we've blown it...

regards, tom lane

It would probably be a good idea to add another configure test to see
whether class "string" is actually available, and disable building
libpq++ if not. (We shouldn't simply kill libpq++ if the "include
<string>" test fails, since older C++ installations may have class
string in <string.h>. But if we can't find a header that defines class
string at all, then libpq++ is definitely going to fall over.)

Any objections if I sneak in such a configure test? Should be a
low-risk change.

regards, tom lane

I would like to see one other user with the problem first.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

It would probably be a good idea to add another configure test to see
whether class "string" is actually available, and disable building
libpq++ if not.

I would like to see one other user with the problem first.

Frank's problem was that he had only installed the runtime RPM for
libstdc++, not the devel RPM. Do you think he's the only such user?
(Especially considering that he said he was running a stock Mandrake
distro...)

Anyway, the fix is already committed, and it's the least of the
damage I've done today. Amazing how permissive Marc gets when a bug
is biting him personally ;-). Do you want to argue for putting off
the release date so we can get more testing on these fixes?

regards, tom lane

On Fri, 5 May 2000, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

It would probably be a good idea to add another configure test to see
whether class "string" is actually available, and disable building
libpq++ if not.

I would like to see one other user with the problem first.

Frank's problem was that he had only installed the runtime RPM for
libstdc++, not the devel RPM. Do you think he's the only such user?
(Especially considering that he said he was running a stock Mandrake
distro...)

Anyway, the fix is already committed, and it's the least of the
damage I've done today. Amazing how permissive Marc gets when a bug
is biting him personally ;-). Do you want to argue for putting off
the release date so we can get more testing on these fixes?

I swear, no matter what software I use, if there is a bug that can be
tweaked or triggered, I'll find a way to do it *sigh*

Bruce Momjian <pgman@candle.pha.pa.us> writes:

It would probably be a good idea to add another configure test to see
whether class "string" is actually available, and disable building
libpq++ if not.

I would like to see one other user with the problem first.

Frank's problem was that he had only installed the runtime RPM for
libstdc++, not the devel RPM. Do you think he's the only such user?
(Especially considering that he said he was running a stock Mandrake
distro...)

Anyway, the fix is already committed, and it's the least of the
damage I've done today. Amazing how permissive Marc gets when a bug
is biting him personally ;-). Do you want to argue for putting off
the release date so we can get more testing on these fixes?

I say shoot it out the door. It is not like 7.0.0 is going to be
perfect and we aren't going to need a 7.0.1.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Anyway, the fix is already committed, and it's the least of the
damage I've done today. Amazing how permissive Marc gets when a bug
is biting him personally ;-). Do you want to argue for putting off
the release date so we can get more testing on these fixes?

I say shoot it out the door. It is not like 7.0.0 is going to be
perfect and we aren't going to need a 7.0.1.

There is that. There will *always* be one more bug ;-). Unless we
see another showstopper-class bug report between now and Monday,
I'd be happy with release on Monday.

regards, tom lane

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:

Also, the current configure run will fail if you
don't have a C++ compiler at all.

Fail completely?

I'm not going to try to prove this now by uninstalling all my compilers
but this is a known deficiency in autoconf.

Well, what it appears to be is autoconf espousing the same "fail hard"
philosophy that you were just claiming was a good thing ;-). If you ask
it for AC_PROG_CXX and it can't find any working C++ compiler, it gives
up. I have just checked the behavior with no C++ compiler nor gcc in
the PATH, and our configure script will complete if you specify
--without-CXX, but not otherwise.

Definitely seems like a good idea to change to a default of --without-CXX
for 7.1. Is there anyone out there who wants to argue against it?

regards, tom lane