This is the mail archive of the crossgcc@sourceware.cygnus.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more infromation.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Libiberty



After som dissecting of Makefiles and error logs, I have finally
discovered where GCC expects to find the target binutils [apart from
in PATH] and header files, namely as follows: (I know - I'm lame)

       prefix = /home/geirfrs/gcc-ppc-vxworks
       exec_prefix = $(prefix)
       build_tooldir = $(exec_prefix)/powerpc-wrs-vxworks
       r=`pwd`; export r; 

       GCC_FOR_TARGET = $$r/gcc/xgcc \
		      -B$$r/gcc/ \
		      -B$(build_tooldir)/bin/ \
		      -I$(build_tooldir)/include

GCC finally stopped complaining when I put the VxWorks header files in
the `/home/geirfrs/gcc-ppc-vxworks/powerpc-wrs-vxworks/' directory.
But apparently, GCC uses these headerfiles directly, whithout ever 
letting `fixproto' loose on them. Is this because the VxWorks system
description deems this unnessesary or am I doing something wrong here?

The above obvious takes care of the conflict between the native `as'
and the `/home/geirfrs/gcc-ppc-vxworks/powerpc-wrs-vxworks/bin/as' 
But still Make issues one or more references to the transformed name
version of the binutils, powerpc-wrs-vxworks-xxxx that is. These I
took care of by adding `/home/geirfrs/gcc-ppc-vxworks/bin' to PATH.
But still - this should not happen, should it?



Now for the real problem - libiberty. As far as I can determine,
libiberty contains fixes for host OS deficiancies. Therefore, it 
ougth to be compiled with the native compiler, rigth? 
Well, apparently not. This is the errorlog:

 make[2]: Entering directory
 `/gcc-install/gcc-obj/gcc-2.95.2-ppc/powerpc-wrs-vxworks/libiberty'
 test x"no" != xyes || \

 /gcc-install/gcc-obj/gcc-2.95.2-ppc/gcc/xgcc  <=== This correct?
  -B/gcc-install/gcc-obj/gcc-2.95.2-ppc/gcc/
  -B/home/geirfrs/gcc-ppc-vxworks/powerpc-wrs-vxworks/bin/ 
  -c -DHAVE_CONFIG_H -g -O2
  -I. -I/gcc-install/gcc-src/gcc-2.95.2/libiberty/../include
  /gcc-install/gcc-src/gcc-2.95.2/libiberty/choose-temp.c
  -o pic/choose-temp.o

 /.../gcc-src/gcc-2.95.2/libiberty/choose-temp.c:29: stdio.h:
 /.../gcc-src/gcc-2.95.2/libiberty/choose-temp.c:30: sys/types.h:
 /.../gcc-src/gcc-2.95.2/libiberty/choose-temp.c:32: unistd.h:
 /.../gcc-src/gcc-2.95.2/libiberty/choose-temp.c:35: stdlib.h:
 /.../gcc-src/gcc-2.95.2/libiberty/choose-temp.c:38: sys/file.h: 
 No such file or directory make[2]: *** [choose-temp.o]
 Error 1 make[2]: Leaving directory
 `/gcc-install/gcc-obj/gcc-2.95.2-ppc/powerpc-wrs-vxworks/libiberty'

I.e the `choose-temp.c' file includes the usual POSIX style include
files. Now, as a POSIX conforming RT-OS, VxWorks also comes with these
header files. But looking into the actual source of `choose-temp.c' 
I can not imagine why this file should ever need be crosscompiled.

One look into the `.../libiberty/Makefile' points out the most likely
candidate to the crosscompile construct above, namely the line:

	  INCDIR=$(srcdir)/$(MULTISRCTOP)../include

	  COMPILE.c = $(CC) -c -DHAVE_CONFIG_H $(LIBCFLAGS) \
		      -I. -I$(INCDIR) \
		      $(HDEFINES) 

I say most likely becuse even if I add the line
`-I/home/geirfrs/gcc-ppc-vxworks/powerpc-wrs-vxworks/include'
to the line obove, the log shows this search path is ignored.
I have not experimentet any more because I believe crosscompile
is wrong in the first place. Could someone help me out here?

--

  ******************************************************
  Never ever underestimate the power of human stupidity.
  -Robert Anson Heinlein

		GeirFRS@invalid.ed.ntnu.no
  ******************************************************


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]