Re: GDB compile problem.

Re: GDB compile problem.

[Michael Elizabeth Chastain]

chastain> After a couple of rounds of e-mail, we figured out the problem:
chastain> on Alex Turner's system, there's an environment variable "CPP=g++".

eliz> Shouldn't that be "CXX=g++"?

Sorry, my grammar is contorted.

Alex's environment had a variable with the name "CPP" set to the value
"g++".  This variable was there for some other purpose.  The configure
scripts in gdb 5.0 picked up this variable and tried to use it as the name
of the C Preprocessor.  The problem manifested as unresolved externals
at the time of the final link.  This was not obvious to diagnose.

So yes, it would be good for us if whatever *other* software that someone
has on their system would use CXX and not CPP as an environment
variable.

But it would be good if *our* software gave a useful error message:
"you have something named CPP in your environment, but it does not
perform the task of a C Preprocessor."

(And I know when I see comments: 'work around blah bug on Stardent ...'
that it's an extremely delicate piece of software to touch).

Michael

Re: GDB compile problem.

[Eli Zaretskii]

On Mon, 26 Feb 2001, Michael Elizabeth Chastain wrote:

> chastain> After a couple of rounds of e-mail, we figured out the problem:
> chastain> on Alex Turner's system, there's an environment variable "CPP=g++".
> 
> eliz> Shouldn't that be "CXX=g++"?
> 
> Sorry, my grammar is contorted.

No, it wasn't: I understood exactly what you meant.  Perhaps my own 
wording was unclear, in which case it's my turn to apologize.

> So yes, it would be good for us if whatever *other* software that someone
> has on their system would use CXX and not CPP as an environment
> variable.
> 
> But it would be good if *our* software gave a useful error message:
> "you have something named CPP in your environment, but it does not
> perform the task of a C Preprocessor."

There's no end to this.  What if someone sets "CC=/not/a/compiler/at/all",
or "LN_S=/anything/but/ln"?  If that happens, the configury stuff will 
begin falling apart all over the place, with all kinds of weirdo error 
messages.  I think a line should be drawn somewhere, and using 
well-established variable names for incompatible purposes is IMHO beyond 
that line.

Moreover, these variables are there _precisely_ so the end-user could set 
them to whatever she pleases without being subject to Autoconf's 
scrutiny, for those cases where Autoconf isn't smart enough.  If you now 
let Autoconf have its own ideas about the values of these variables, you 
might as well screw somebody else.

PS. How do you even check that the preprocessor ``works''?

Re: GDB compile problem.

[Eli Zaretskii]

> Date: Mon, 26 Feb 2001 10:47:23 -0800
> Cc: gdb@sourceware.cygnus.com
> 
> > PS. How do you even check that the preprocessor ``works''?
> 
> That part is easy.  You preprocess this file:
> 
>   int i;
> 
> ... and check that the output contains the line "int i"

Then CPP="sed ''" will pass your test ;-)

> I would definitely draw the line so that "CPP" is inside it.  "CPP" really
> is an ambiguous word and prone to misunderstanding; in my opinion, CC and
> LN_S aren't.  Even the Gnu Compiler Collection acknowledges "FILE.cpp"
> as an extension for C++ source code.
> 
> > Moreover, these variables are there _precisely_ so the end-user could set 
> > them to whatever she pleases without being subject to Autoconf's 
> > scrutiny, for those cases where Autoconf isn't smart enough.
> 
> I definitely accept this point.
> 
>   User: my $FOO is named "bar" ...
>   Software: your $FOO does not fit my pre-conceptions ...
> 
> That would not be very Unix-like.

Yes.

The question is, how to check the value of $CPP so that the test won't
be too viral...

Re: GDB compile problem.

[Michael Elizabeth Chastain]

Hi Eli,

> PS. How do you even check that the preprocessor ``works''?

That part is easy.  You preprocess this file:

  int i;

... and check that the output contains the line "int i"

> There's no end to this.  What if someone sets "CC=/not/a/compiler/at/all",
> or "LN_S=/anything/but/ln"?  If that happens, the configury stuff will 
> begin falling apart all over the place, with all kinds of weirdo error 
> messages.

"Weirdo error messages" are not a problem.  They may not be obvious to
the user, but they will be more obvious to the support people monitoring
the newsgroups.  The problem is when the configury stuff runs without
no errors but produces useless config.h files.

I would definitely draw the line so that "CPP" is inside it.  "CPP" really
is an ambiguous word and prone to misunderstanding; in my opinion, CC and
LN_S aren't.  Even the Gnu Compiler Collection acknowledges "FILE.cpp"
as an extension for C++ source code.

> Moreover, these variables are there _precisely_ so the end-user could set 
> them to whatever she pleases without being subject to Autoconf's 
> scrutiny, for those cases where Autoconf isn't smart enough.

I definitely accept this point.

  User: my $FOO is named "bar" ...
  Software: your $FOO does not fit my pre-conceptions ...

That would not be very Unix-like.

Michael

Re: GDB compile problem.

[Trond Eivind Glomsrød]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 202 bytes --]

Alex Turner <musicmaker@newfutureweb.com> writes:

> Well that depends - which system are you talking about? 

RHL 7 - there is a compiler update available.

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

Re: GDB compile problem.

[Michael Elizabeth Chastain]

After a couple of rounds of e-mail, we figured out the problem:
on Alex Turner's system, there's an environment variable "CPP=g++".
The configure script uses "CPP" to run the preprocessor, which causes
a bunch of configury stuff to fail.

Note that "CPP=g++ -E" would probably work, but "g++" with no further
flags doesn't behave much like old school /lib/cpp.

The name "CPP" is fundamentally ambiguous.  Perhaps configure files
could test out the preprocessor (especially if it is user-specified)
and give a more clear error up front.  I'll sleep on it and then maybe
file an enhancement request for autoconf.

Michael

Re: GDB compile problem.

[Alex Turner]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]

Well that depends - which system are you talking about? The RH6.2 is
updated to glibc-2.1.3 et al, however the RH7 one is not yet patched, as I
only just installed it in order to test this on, and the updates had not
yet finished downloading.  I have now had the chance to try it on another
system (poor computer - it seems to be my beast of burden), an older
RedHat 6.1 box, that is totaly unpatched, as it has always worked
perfectly from the day I installed it, and now is running half the
services for my web hosting stuff, however it is slower than molasses :(.
Michael has been helping me figure out this little problem, but I thank
you for you assistance also.

Alex

On 26 Feb 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:

> Alex Turner <musicmaker@newfutureweb.com> writes:
> 
> > I'm writing a multithreaded MUD thing (It's a bit more than just a MUD),
> > and I'm having some thread problems, so I decided to upgrade to gdb 5.0.
> > Only thing is, it doesnt appear that there are binaries readily available
> > for RedHat 6.2 (I really didnt like the look of RH7).  I tried building
> > the MUD on RH7, but there seems to be a problem with the C++ library, and
> > I get thread lock whenever I call cout.  
> 
> You have applied the updates, of course?
> 
> -- 
> Trond Eivind Glomsrød
> Red Hat, Inc.
> 

Re: GDB compile problem.

[Trond Eivind Glomsrød]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

Alex Turner <musicmaker@newfutureweb.com> writes:

> I'm writing a multithreaded MUD thing (It's a bit more than just a MUD),
> and I'm having some thread problems, so I decided to upgrade to gdb 5.0.
> Only thing is, it doesnt appear that there are binaries readily available
> for RedHat 6.2 (I really didnt like the look of RH7).  I tried building
> the MUD on RH7, but there seems to be a problem with the C++ library, and
> I get thread lock whenever I call cout.  

You have applied the updates, of course?

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

Re: GDB compile problem.

[Michael Elizabeth Chastain]

I just tried this, gdb 5.0 on a Red Hat 6.2 system, and the build
works for me.  So it's probably a package issue.

You need RPM glibc-devel installed, and maybe some others.
(glibc-devel is not for people who are working on glibc: it's for
anybody developing programs that *use* glibc, which is just about
every C program).

If you already have glibc-devel installed, can you send me these files
from your tree:

  config.cache
  config.status
  libiberty/config.h
  gdb/config.h

Furey
Merc Industries

GDB compile problem.

[Alex Turner]

I'm writing a multithreaded MUD thing (It's a bit more than just a MUD),
and I'm having some thread problems, so I decided to upgrade to gdb 5.0.
Only thing is, it doesnt appear that there are binaries readily available
for RedHat 6.2 (I really didnt like the look of RH7).  I tried building
the MUD on RH7, but there seems to be a problem with the C++ library, and
I get thread lock whenever I call cout.  So I tried compiling gdb5.0 on
RH6.2, and get the following error:

gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I./../include  -W -Wall -Wtraditional
getpwd.c
getpwd.c: In function `getpwd':
getpwd.c:62: storage size of `dotstat' isn't known
getpwd.c:62: storage size of `pwdstat' isn't known
getpwd.c:66: warning: implicit declaration of function `getenv'
getpwd.c:66: warning: assignment makes pointer from integer without a cast
getpwd.c:68: warning: implicit declaration of function `stat'
getpwd.c:74: warning: implicit declaration of function `getcwd'
getpwd.c:77: warning: implicit declaration of function `free'
getpwd.c:62: warning: unused variable `pwdstat'
getpwd.c:62: warning: unused variable `dotstat'
make[1]: *** [getpwd.o] Error 1
make[1]: Leaving directory `/usr/local/src/gdb-5.0/libiberty'
make: *** [all-libiberty] Error 2

Am I missing some libraries or do I have a bad compiler?  What can I do to
fix this problem?

I just did a standard
./configure --prefix=/usr/local/gdb
make

Are there some options that I need here?


Alex T.