Typo fix in toolchain/external-toolchain/ext-tool.mk

The mtd makefile fragment doesn't specify LDFLAGS. This can cause the linking to fail when trying to find libz if using an external toolchain

Quoted 3 lines

The mtd makefile fragment doesn't specify LDFLAGS. This can cause the linking to fail when trying to find libz if using an external toolchain

This is a problem I also face with many other packages (libpng, directfb, etc.). So I've proposed another, more radical patch:

http://buildroot.uclibc.org/lists/buildroot/2008-October/011017.html

Sadly, I didn't get any feedback about it.

Quoted 10 lines · Thomas Petazzoni

Quoted 3 lines

The mtd makefile fragment doesn't specify LDFLAGS. This can cause the linking to fail when trying to find libz if using an external toolchain

This is a problem I also face with many other packages (libpng, directfb, etc.). So I've proposed another, more radical patch:

http://buildroot.uclibc.org/lists/buildroot/2008-October/011017.html

Sadly, I didn't get any feedback about it.

Add usbutils to the list of packages with the same problem.

I figured I had something setup wrong with my external toolchain so I just patched the .mk files to make it work. Good to know I'm not the only one with problems.

Just did a quick glance at the patch above, I don't think it would work for the mtd package. The patch add TARGET_LDFLAGS to the TARGET_CONFIGURE_OPTS. The mtd package doesn't use Autotools so I don't think it will see the change.

It should work for usbutils. But I'm not sure if the "-Wl,--rpath-link -Wl,$(STAGING_DIR)/usr/lib" is also needed.

For reference here is what I patched to get mtd and usbutils to compile:

Just did a quick glance at the patch above, I don't think it would work for the mtd package. The patch add TARGET_LDFLAGS to the TARGET_CONFIGURE_OPTS. The mtd package doesn't use Autotools so I don't think it will see the change.

It should work for usbutils. But I'm not sure if the "-Wl,--rpath-link -Wl,$(STAGING_DIR)/usr/lib" is also needed.

TARGET_CONFIGURE_OPTS is supposed to be used in all packages when calling ./configure, as far as I understand (and it's the case in the packages I had a look at). TARGET_CONFIGURE_OPTS is of course also used by Makefile.autotools.in.

However, buildroot needs copy the correct version of the libraries to match the flags used to compile the applications.

From: Grant Likely <[email protected]>

Fix buildroot to work with external toolchains using multilib. Multilib toolchains have several sets of libraries which they can choose between depending on the optimization flags. For example, a single toolchain could have libraries compiled for both hard and soft floating point. However, buildroot needs copy the correct version of the libraries to match the flags used to compile the applications.

This patch adds the CPU optimization flags to the execution of GCC when determining the location of the libraries to copy. Passing the optimization flags makes the library linking and copying consistent.

Tested using CodeSourcery PowerPC toolchain on a Xilinx Virtex5 ppc440 platform.
---

 toolchain/external-toolchain/ext-tool.mk |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

(quoted diff) +0 -0

b/toolchain/external-toolchain/ext-tool.mk index bbf430c..ba10dc7 100644 --- a/toolchain/external-toolchain/ext-tool.mk +++ b/toolchain/external-toolchain/ext-tool.mk

(quoted diff) +2 -2

@@ -10,7 +10,8 @@ copy_toolchain_lib_root = \
 	DST="$(strip $2)"; \
 	STRIP="$(strip $3)"; \
  \
-	LIB_DIR=`$(TARGET_CC) -print-file-name=$${LIB} | sed -e
 "s,/$${LIB}\$$,,"`; \
+	LIB_DIR=`$(TARGET_CC) $(subst ",,$(BR2_TARGET_OPTIMIZATION))
-print-file-name=$${LIB} | sed -e "s,/$${LIB}\$$,,"`; \
+	MULTILIB=`$(TARGET_CC) $(subst
 ",,$(BR2_TARGET_OPTIMIZATION)) -print-multi-directory`; \ \
 	if test -z "$${LIB_DIR}"; then \
 		echo "copy_toolchain_lib_root: lib=$${LIB} not

found"; \ @@ -21,7 +22,7 @@ copy_toolchain_lib_root = \
for FILE in `find $${LIB_DIR} -maxdepth 1 -type l -name
"$${LIB}*"; do \ LIB=basename $${FILE}`; \

(quoted diff) +0 -1

 		while test \! -z "$${LIB}"; do \
-			echo "copy_toolchain_lib_root lib=$${LIB}

dst=$${DST}"; \

(quoted diff) +1 -0

+			echo "copy_toolchain_lib_root

multilib=$${MULTILIB} lib=$${LIB} dst=$${DST}"; \ rm -fr $(TARGET_DIR)$${DST}/$${LIB}; \ mkdir -p $(TARGET_DIR)$${DST}; \
if test -h $${LIB_DIR}/$${LIB}; then \

_______________________________________________
buildroot mailing list
buildroot at uclibc.org
http://busybox.net/mailman/listinfo/buildroot

Hi Grant,

I've recently tried to work again on integrating CodeSourcery toolchains into Buildroot, but I'm facing issues related to multilib. I've summed up these issues in the following post:

?http://lists.busybox.net/pipermail/buildroot/2010-January/031421.html

If you have any idea on how to solve the issues, don't hesitate to tell me.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Grant" == Grant Likely <[email protected]> writes:

Grant Likely, 16.10.2008:

target/linux/Makefile.in ifeq ($(BR2_PACKAGE_BUSYBOX_INITRAMFS),y) · line 206

Quoted 7 lines

target/linux/Makefile.in +2 -2

-     $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) modules
-     $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) \
+     $(LINUX26_MAKE) modules
+     $(LINUX26_MAKE) \
              DEPMOD=$(STAGING_DIR)/bin/$(GNU_TARGET_NAME)-depmod26 \
              INSTALL_MOD_PATH=$(TARGET_DIR) modules_install

DEPMOD could be defined in LINUX26_MAKE_FLAGS, INSTALL_MOD_PATH is already there. Then it would be a small line here.

Quoted 4 lines

target/linux/Makefile.in +0 -0

@@ -240,6 +242,9 @@ linux26-force:
 # This has been renamed so we do _NOT_ by default run this on 'make clean'
 linux26clean:
      rm -f $(LINUX26_KERNEL) $(LINUX26_DIR)/.configured

target/linux/Makefile.in linux26-force: · line 248

Quoted 4 lines

target/linux/Makefile.in +3 -0

+     # Note; this invocation of make is different from the rest.  Why
+     # does 'PATH' need to be assigned here?  Can this be replaced with
+     # $(LINUX26_MAKE) like all the others?
      -$(MAKE) PATH=$(TARGET_PATH) -C $(LINUX26_DIR) clean

I think so, maybe a leftover, but I don't know. Git-grepping for TARGET_PATH through the repository shows some uses of this in 4 devices but not restricted to the clean target.

From: Grant Likely <[email protected]>

Originally, $(LINUX26_VERSION) was used to figure out which directory modules would get installed in under /lib/modules. This causes problems when $(LINUX26_VERSION) differs from what version the kernel source thinks it is using because it will try to use depmod in the wrong directory.

This patch adds a new variable $(LINUX26_VERSION_MOD) which resolves to the exact version string that the kernel uses. Module install then uses this value instead of $(LINUX26_VERSION) when running depmod

This patch also eliminates the modules.dep target and makes .modules_installed depend on $(LINUX26_DIR)/.configured directly. This is necessary because the value of $(LINUX26_VERSION_MOD) is unavailable before the kernel is unpacked. Trying to use it in a target or dependency name confuses make.

Quoted 8 lines · On Thu, 16 Oct 2008 22:32:46 +0200 "Grant Likely" <[email protected]>…

From: Grant Likely <[email protected]>

Originally, $(LINUX26_VERSION) was used to figure out which directory modules would get installed in under /lib/modules. This causes problems when $(LINUX26_VERSION) differs from what version the kernel source thinks it is using because it will try to use depmod in the wrong directory.

I like this stuff, I'll give it a spin and see how it performs. If it works well I'll add it to the repo (unless somebody beat me to it).

Quoted 10 lines

This patch adds a new variable $(LINUX26_VERSION_MOD) which resolves to the exact version string that the kernel uses. Module install then uses this value instead of $(LINUX26_VERSION) when running depmod

This patch also eliminates the modules.dep target and makes .modules_installed depend on $(LINUX26_DIR)/.configured directly. This is necessary because the value of $(LINUX26_VERSION_MOD) is unavailable before the kernel is unpacked. Trying to use it in a target or dependency name confuses make.

And what about using the $(PROJECT_DIR)/autotools-stamp directory instead for the depend file? Follow with the stream, etc... Easier to know how to trigger a reinstall as well.

Originally, $(LINUX26_VERSION) was used to figure out which directory modules would get installed in under /lib/modules. This causes problems when $(LINUX26_VERSION) differs from what version the kernel source thinks it is using because it will try to use depmod in the wrong directory.

Le Thu, 16 Oct 2008 14:32:46 -0600,
Grant Likely <[email protected]> a ?crit :

Quoted 5 lines

Originally, $(LINUX26_VERSION) was used to figure out which directory modules would get installed in under /lib/modules. This causes problems when $(LINUX26_VERSION) differs from what version the kernel source thinks it is using because it will try to use depmod in the wrong directory.

Just for curiosity, in what cases $(LINUX26_VERSION) can differ from the ? version the kernel source thinks it is using ? ?

Otherwise, the version proposed by Hans-Christian Egtvedt looks good to me.

When using a git kernel tree for instance, LINUX26_VERSION is set to "linux-git" to match the directory that the kernel is unpacked into but the kernel source could be reporting just about any "linux-vX.Y.Z-<sha1>".

Le Thu, 16 Oct 2008 14:32:46 -0600,
Grant Likely <[email protected]> a ?crit :

Quoted 5 lines

Originally, $(LINUX26_VERSION) was used to figure out which directory modules would get installed in under /lib/modules. This causes problems when $(LINUX26_VERSION) differs from what version the kernel source thinks it is using because it will try to use depmod in the wrong directory.

Just for curiosity, in what cases $(LINUX26_VERSION) can differ from the ? version the kernel source thinks it is using ? ?

Le Thu, 16 Oct 2008 14:32:46 -0600,
Grant Likely <[email protected]> a ?crit :

Quoted 5 lines

Originally, $(LINUX26_VERSION) was used to figure out which directory modules would get installed in under /lib/modules. This causes problems when $(LINUX26_VERSION) differs from what version the kernel source thinks it is using because it will try to use depmod in the wrong directory.

Just for curiosity, in what cases $(LINUX26_VERSION) can differ from the ? version the kernel source thinks it is using ? ?

Otherwise, the version proposed by Hans-Christian Egtvedt looks good to me.

From: Grant Likely <[email protected]>

Setting HOSTCFLAGS when calling make for the kernel compile messes up the tools that the kernel builds for itself. Specifically, the building of the device tree compiler (dtc) in arch/powerpc adds some required flags to HOSTCFLAGS. However, if HOSTCFLAGS= is specified when calling make, then the local flags are never added and the kernel compile fails.

This patch removes the HOSTCFLAGS= from $(LINUX26_MAKE_FLAGS). I've marked this patch as an RFC because I don't know what is really required here. Removing it works for me (of course), but it may break other users. I just don't know if there is a better way to set HOSTCFLAGS so that it doesn't override the settings that the kernel uses itself.

---

target/linux/Makefile.in.advanced | 2 +-

1 files changed, 1 insertions(+), 1 deletions(-)

target/linux/Makefile.in.advanced +0 -0

index 42384f1..9c6df1f 100644
@@ -186,7 +186,7 @@ LINUX_KERNEL:=$(LINUX26_KERNEL)
 LINUX26_BZCAT:=$(BZCAT)
 

__LINUX26_NO_PIC=-fPIC -fpic -DPIC -fwrapv -ftrapv

target/linux/Makefile.in.advanced +1 -1

-LINUX26_MAKE_FLAGS = HOSTCC="$(HOSTCC)" HOSTCFLAGS="$(HOSTCFLAGS)" \
+LINUX26_MAKE_FLAGS = HOSTCC="$(HOSTCC)" \

	ARCH=$(KERNEL_ARCH) \
	CFLAGS_KERNEL="$(filter-out $(__LINUX26_NO_PIC),$(TARGET_CFLAGS))" \
	INSTALL_MOD_PATH=$(TARGET_DIR) \

Quoted 8 lines · Grant Likely

From: Grant Likely <[email protected]>

Setting HOSTCFLAGS when calling make for the kernel compile messes up the tools that the kernel builds for itself. Specifically, the building of the device tree compiler (dtc) in arch/powerpc adds some required flags to HOSTCFLAGS. However, if HOSTCFLAGS= is specified when calling make, then the local flags are never added and the kernel compile fails.

One could argue that this is really a bug in the kernel.

Quoted 5 lines

This patch removes the HOSTCFLAGS= from $(LINUX26_MAKE_FLAGS). I've marked this patch as an RFC because I don't know what is really required here. Removing it works for me (of course), but it may break other users. I just don't know if there is a better way to set HOSTCFLAGS so that it doesn't override the settings that the kernel uses itself.

you could append it to HOSTCC, but that didn't work either (at least for some earlier 2.6.x). The problem with HOSTCFLAGS and HOSTCC is that for some hosts the HOSTCFLAGS are integral part of having a working HOSTCC, you can't separate them without rendering your HOSTCC completely dysfunctional (since the stuff is supposed to run, too).

From: Grant Likely <[email protected]>

Add an option in Linux advanced configuration to clone a git repository directly (without a snapshot tarball).

---

This patch depends on the earlier patch to add the variable $(LINUX26_VERSION_MOD) because the value of $(LINUX26_VERSION) is set to 'git' here, but the kernel could report just about any version string.
---

target/linux/Config.in.advanced   |   30 ++++++++++++++++++++++++++++++
target/linux/Makefile.in.advanced |   12 ++++++++++++
2 files changed, 42 insertions(+), 0 deletions(-)

target/linux/Config.in.advanced +9 -0

index 798a662..350129b 100644
@@ -15,6 +15,10 @@ if BR2_KERNEL_LINUX_ADVANCED
 # BR2_CUSTOM_LINUX26_PATCH_SITE
 # BR2_CUSTOM_LINUX26_PATCH
 #
+# BR2_LINUX26_GIT
+# BR2_LINUX26_GIT_URL
+# BR2_LINUX26_GIT_BRANCH
+#
 # BR2_LINUX_BSP_PATCH
 #
 # BR2_PACKAGE_LINUX_USE_KCONFIG

@@ -140,6 +144,11 @@ config BR2_LINUX_2_6_STABLE
 	help
 	  Linux 2.6.26.3
 
+config BR2_LINUX26_GIT
+	bool "Use a Linux git repository"
+	help
+	  Clone from a git tree.
+

config BR2_LINUX_2_6_26

	bool "Linux 2.6.26"
	select BR2_KERNEL_BASE

target/linux/Config.in.advanced +0 -0

@@ -253,6 +262,26 @@ config BR2_CUSTOM_LINUX26_PATCH_SITE
 

endif

target/linux/Config.in.advanced +20 -0

+if BR2_LINUX26_GIT
+config BR2_LINUX26_GIT_URL
+	string "git URL"
+	default "file:///path/to/git/tree/linux-2.6/"
+	help
+	  URL to git repository
+
+	  Any git URL works here, but you may find it more efficient to
+	  clone from a tree on the same local filesystem using the file:///
+	  protocol.  The file:/// protocol allows git to hardlink to the
+	  respository database which is faster and is requires less disk
+	  space.
+
+config BR2_LINUX26_GIT_BRANCH
+	string "git branch"
+	default "master"
+	help
+	  Name of branch to use in get repository
+endif
+

# -----------------------------------------------

menu "Patches"

target/linux/Config.in.advanced +1 -0

 	default $(BR2_CUSTOM_LINUX26_VERSION) if BR2_LINUX26_CUSTOM
+	default "git" if BR2_LINUX26_GIT
 

menu "Linux Kernel Configuration"

target/linux/Makefile.in.advanced +0 -0

index 9c6df1f..b0cb03e 100644
@@ -209,6 +209,7 @@ $(DL_DIR)/$(LINUX26_PATCH_SOURCE):
 	 $(WGET) -P $(DL_DIR) $(LINUX26_PATCH_SITE)/$(LINUX26_PATCH_SOURCE)

endif

+ifneq ($(BR2_LINUX26_GIT),y) $(LINUX26_DIR)/.unpacked: $(DL_DIR)/$(LINUX26_SOURCE)

	rm -rf $(LINUX26_DIR)
	@echo "*** Unpacking kernel source"

target/linux/Makefile.in.advanced +0 -0

@@ -218,6 +219,14 @@ ifneq ($(DOWNLOAD_LINUX26_VERSION),$(LINUX26_VERSION))
 	mv -f $(PROJECT_BUILD_DIR)/linux-$(DOWNLOAD_LINUX26_VERSION) $(LINUX26_DIR)

endif
touch $@

target/linux/Makefile.in.advanced +3 -0

 	@echo BR2_LINUX26_CUSTOM=$(BR2_LINUX26_CUSTOM)
 	@echo BR2_CUSTOM_LINUX26_PATCH_SITE=$(BR2_CUSTOM_LINUX26_PATCH_SITE)
 	@echo BR2_CUSTOM_LINUX26_PATCH=$(BR2_CUSTOM_LINUX26_PATCH)
+	@echo BR2_LINUX26_GIT=$(BR2_LINUX26_GIT)
+	@echo BR2_LINUX26_GIT_URL=$(BR2_LINUX26_GIT_URL)
+	@echo BR2_LINUX26_GIT_BRANCH=$(BR2_LINUX26_GIT_BRANCH)
 	@echo BR2_LINUX_BSP_PATCH=$(BR2_LINUX_BSP_PATCH)
 	@echo BR2_PACKAGE_LINUX_USE_KCONFIG=$(BR2_PACKAGE_LINUX_USE_KCONFIG)
 	@echo BR2_PACKAGE_LINUX_USE_DEFCONFIG=$(BR2_PACKAGE_LINUX_USE_DEFCONFIG)

Quoted 10 lines · Grant Likely

From: Grant Likely <[email protected]>

Add an option in Linux advanced configuration to clone a git repository directly (without a snapshot tarball).

---

This patch depends on the earlier patch to add the variable $(LINUX26_VERSION_MOD) because the value of $(LINUX26_VERSION) is set to 'git' here, but the kernel could report just about any version string.

Quoted 22 lines

target/linux/Config.in.advanced +20 -0

+if BR2_LINUX26_GIT
+config BR2_LINUX26_GIT_URL
+      string "git URL"
+      default "file:///path/to/git/tree/linux-2.6/"
+      help
+        URL to git repository
+
+        Any git URL works here, but you may find it more efficient to
+        clone from a tree on the same local filesystem using the file:///
+        protocol.  The file:/// protocol allows git to hardlink to the
+        respository database which is faster and is requires less disk
+        space.
+
+config BR2_LINUX26_GIT_BRANCH
+      string "git branch"
+      default "master"
+      help
+        Name of branch to use in get repository
+endif
+

# -----------------------------------------------

target/linux/Config.in.advanced config BR2_LINUX26_VERSION · line 448

Quoted 4 lines

menu "Patches"

target/linux/Config.in.advanced +0 -0

@@ -418,6 +447,7 @@ config BR2_LINUX26_VERSION
      default "2.6.22.10" if BR2_LINUX_2_6_22_10
      default "$(BR2_KERNEL_CURRENT_VERSION)"if BR2_LINUX_2_6_STABLE

looking at the URI of this file. No wonder.

Quoted 5 lines

target/linux/Config.in.advanced +1 -0

      default $(BR2_CUSTOM_LINUX26_VERSION) if BR2_LINUX26_CUSTOM
+      default "git" if BR2_LINUX26_GIT
 

menu "Linux Kernel Configuration"

target/linux/Makefile.in.advanced ifneq ($(DOWNLOAD_LINUX26_VERSION),$(LINUX26_VERSION)) · line 229

Quoted 12 lines

target/linux/Makefile.in.advanced +0 -0

@@ -218,6 +219,14 @@ ifneq ($(DOWNLOAD_LINUX26_VERSION),$(LINUX26_VERSION))
      mv -f $(PROJECT_BUILD_DIR)/linux-$(DOWNLOAD_LINUX26_VERSION) $(LINUX26_DIR)

endif
touch $@

target/linux/Makefile.in.advanced +8 -0

+else
+$(LINUX26_DIR)/.unpacked:
+      @echo "*** Cloning kernel git tree"
+      git clone --depth 1 $(BR2_LINUX26_GIT_URL) $(LINUX26_DIR)
+      cd $(LINUX26_DIR) && \
+              git reset --hard origin/$(BR2_LINUX26_GIT_BRANCH)
+      touch $@
+endif # BR2_LINUX26_GIT

I've done something like this for libtool, and i *think* that i will not waste _that_ much bandwith over and over again. Not my call, though.

Review linux-status:

Quoted 1 line

(quoted diff) +0 -0

@@ -499,6 +508,9 @@ linux-status:

linux-status. If you have make, you most likely have grep, too.

Quoted 10 lines

target/linux/Makefile.in.advanced +3 -0

      @echo BR2_LINUX26_CUSTOM=$(BR2_LINUX26_CUSTOM)
      @echo BR2_CUSTOM_LINUX26_PATCH_SITE=$(BR2_CUSTOM_LINUX26_PATCH_SITE)
      @echo BR2_CUSTOM_LINUX26_PATCH=$(BR2_CUSTOM_LINUX26_PATCH)
+      @echo BR2_LINUX26_GIT=$(BR2_LINUX26_GIT)
+      @echo BR2_LINUX26_GIT_URL=$(BR2_LINUX26_GIT_URL)
+      @echo BR2_LINUX26_GIT_BRANCH=$(BR2_LINUX26_GIT_BRANCH)
      @echo BR2_LINUX_BSP_PATCH=$(BR2_LINUX_BSP_PATCH)
      @echo BR2_PACKAGE_LINUX_USE_KCONFIG=$(BR2_PACKAGE_LINUX_USE_KCONFIG)
      @echo BR2_PACKAGE_LINUX_USE_DEFCONFIG=$(BR2_PACKAGE_LINUX_USE_DEFCONFIG)

Quoted 3 lines · Bernhard Reutner-Fischer

Quoted 1 line · Grant Likely

(quoted diff) +0 -0

@@ -418,6 +447,7 @@ config BR2_LINUX26_VERSION

Quoted 3 lines

target/linux/Config.in.advanced config BR2_LINUX26_VERSION · line 448

Quoted 1 line

target/linux/Config.in.advanced +0 -0

      default "$(BR2_KERNEL_CURRENT_VERSION)"if BR2_LINUX_2_6_STABLE

looking at the URI of this file. No wonder.

Umm, I don't know what you are referring to here. Are you referring to using 'git' as the value of BR2_LINUX26_VERSION instead of the full URL?

Quoted 2 lines

I've done something like this for libtool, and i *think* that i will not waste _that_ much bandwith over and over again. Not my call, though.

It should be okay. Using the --depth flag keeps the download size to the bear minimum. Using it on current mainline results in ~100MB of git repo (as opposed to ~50MB for a bz2 tarball and ~300MB for a full git clone). Also, in the help text I recommend to use a local git tree to keep clone bandwidth costs to a minimum.

Quoted 4 lines

Review linux-status:

Quoted 2 lines

(quoted diff) +0 -0

@@ -499,6 +508,9 @@ linux-status:

linux-status. If you have make, you most likely have grep, too.

I had mostly just been following the existing lead. I can drop this change if it is preferred.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Grant" == Grant Likely <[email protected]> writes: