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