On Sat, 23 Aug 2008, Dirk Behme wrote:
Woodruff, Richard wrote:
Hi Dirk,
Relevant parts of OMAP3 patch we talk about here (most probably reformated cause of copy & paste to mailtool, so just for discussion. Final patches will be sent by git-send-mail). Note the -lgcc_eh which seems to be CodeSourcery specific, and the -march=armv7a in config.mk.
diff -uprN uboot_clean/Makefile uboot_beagle/Makefile --- uboot_clean/Makefile 2008-08-22 19:57:05.000000000 +0200 +++ uboot_beagle/Makefile 2008-08-22 19:53:52.000000000 +0200 @@ -141,7 +141,7 @@ ifeq ($(ARCH),ppc) CROSS_COMPILE = ppc_8xx- endif ifeq ($(ARCH),arm) -CROSS_COMPILE = arm-linux- +CROSS_COMPILE = arm-none-linux-gnueabi-
CROSS_COMPILE can always be set as an environment variable. It is
only for convenience. CodeSourcy from my vantage point is common enough it would nice to see it the default. In the end it doesn't matter.
endif ifeq ($(ARCH),i386) CROSS_COMPILE = i386-linux- @@ -253,7 +253,7 @@ LIBBOARD = board/$(BOARDDIR)/lib$(BOARD) LIBBOARD := $(addprefix $(obj),$(LIBBOARD))
# Add GCC lib -PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc +PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc -lgcc_eh
What is being gained by changing platform libs part? Every now and
then I update my local omap3 u-boot and I've not had to change that to get it working with codesourcy tool chains. It might be I've not hit the issue yet.
Did check regarding -lgcc_eh: Used CodeSourcery tool chain and compiled (linked) with and without -lgcc_eh. The resulting binaries are identical and no link issues. Seems we can remove -lgcc_eh then. I just wonder now why it is there and what it is (was?) good for?
AFAIK, you can safely remove it. I don't know how CodeSourcery build their toolchains but when I do mine I remove it from glibc and then there is no libgcc_eh at all. The trick is glibc headers are required to build first stage cross-gcc and cross gcc is required to build glibc. And glibc in turn is required to build gcc :) It might be easier to do it with previous versions installed but I usually build toolchains as RPM packages assuming no previous toolchain is installed. And it is build in buildroot with all the system stuff going into sysroot.
The build process is multi-stage -- first just provisional glibc headers are built, then they are used to build limited first stage cross-gcc, then this gcc is used to build full-blown glibc that gets installed in sysroot overwriting those provisional headers, then this newly built glibc is used to build the full cross-gcc.
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************