FW: The word

["Dockeen" <dockeen at mchsi dot com>]

-----Original Message-----
From: Dockeen [mailto:dockeen@mchsi.com]
Sent: Sunday, February 24, 2002 6:29 PM
To: Dan Lange
Subject: The word


There is still no directory libstdc++-v3 going anywhere
in the Cygwin directory structure. It is there in my
downloaded directory. Hmmm, looks like something
may be going astray earlier...

Waynebozo

-----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