> -----Original Message----- > From: Jordan Justen [mailto:[email protected]] > Sent: 18 March 2014 22:02 > To: Olivier Martin > Cc: [email protected] > Subject: Re: [edk2-buildtools] [PATCH] BaseTools: Added support to use > GCC on Windows host (WINGCC) > > On Tue, Mar 18, 2014 at 10:12 AM, Olivier Martin > <[email protected]> wrote: > > > > > >> -----Original Message----- > >> From: Jordan Justen [mailto:[email protected]] > >> Sent: 13 March 2014 16:53 > >> To: Olivier Martin > >> Cc: [email protected] > >> Subject: Re: [edk2-buildtools] [PATCH] BaseTools: Added support to > use > >> GCC on Windows host (WINGCC) > >> > >> On Mon, Mar 10, 2014 at 12:04 PM, Olivier Martin > >> <[email protected]> wrote: > >> > This new toolchain wants to be architecture independent. > >> > >> Do you mean that you want GCC44 - GCC48 will adopt the same build > rule > >> family? > > > > No, I would like WINGCC to be as close as GCC4x toolchains. But I do > not > > want to change GCC4x toolchains. > > > >> > And I would like to > >> > deprecate ARMGCC and ARMLINUXGCC to only support the GCCxx > >> toolchains. > >> > >> It looks like after this change you will have 3 different build rule > >> families all using the same build rule templates. WINGCC, ARMGCC and > >> ARMLINUXGCC. > >> > >> This build rule family does not appear to be very 'windows' > specific, > >> so why have the name of WINGCC? > >> > > > > Again, I would like to deprecate/remove ARMGCC and ARMLINUXGCC. And I > also > > want to be able to build EDK2 with GCC on Windows host platform. > > Some of the GCC4x rules does not seem to work fine on Windows. I have > not > > personally tried to understand why they were not working. > > > > > > Ok... I have just tried to see what I would need to build EDK2 with > GCC48 on > > Windows (with GNU make). > > > > # The toolchain I am using: > > https://launchpad.net/linaro-toolchain- > binaries/trunk/2013.10/+download/gcc- > > linaro-aarch64-none-elf-4.8-2013.10_win32.zip > > > > # Here are the build instructions: > > set > > GCC48_AARCH64_PREFIX=C:\Toolchains\gcc-linaro-aarch64-none-elf-4.8- > 2013.10_w > > in32\bin\aarch64-none-elf- > > edksetup.bat > > build -a AARCH64 -p ArmPkg\ArmPkg.dsc -t GCC48 > > > > # Errors: > > 1) '"echo"' is not recognized as an internal or external command, > operable > > program or batch file. > > ==> Solution: I removed $(SYMRENAME) (I tried to replace echo by '#' > and > > '@rem' but did not work) > > If I remember correctly, I added SYMRENAME when working on GCC IPF > support. (Although SYMRENAME appears in a single patch bomb in > BaseTools r1554.) > > Unfortunately, I never got GCC IPF functional, since I did not have > access to an IPF system. As far as I know, although some GCC > toolchains can successfully build IPF images, they are not functional > images. Based on this, it might be better to remove SYMRENAME > altogether, as it does not appear that this is going to be addressed.
That's good to know. > > 2) > > "C:\Toolchains\gcc-linaro-aarch64-none-elf-4.8- > 2013.10_win32\bin\aarch64-non > > e-elf-ar" -cr > > > h:\tianocore\Build\Arm\DEBUG_GCC48\AARCH64\ArmPkg\Library\ArmDmaLib\Arm > DmaLi > > b\OUTPUT\ArmDmaLib.lib > @h:\tianocore\Build\Arm\DEBUG_GCC48\AARCH64\ArmPkg > > \Library\ArmDmaLib\ArmDmaLib\OUTPUT\object_files.lst > > C:\Toolchains\gcc-linaro-aarch64-none-elf-4.8- > 2013.10_win32\bin\aarch64-none > > -elf > > -ar: > > > h:tianocoreBuildArmDEBUG_GCC48AARCH64ArmPkgLibraryArmDmaLibArmDmaLibOUT > PUTAr > > mDmaLib.obj: No such file or directory > > ==> Solution, I replaced @$(OBJECT_FILES_LIST) by $(OBJECT_FILES) in > > $(SLINK) > > I'm a bit confused about how you are running the build command. Are > you running build from under the windows "cmd" shell, but specifying > -t GCC48? (I see windows style paths, GCC48 uses gnu makefiles.) Yes, I was running the command from a Windows Shell (with GNU Make support from http://gnuwin32.sourceforge.net/packages/make.htm) Here the build steps I was using: 1. Open a Visual Studio Command Prompt 2. Go into your EDK2 working directory 3. edksetup.bat 4. set GCC48_ARM_PREFIX=$(WIN_ARM_GCC_ROOT)\bin\arm-linux-gnueabihf- 5. build -a ARM -p ArmPlatformPkg\ArmVExpressPkg\ArmVExpress-CTA15-A7.dsc -t GCC48 > Is the @ syntax unsupported on this "ar" binary? It looks like it is > supported, but ar is treating the \ character as an escape within the > @$(OBJECT_FILES_LIST) file. The toolchain guys told me it is a side effect of binutils. libiberty (part of binutils) explicitly deals with backslashes so it can do quoting, as arguments are split on whitespace otherwise. It's really a side effect of the fact that Windows uses backslash for path separation and UNIX traditionally uses backslash for escaping strings. > How about supporting windows GCC builds under cygwin or msys unix > shells? (I think this should make file paths be unix style.) Windows paths are not an issue into the makefile itself. It actually works pretty well. But the issue comes when there is Windows filename into `ar` and `ld` configuration file. I found building with Cygwin slow and unreliable (the EDK2 build system was hanging sometimes). ... Actually, I have just tried... And it fails on the first command: $ build -a ARM -p ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc -t GCC48 "/cygdrive/c/tmp/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_win32/bin/arm-li nux-gnueabihf-gcc" -mthumb -mcpu=cortex-a15 -I/cygdrive/c/tmp/uefi-2cc8b63/ArmPlatformPkg/ArmVExpressPkg/Include -I/cygdrive/c/tmp/uefi-2cc8b63/ArmPlatformPkg/ArmVExpressPkg/Include/Platfor m/CTA15-A7 -g -fshort-wchar -fno-stack-protector -fno-strict-aliasing -Wall -Werror -Wno-missing-braces -Wno-array-bounds -ffunction-sections -fdata-sections -c -include AutoGen.h -DSTRING_ARRAY_NAME=BaseMemoryLibStmStrings -g -Os -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-missing-braces -Wno-array-bounds -c -include AutoGen.h -mword-relocations -mlittle-endian -mabi=aapcs -mapcs -fno-short-enums -save-temps -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft -mno-unaligned-access -O0 -o /cygdrive/c/tmp/uefi-2cc8b63/Build/ArmVExpress-CTA15-A7/DEBUG_GCC48/ARM/ArmP kg/Library/BaseMemoryLibStm/BaseMemoryLibStm/OUTPUT/./ScanMem64Wrapper.obj -I/cygdrive/c/tmp/uefi-2cc8b63/ArmPkg/Library/BaseMemoryLibStm/Arm -I/cygdrive/c/tmp/uefi-2cc8b63/ArmPkg/Library/BaseMemoryLibStm -I/cygdrive/c/tmp/uefi-2cc8b63/Build/ArmVExpress-CTA15-A7/DEBUG_GCC48/ARM/Ar mPkg/Library/BaseMemoryLibStm/BaseMemoryLibStm/DEBUG -I/cygdrive/c/tmp/uefi-2cc8b63/MdePkg -I/cygdrive/c/tmp/uefi-2cc8b63/MdePkg/Include -I/cygdrive/c/tmp/uefi-2cc8b63/MdePkg/Include/Arm /cygdrive/c/tmp/uefi-2cc8b63/ArmPkg/Library/BaseMemoryLibStm/ScanMem64Wrappe r.c arm-linux-gnueabihf-gcc.exe: error: /cygdrive/c/tmp/uefi-2cc8b63/ArmPkg/Library/BaseMemoryLibStm/ScanMem64Wrappe r.c: No such file or directory arm-linux-gnueabihf-gcc.exe: fatal error: no input files compilation terminated. make: *** [/cygdrive/c/tmp/uefi-2cc8b63/Build/ArmVExpress-CTA15-A7/DEBUG_GCC48/ARM/Arm Pkg/Library/BaseMemoryLibStm/BaseMemoryLibStm/OUTPUT/ScanMem64Wrapper.obj] Error 1 $ ls /cygdrive/c/tmp/uefi-2cc8b63/ArmPkg/Library/BaseMemoryLibStm/ScanMem64Wrappe r.c /cygdrive/c/tmp/uefi-2cc8b63/ArmPkg/Library/BaseMemoryLibStm/ScanMem64Wrappe r.c We would still need a 'special' toolchain to support Cygwin. > > 3) > > "C:\Toolchains\gcc-linaro-aarch64-none-elf-4.8- > 2013.10_win32\bin\aarch64-non > > e-elf-ld" -o > > > h:\tianocore\Build\Arm\DEBUG_GCC48\AARCH64\ArmPkg\Drivers\CpuDxe\CpuDxe > \DEBU > > G\ArmCpuDxe.dll -Ttext=0x0 --emit-relocs -nostdlib --gc-sections -u > _Module > > EntryPoint -e _ModuleEntryPoint -Map > > > h:\tianocore\Build\Arm\DEBUG_GCC48\AARCH64\ArmPkg\Drivers\CpuDxe\CpuDxe > \DEBU > > G/ArmCpuDxe.map --start-group > > > @h:\tianocore\Build\Arm\DEBUG_GCC48\AARCH64\ArmPkg\Drivers\CpuDxe\CpuDx > e\OUT > > PUT\static_library_files.lst --end-group > > C:\Toolchains\gcc-linaro-aarch64-none-elf-4.8- > 2013.10_win32\bin\aarch64-none > > -elf-ld: cannot find > > > h:tianocoreBuildArmDEBUG_GCC48AARCH64MdePkgLibraryBaseLibBaseLibOUTPUTB > aseLi > > b.lib: No such file or directory > > C:\Toolchains\gcc-linaro-aarch64-none-elf-4.8- > 2013.10_win32\bin\aarch64-none > > -elf-ld: cannot find > > > h:tianocoreBuildArmDEBUG_GCC48AARCH64MdePkgLibraryBasePcdLibNullBasePcd > LibNu > > llOUTPUTBasePcdLibNull.lib: No such file or directory > > (...) > > ==> Solution: I replaced @$(STATIC_LIBRARY_FILES_LIST) by > > $(STATIC_LIBRARY_FILES) > > Same situation as 2 above. > > > 4) "echo" objcopy not needed for > > > h:\tianocore\Build\Arm\DEBUG_GCC48\AARCH64\ArmPkg\Drivers\CpuDxe\CpuDxe > \DEBU > > G\ArmCpuDxe.dll'"echo"' is not recognized as an internal or external > > command, operable program or batch file. > > ==> Solution: I removed $(OBJCOPY) > > Which section of build_rule.txt? > > It sounds like a BaseTools 'true' command could be helpful. > For the sections [Static-Library-File] and [Dynamic-Library-File] Olivier ------------------------------------------------------------------------------ _______________________________________________ edk2-buildtools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel
