FW: Even More More data

[Dockeen]

-----Original Message-----
From: Dockeen [mailto:dockeen@mchsi.com]
Sent: Sunday, February 24, 2002 6:19 PM
To: Dan Lange
Subject: Even More More data


Thanks for your help! I deeply appreciate people taking their time with me.
I have scanned your email, thanks for the information about how to

One data point I just ran across was this.  Again, doing what I should
have done first, I did a windows search of libstdc++.  I did not find
one that got installed by 

make install

By the way, I was following the "recipe" from the earlier elements on
the post.  Yes, I enabled c,c++,f77.

Now, I did make install again, and noted that it ended right after
the fastjar error, so I am, as we speak, doing make install --ignore
to see if I get libstdc++ to be "installed".

Will let you know as soon as the bugger finishes.

Again, sincere thanks,

Wayne

-----Original Message-----
From: Dan Lange [mailto:lange92@2067.resnet.uni.edu]
Sent: Sunday, February 24, 2002 6:08 PM
To: Dockeen
Subject: Re: More data


Wayne--
  Since you're on Cygwin and not linux according to your previous posts,
some of this might be a little inaccurate, but most of it should still
apply. So there's my disclaimer.
  First off, your first message of the last 2 today have suggested you
were on the right track. Then you sent the second... So you need to know
something: when you build gcc, if you get binaries in /usr/local, then
everything will be under /usr/local/. That's a "prefix" in the top-level
Makefile, for computerspeak.

On Sun, 24 Feb 2002, Dockeen wrote:

> I meant /usr/include/g++-3

Right. This would have been from the native compiler. This would explain
why, as you so eloquently put it, the native one worked fine, but the
built one did not. (Oh, and don't let that "-3" fool you--my version of
gcc on this particular machine is still 2.95.2, but it too has
"/usr/include/g++-3/iostream.h".

> (1) It was in /usr/local/g++-3, which seems to indicate that
> at least some of the suffix command is working.

I would have expected /usr/local/include/g++-3/iostream.h.

Crazy question: when you built gcc, did you do `make LANGUAGES="c c++"` ?
Including "c++" is important. And did you do the 'make install'?



> (2) Now, I did the ultimate in cheating and gave the include
> statement the direct path to this version of iostream.h.  When
> I ran the /usr/local/bin (new) version of g++, it gave voluminous
> errors related to iostream.h.  When I compiled with straight
> g++ (old Cygwin version), it compiled OK.

Indeed. You pointed to headers for the NATIVE compiler.

Start by running:

  find /usr/local -name iostream.h

if that returns something, that's what you need. if it doesn't, you may
need to go back and re-run the make languages step mentioned earlier.


>I could get the "old" version to compile with
>
>#include<iostream.h>
>
>or
>#include<iostream>
>
>The new version would not compile with either, giving
>a "no such file or directory" error. I then tried a
>compile of a work tool, which has a large number of
>files to make.  It goes through the compile part of the make
>OK, but when it goes to link, it throws a lot of errors
>related to flavors of "new" and "delete". The make uses
>gcc by the way, though in the past I have tried g++
>as well.

Here you show that you really have a pretty firm grip on what's really
going on. In the compile phase, what matters is generating a "logical"
connection between symbols in the .h files and the functions in whatever
you're building and vice versa. However linking requires the actual
precompiled symbols for the functions--but you won't find iostream.o,
because it's hidden away in a file called "libstdc++.a". (On linux, in my
native compiler, this is at /usr/lib/gcc-lib/i386-linux/2.95.2; you'll
find your native lib stuff in some directory named something else, but it
shouldn't be too different.) You can verify what I just told you--find
your libstdc++.a, and run `ar t libstdc++.a` on it. you can look through
it and see it, or you can grep the output for iostream.o.

Now, you may want to fiddle with some of the environment variables
enumerated on
http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html

In particular, I believe "LIBRARY_PATH" might be one you'd want to change,
after you've located your built version of libstdc++.a under /usr/local.
You might also want to change CPLUS_INCLUDE_PATH as well. I missed the one
about you renaming the binaries to add "-3" to the end of their names--did
you do that? That might actually cause you more problems in the long run.
I wouldn't do it.

Another one--did you remember to put /usr/local/bin at the *front* of your
PATH environment variable? That is particularly important. That goes
double if you're cross-compiling; I forget if you are or not.

Just a few more pointers and a little theory...

HTH. HAND.

DanL