Thread: 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 `::'
...........
Need any more details ?
TIA, Frank.
> 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,
Pennsylvania19026
> > 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, Pennsylvania19026
> 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, Pennsylvania19026
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, Pennsylvania19026
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