Re: Asking gcc for the include directory location?

[Kai Ruottu <karuottu at mbnet dot fi>]

Toralf Lund wrote:
> Dave Korn wrote:
> >   Sorry, I've been following this thread but I just don't follow :)  
> > Why are
> > we asking the preprocessor about include paths?  Only the compiler knows.
Maybe because it has always used them and has known them meanwhile the GCC
driver and the "real" compilers seemingly haven't...   A bare 'gcc' 
cannot  show
them neither the old  'cc1*'  in GCC versions as old as the gcc-2.95.

So after having only that 'arm-coff-gcc' but nothing else,  using it 
somehow to
"tell" the include paths may be vain... Neither taking only a 'cc1' and 
expecting it
to tell may be vain.

If one has all the GCC components available and they being installed 
properly,
then the 'gcc' can exec the possible 'cpp' and the 'cc1*' etc. and let 
them tell what
they know....

> Well I wanted to use gcc or possibly g++ myself, but then someone 
said that it
> couldn't be done, and I had to use cpp instead...

That someone seemed to me... And me being ignorant about the '-E -'  
use in this :-(

Never too old to learn more.  If only someone could tell how on earth 
all the vain
stuff in the output beginning could be stripped away. If I would like to 
see the header
search paths, everything else would then be vain.  So something like :

Dell:/data1/usr/local/lib/gcc-lib/sparc-solaris2.7/2.95.3-1 # ./cpp0 -v
GNU CPP version 2.95.3-1 20010315 (release) (sparc)
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/local/lib/gcc-lib/sparc-solaris2.7/2.95.3-1/include
/usr/local/sparc-solaris2.7/sys-include
/usr/local/sparc-solaris2.7/include
End of search list.
The following default directories have been omitted from the search path:
/usr/local/include/g++-3
End of omitted list.

should be what one gets with a simple and easily understood command.  If 
the 'cpp'
is expected to give this, it would be very simple to use 'gcc' the 
option to 'cpp', like :

Dell:~ # gcc-sparc-solaris2.9-3.2 -Wp,-v

telling "Give the '-v' option to the preprocessor so that it would show 
the include paths".
But it doesn't work and gives instead :

gcc-sparc-solaris2.9-3.2: no input files

Meanwhile the mystic '$target-cpp' works and gives the option to the 
"real" cpp, where
ever that  then is :

Dell:~ # cpp-sparc-solaris2.9-3.2 -Wp,-v
GNU CPP version 3.2.3 (cpplib) (sparc ELF)
ignoring nonexistent directory "NONE/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/local/lib/gcc-lib/sparc-solaris2.9/3.2.3/include
/usr/local/lib/gcc-lib/sparc-solaris2.9/../../../sparc-solaris2.9/sys-include
/usr/local/lib/gcc-lib/sparc-solaris2.9/../../../sparc-solaris2.9/include
End of search list.

So 'gcc' doesn't work but 'cpp' works !  The 'gcc -E -v -' command
gives here :

Dell:~ # gcc-sparc-solaris2.9-3.2 -E -v -
Reading specs from /usr/local/lib/gcc-lib/sparc-solaris2.9/3.2.3/specs
Thread model: posix
gcc version 3.2.3 (by karuottu@mbnet.fi)
/usr/local/lib/gcc-lib/sparc-solaris2.9/3.2.3/cpp0 -lang-c -v 
-D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=3 
-D__GXX_ABI_VERSION=102 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 
-D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ 
-D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix 
-Asystem=unix -Asystem=svr4 -D__NO_INLINE__ -D__STDC_HOSTED__=1 
-D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int 
-D__WCHAR_TYPE__=long int -D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ 
-Acpu=sparc -Amachine=sparc -

before telling what one really wanted to see!  The previous can be 
totally ok if
one wants to see also all the predefines, thread model, gcc version

Maybe this is that famous "smalltalk" we Finns don't use, anyone who 
makes a
phone call and then starts it with talking about the weather, how the 
family  is, any
diseases etc. etc., should be prepared to hear: "I have a little hurry 
now, lets chat
later and then the phone call will be shut.  To the real subject 
immediately without
any precautions if one has such....

The expected thing could be that the 'gcc -print-search-dirs' would 
show also what
the '-v' option given to the real 'cpp' gives, this has been quite 
"standard" this far :

Dell:/usr/local/lib/gcc-lib/ppc-suse-linux10.1/4.1.1 # ./cc1plus -v
ignoring nonexistent directory "NONE/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include/c++/4.1.1
/usr/local/include/c++/4.1.1/ppc-suse-linux10.1
/usr/local/include/c++/4.1.1/backward
/usr/local/lib/gcc-lib/ppc-suse-linux10.1/4.1.1/include
/usr/local/ppc-suse-linux10.1/sys-include
/usr/local/ppc-suse-linux10.1/include
End of search list.

But neither the 'cpp -print-search-dirs' gives what one expects, in this 
case something
like the previous....

BTW, the 'g++ -E -v'  DIDN'T WORK here, it didn't show the C++ search 
paths! Neither
its (just invented) variation :

Dell:~ # g++ -E -Wp,-v -
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/i586-suse-linux/4.1.0/include
/usr/lib/gcc/i586-suse-linux/4.1.0/../../../../i586-suse-linux/include
/usr/include
End of search list.

But if the '-v' is given directly to the "real cpp" in 'cc1plus' :

Dell:/usr/lib/gcc/i586-suse-linux/4.1.0 # ./cc1plus -v
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.1.0
/usr/include/c++/4.1.0/i586-suse-linux
/usr/include/c++/4.1.0/backward
/usr/local/include
/usr/lib/gcc/i586-suse-linux/4.1.0/include
/usr/lib/gcc/i586-suse-linux/4.1.0/../../../../i586-suse-linux/include
/usr/include
End of search list.

Then it works!   Dave, what is wrong with this '-E -' system?


--
For unsubscribe information see http://sourceware.org/lists.html#faq