g++3.0libraries

Our system manager, who is not an expert in c++,
has just installed g++3.0 at my request on an IBM workstation. It doesn't work.

I construct the file test.C which contains the single line
#include<iostream>

and try to compile it using
g++ -c test.C

It produces a large error file which begins with the series

In file included from /rccp/AIX/include/g++-v3/bits/std_iosfwd.h:40,
                 from /rccp/AIX/include/g++-v3/bits/std_ios.h:39,
                 from /rccp/AIX/include/g++-v3/bits/std_ostream.h:39,
                 from /rccp/AIX/include/g++-v3/bits/std_iostream.h:40,
                 from /rccp/AIX/include/g++-v3/iostream:31,
                 from test.C:1:
/rccp/AIX/include/g++-v3/bits/stringfwd.h:44: template with C linkage
/rccp/AIX/include/g++-v3/bits/stringfwd.h:52: template with C linkage
/rccp/AIX/include/g++-v3/bits/stringfwd.h:56: template with C linkage

and carries on in much the same way.

My include path is set to the new includes directory

echo $CPLUS_INCLUDE_PATH
/rccp/AIX/include/g++-v3/

What is the problem, and how can it be fixed?
LVL 1
glebspyAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
AxterConnect With a Mentor Commented:
glebspy,
To fix your problem try the following:

Go to the command line and type "which g++"
That should return something like the following:
/home/gcc/bin/g++

Then using the above return path value modify the path by entering the following command line:
set path = ( /home/gcc/bin $path )

Then change the current directory to the directory that contains your test.c file.
Enter the following:
g++ test.c


That should compile your code.
0
 
makerpCommented:
perhaps you need to give the file the ext .cpp so its compiled as C++ not C

also try giving it a main otherwise the linker wont find an entry point


0
 
makerpCommented:
i would do

#include <stdio.h>

void main()
{
printf("HELLO WORLD\n");
}

that should compile uner C and C++
0
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

 
glebspyAuthor Commented:
Sorry, makerp, I didn't make myself clear. Thanks for trying anyway.

1) .C is a valid extension exclusively for a c++ programme. It's just as good as .cpp . I tried it with .cpp and it's exactly the same.

2) It's true that for a full compilation I need an entry point but compiling with the -c option produces what we call an `object' file - a file which could for instance contain just a class or a function definition and does not need an entry point. It has to be linked later against an object file containing a main.

3) I need to use c++, and the many std classes. stdio.h is no good to me.
0
 
garbouaCommented:
Yes the GCC compilers will recognize .c .C .CC .cpp .i .s .o etc etc, and I do believe your problem is installation as you suspected.

first I though you included /usr/include/g++-3.0 in your makefile, but since you don't have a makefile you must have, your sysadmin, added include path manually.    a "make install" on source code will automatically take care of that.
0
 
glebspyAuthor Commented:
Dear garboua,
 You're right, I'm not using make for this. Like I said, I've set the environment variable CPLUS_INCLUDE_PATH to contain the include path from the new install (and only that path). I did this myself, the sysadmin didn't do it.
0
 
garbouaCommented:
I think that is your problem  because gnu installation already add the path to your system.  un-do-it , and it should work, "i'm hoping?" :-)
0
 
AxterCommented:
>>1) .C is a valid extension exclusively for a c++
>>programme. It's just as good as .cpp . I tried it with
>>.cpp and it's exactly the same.

This is not true.  In many compilers, includeing the GNU compiler, code that is compiled in a *.C file, is by default compiled as C code.
Code that is compiled in a C++ file, is by default compiled as C++ code.

You should always use *.cpp files for your C++ code.

Before continuing to trouble shoot your problem, you sould first change the file name to *.cpp extension.
This may not fix the problem, but if you don't fix this, you will not be able to tell when you actually do get your problem fix, because it still will not compile correctly.

Please post the complete code that you're trying to compile.
0
 
AxterCommented:
Correction:
Code that is compiled in a *.cpp file, is by default compiled as C++ code.
0
 
glebspyAuthor Commented:
Dear Axter,
 Of course you are a very great expert, much greater than  me, and I'm flattered that you looked at my question. So please tell me why you believe what you said about the .C file extension interpreted as interpreted by gcc as a plain c programme, and I will change my practices, and pass on to the gcc group that there is misinformation in their man pages.


According to man gcc, the gcc (current release 3.0) interpretation of file extensions is as follows. Please pay careful attention to the the fact that my .C extension is a *capital* C.

.cc
.C
.cxx
.cpp
   C++ source (passed through cpp).
.c
   C source that must be passed through cpp first.
.i
   Raw C source (no cpp pass).
.ii
   Raw C++ source (not to be preprocessed).
.m
   Objective-C source.
.S
   Assembler that must be passed through cpp first.
.s
   Raw assembler source (no cpp pass).

Any other file is passed to the linker, under the assumption that it's an object file.

Dear all,

Here is a simplification of the problem using a complete c++ source, with a main:

#include<iostream>
#include<string>

int main(void)
{
  string z="sdfhsjhfe";
  cout<<z<<endl;
}


when I pass this to gcc using the command line

g++ test2.C

the linker returns the following errors:
ld: 0711-317 ERROR: Undefined symbol: std::string::_Rep::_S_max_size
ld: 0711-317 ERROR: Undefined symbol: std::string::_Rep::_S_terminal
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status

Any ideas..

0
 
garbouaCommented:
Axter,
I don't know what gnu compiler You are using, or got your information from.  I don't have 3.0 installed yet because of the it is not compatible with RH7.x binaries, but I KNOW that  ".C" ext will invoke g++.  I migrated applications from Unix to linux servers and kept the old ".C" ext and guess what?  IT invokes the g++.
you can test it on any  gnu compiler.
qlebspy,
I am as confOsed as confused can be.  
0
 
AxterCommented:
Well, after doing some test on our GNU compiler, it seems I got egg on my face.

We use template makefile for compiling our programs.  The makefile has script in it, to make *.c files compile in C, and make *.cpp files compile in C++.

So the bottom line, is that you're right about the GNU compiler.

However, there are other compilers that do compile *.C files in C and *.cpp files in C++.

Also if someone is trying to use your code, and they have a makefile similar to the one my company uses, they'll also have a problem compiling the code.

It is common practice to put C code in *.C files, and to put C++ code in *.cpp files.
Since there's no real good reason not to use the common practice, I highly recommend that you use *.cpp files for your C++ code.
0
 
garbouaCommented:
well actually, old code developed on Unix machine had ".c" for the C source files and ".C" for the C++ files.  I am not going to critis your makefile, but as your said, you should make all your code protable, include makefiles.
0
 
AxterCommented:
>>I am not going to critis your makefile
This is not my makefile.  It's the one used by the company I work for.

The reason they use this method, is because all of their old C code is written in *.c files.

By using this method, they don't have to modify the *.c file when they're taking a file from a C compiled project and putting it into a C++ project.
Otherwise, some of their files would have to be modified to get them to work in a C++ project.

This is common practice, and that's why many compilers compile *.c files to C.
0
 
AxterCommented:
FYI,
To fix this problem permenantly, modify your .cshrc file and add the "set path = ( /home/gcc/bin $path )" to it.
0
 
glebspyAuthor Commented:
Dear all,
 Thanks for your help so far.

 I have decided to move this question to the Unix Programming environment, and to increase the points. I have done some research into the problem and found that it is a known problem on my system (related to the linker), so it remains to find a workaround. It is not advertised in gcc's bug list, so I believe there must be a workaround.

 Thanks to Axter for telling us about a different widely used convention for file extensions.

http://www.experts-exchange.com/jsp/qManageQuestion.jsp?ta=unixprog&qid=20161637
0
 
AxterCommented:
glebspy,
Did you try the instructions I posted in my previous comment?

That should have fix the problem.
0
 
glebspyAuthor Commented:
Dear Axter,
 yes
0
 
glebspyAuthor Commented:
I'm sorry I didn't accept this earlier - the fact is that there *was* a problem with conflicting include paths, in addition to the linker problem which is posted on the referenced question in Unix programming. Thanks Axter.
Thanks garboua for contributing.

Please help me with the linker question if you can, it's worth a lot of points, and it's important to my work.

0
 
AxterCommented:
>>Please help me with the linker question if you can, it's
>>worth a lot of points, and it's important to
>>my work.
Where do you have the link question posted?
Can you please post a link to your other question here?

0
 
glebspyAuthor Commented:
Axter,

 It's already on this thread, 5 or 6 comments up.

 Here it is again though:

http://www.experts-exchange.com/jsp/qManageQuestion.jsp?ta=unixprog&qid=20161637 
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.