2 Replies Latest reply on Jan 24, 2013 9:23 AM by Eman

    Kernel build: CodeBench Lite (Win32) + Cygwin Fails

    Eman

      Dear Sirs,

       

      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

       

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

      d:/zarm/csbench/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/include

       

      $ arm-none-linux-gnueabi-gcc.exe -print-sysroot

      d:\zarm\csbench\bin\../arm-none-linux-gnueabi/libc

       

      $ arm-none-linux-gnueabi-gcc.exe --sysroot=/cygdrive/d/zarm/ -print-sysroot

      /cygdrive/d/zarm/

       

      $ 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

      ...

      .LASF49:

              .ascii  "D:\\zarm\\kernel\\linux\\linux-2.6.35.x\000"

      ============================================================

       

      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!

       

      Best regards,

       

      Eman

        • 1. Re: Kernel build: CodeBench Lite (Win32) + Cygwin Fails
          brad_dixon

          Eman:

           

          You've picked a hard path to follow here. Not many people attempt to build the Linux kernel from a Windows host. We certainly don't attempt to in our QA processes for either CB Lite or our commercial products. People are usually, and rightfully, dissuaded from this path when they consider that even if the Linux kernel is successfully built that creating a complete userspace cross built from a Windows host will require the invocation of hundreds of support utilities which might not be available on Windows and may not faithfully replicate the expected behaviors that they would exhibit under Linux.

           

          We don't spend time testing this particular usage of CB because the path is rarely taken and, as you put it, "agony".

           

          You might wonder why we have Linux platform toolchains that operate on a Windows host at all since they aren't advised for building the Linux kernel or Linux a typical Linux userspace. We most often see customers utilizing this product configuration for building their own userspace applications where they control the build process directly. We have many customers who use CodeBench on Windows to do Linux application work.

           

          As to the specifics of your post:

           

          1) I've asked an engineer to look at the two path related issues you pointed to.

           

          2) If you don't intend to run the code then you won't have a target at all and therefore you have no need to copy the sysroot anywhere at all. You should be fine on this.

           

          3) You asked about using a sysroot from another location. If you aren't using a target to run the code why would you need a sysroot at all?

           

          I'll come back with more as I have something to share.

           

          Thanks, Brad

          • 2. Re: Kernel build: CodeBench Lite (Win32) + Cygwin Fails
            Eman

            My questions (4 & 5 ´) are two different questions. I have a sysroot from an old (gcc 4.4) CodeSourcery based compiler. If I could use those files, or will they collide with later GCC?

             

            I got everything in kernel to build, except:

            a) The binutils in "this" version of your CBL is broken with the bug I mentioned in the other post. (Giving the "Error: selected processor does not support ARM mode")

            b) GCC with versions >4.6 doesn't allow for "inlining" and throws errors, where older compilers ignores it. Not sure if there is a patch you've missed or something else?

            c) giving command line option "-march=armv7-a" gets overidden by generated assembly with "-march=armv5te". Why is this?