I have installed successfully your Sourcery CodeBench lite (2012.09.64) on a Windows Vista + Cygwin environment.
The environment is carefully setup in such a way that it is case sensitive and fullfills all other POSIX+ environment settings (as required for Linux builds).
This seem to work fine when compiling simple individual programs like HelloWorld.c etc. But when attempting to compile anything more advanced where linking of modules involves external libraries, like a Linux Kernel, I get many problems which I beleive is a result of a buggy implementation of handling Win32 paths versus POSIX paths. According to your documents, your cross compiler should be able to handle these paths if you set your environment variable "CYGPATH=cygpath". I have now tried several different forms of this variable, and results are always the same. Your tool(s) nearly always returns some windows paths at some point. If not immediately from compiler stage, it appears later in assembly or linking stage. It seem that your compiler is "leaking" these from other stages...
Here is some output:
$ echo $CYGPATH
$ $CYGPATH --version
cygpath (cygwin) 1.7.17
Path Conversion Utility
Copyright (C) 1998 - 2012 Red Hat, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ arm-none-linux-gnueabi-gcc.exe -print-file-name=include
$ arm-none-linux-gnueabi-gcc.exe -print-sysroot
$ arm-none-linux-gnueabi-gcc.exe --sysroot=/cygdrive/d/zarm/ -print-sysroot
$ arm-none-linux-gnueabi-gcc.exe --sysroot=/cygdrive/d/zarm/ -print-file-name=include
d:/zarm/csbench/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/include <=== NOT OK !!
As you can see, this would be a critical issue when you try to compile a Linux kernel which contain several Makefile's with statements like this:
"NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)"
In addition, when you check the resulting assembly (.S) files, you find "leakage", in particular from the variables: -iprefix and -isystem . For example in the generated ./kernel/bounds.s file in a standard Linux kernel (2.6.35), we find:
@ -iprefix d:\zarm\csbench\bin\../lib/gcc/arm-none-linux-gnueabi/4.7.2/ <=== Problem !!
@ -isysroot /cygdrive/d/zarm/csbench/arm-none-linux-gnueabi/libc
@ ... -iprefix ./ <=== OK !
@ -isystem /cygdrive/d/zarm/csbench/lib/gcc/arm-none-linux-gnueabi/4.7.2/include
@ -include include/generated/autoconf.h -MMD kernel/.bounds.s.d
This when compiled with Makefile:
AS = $(CROSS_COMPILE)as -iprefix ./
LD = $(CROSS_COMPILE)ld --sysroot=$(SYSROOT) -iprefix ./
CC = $(CROSS_COMPILE)gcc --sysroot=$(SYSROOT) -iprefix ./
#CPP = $(CC) -E
CPP = $(CROSS_COMPILE)cpp --sysroot=$(SYSROOT) -iprefix ./
AR = $(CROSS_COMPILE)ar
NM = $(CROSS_COMPILE)nm
In conclusion, it seem that CS bench is accepting POSIX paths as input, but not properly (and always) returning POSIX as output, when CYGPATH is defined, if ever! BUG??
So my question has multiplied to several:
1) How can I resolve this issue?
2) Is there any way to influence and remove that "second" -prefix in any way?
3) Why is CYGPATH not working as expected? (from your own documents?)
4) In your other document ("Getting Started") you also mention that $SYSROOT should be copied to target directory, is this a requirement? (Because I'm not actually running the execuatbles, just test compiling...so I'm just using default CS installation. Hope this is this ok?)
5) Is it possible to use a $SYSROOT location from a different CS toolchain? (I have an old one that perhaps match my board better.)
Any help or pointers you could provide, would help alleviate a great amount of cross-compilation aganoy!