kernel patch not applied

Buildroot David Claffey 9 participants 20 messages May 10, 2007 – Nov 4, 2008

Share & tools

David Claffey

author

2007-05-10 14:21 UTC #0 lore raw

I have a custom kernel patch I want applied when building the 2.6 kernel. I created a device under target/devices with a directory kernel-patches and BR2_BOARD_PATH set correctly. However, the patch is never applied apparently because all patches are assumed to be minor kernel version patches.

In the case when DOWNLOAD_LINUX26_VERSION equals LINUX26_VERSION no patches, including custom kernel patches, are applied. My current fix below will change the directory name if minor kernel patches are applied, but still allow patches in $(BR2_BOARD_PATH)/kernel-patches to be applied.

Could this cause problem elsewhere in the build?

linux26.mk (working copy) renamed from linux26.mk (revision 18593) +1 -1

Index: target/linux26.mk
===================================================================
@@ -74,11 +74,11 @@
        mv -f $(BUILD_DIR)/linux-$(DOWNLOAD_LINUX26_VERSION) $(LINUX26_DIR)
 endif
        touch $@
+endif # ($(LINUX26_VERSION),$(LINUX_HEADERS_VERSION))
 
 $(LINUX26_DIR)/.patched: $(LINUX26_DIR)/.unpacked
        toolchain/patch-kernel.sh $(LINUX26_DIR) $(LINUX26_PATCH_DIR)
        touch $@
-endif # ($(LINUX26_VERSION),$(LINUX_HEADERS_VERSION))
 
 $(LINUX26_DIR)/.configured:  $(LINUX26_DIR)/.patched  $(LINUX26_KCONFIG)
        cp -dpf $(LINUX26_KCONFIG) $(LINUX26_DIR)/.config

David Claffey

author

2007-05-10 15:34 UTC #1 lore raw

This actually causes an override of the .patched target in toolchain/kernel-headers/kernel-headers-new.makefile.

Suggestions?

Quoted 34 lines · David Claffey

I have a custom kernel patch I want applied when building the 2.6 kernel. I created a device under target/devices with a directory kernel-patches and BR2_BOARD_PATH set correctly. However, the patch is never applied apparently because all patches are assumed to be minor kernel version patches.
In the case when DOWNLOAD_LINUX26_VERSION equals LINUX26_VERSION no patches, including custom kernel patches, are applied. My current fix below will change the directory name if minor kernel patches are applied, but still allow patches in $(BR2_BOARD_PATH)/kernel-patches to be applied.
Could this cause problem elsewhere in the build?
Index: target/linux26.mk
===================================================================
linux26.mk (working copy) renamed from linux26.mk (revision 18593) +1 -1
@@ -74,11 +74,11 @@
        mv -f $(BUILD_DIR)/linux-$(DOWNLOAD_LINUX26_VERSION) $(LINUX26_DIR)
 endif
        touch $@
+endif # ($(LINUX26_VERSION),$(LINUX_HEADERS_VERSION))
 
 $(LINUX26_DIR)/.patched: $(LINUX26_DIR)/.unpacked
        toolchain/patch-kernel.sh $(LINUX26_DIR) $(LINUX26_PATCH_DIR)
        touch $@
-endif # ($(LINUX26_VERSION),$(LINUX_HEADERS_VERSION))
 
 $(LINUX26_DIR)/.configured:  $(LINUX26_DIR)/.patched  $(LINUX26_KCONFIG)
        cp -dpf $(LINUX26_KCONFIG) $(LINUX26_DIR)/.config
_______________________________________________
buildroot mailing list
buildroot at uclibc.org
http://busybox.net/mailman/listinfo/buildroot

Hans-Christian Egtvedt

2007-05-11 14:31 UTC #2 lore raw

Quoted 4 lines

This actually causes an override of the .patched target in toolchain/kernel-headers/kernel-headers-new.makefile.
Suggestions?

I just bumped into the same issue myself.

in toolchain/kernel-headers/kernel-headers-new.makefile

I had to change

$(LINUX_HEADERS_UNPACK_DIR)/.patched:
$(LINUX_HEADERS_UNPACK_DIR)/.unpacked

        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
toolchain/kernel-headers \
                linux-$(LINUX_HEADERS_VERSION)-\*.patch{,.gz,.bz2}
ifeq ($(BR2_PACKAGE_OPENSWAN),y)
        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
                linux-$(LINUX_HEADERS_VERSION)-\*.patch{,.gz,.bz2}

endif
touch $@

$(LINUX_HEADERS_UNPACK_DIR)/.patched:
$(LINUX_HEADERS_UNPACK_DIR)/.unpacked

        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
toolchain/kernel-headers \
                linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
ifeq ($(BR2_PACKAGE_OPENSWAN),y)
        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
                linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*

endif
touch $@

Signature · 4 lines

With kind regards,

Hans-Christian Egtvedt, siv.ing. (M.Sc.)
Applications Engineer - AVR32 System Solutions - Atmel Norway

Bernhard Fischer

2007-05-11 15:40 UTC #3 lore raw

Quoted 25 lines · Hans-Christian Egtvedt

Quoted 4 lines
This actually causes an override of the .patched target in toolchain/kernel-headers/kernel-headers-new.makefile.
Suggestions?
I just bumped into the same issue myself.
in toolchain/kernel-headers/kernel-headers-new.makefile
I had to change
$(LINUX_HEADERS_UNPACK_DIR)/.patched:
$(LINUX_HEADERS_UNPACK_DIR)/.unpacked
       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
toolchain/kernel-headers \
               linux-$(LINUX_HEADERS_VERSION)-\*.patch{,.gz,.bz2}
ifeq ($(BR2_PACKAGE_OPENSWAN),y)
       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
               linux-$(LINUX_HEADERS_VERSION)-\*.patch{,.gz,.bz2}
endif
touch $@
to

Quoted 8 lines

$(LINUX_HEADERS_UNPACK_DIR)/.patched:
$(LINUX_HEADERS_UNPACK_DIR)/.unpacked

       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
toolchain/kernel-headers \
               linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
ifeq ($(BR2_PACKAGE_OPENSWAN),y)
       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
               linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*

which means that your shell just doesn't expand ba{r,z}

We use patterns also to specify targets we intend to strip, so either use a different shell or fix all occurances, i'd say.

David Claffey

author

2007-05-11 16:29 UTC #4 lore raw

The braces expansion issue is different.

kernel-headers-new.makefile and linux26.mk .patched targets overlap.

$(LINUX_HEADERS_UNPACK_DIR)/.patched:
$(LINUX26_DIR)/.patched:

The kernel-headers target pulls in linux-$(LINUX_HEADERS_VERSION)-* patches, while the linux26.mk is explicitly pulling in any patches placed in the $(BR2_BOARD_PATH)/kernel-patches directory.

The latter does not occur because the kernel-headers rule satisfies the dependency early on.

Quoted 39 lines · Bernhard Fischer

Quoted 24 lines · Hans-Christian Egtvedt
Quoted 4 lines
This actually causes an override of the .patched target in toolchain/kernel-headers/kernel-headers-new.makefile.
Suggestions?
I just bumped into the same issue myself.
in toolchain/kernel-headers/kernel-headers-new.makefile
I had to change
$(LINUX_HEADERS_UNPACK_DIR)/.patched:
$(LINUX_HEADERS_UNPACK_DIR)/.unpacked
       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
toolchain/kernel-headers \
               linux-$(LINUX_HEADERS_VERSION)-\*.patch{,.gz,.bz2}
ifeq ($(BR2_PACKAGE_OPENSWAN),y)
       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
               linux-$(LINUX_HEADERS_VERSION)-\*.patch{,.gz,.bz2}
endif
touch $@
to
Quoted 8 lines
$(LINUX_HEADERS_UNPACK_DIR)/.patched:
$(LINUX_HEADERS_UNPACK_DIR)/.unpacked
       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
toolchain/kernel-headers \
               linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
ifeq ($(BR2_PACKAGE_OPENSWAN),y)
       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
               linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
which means that your shell just doesn't expand ba{r,z}
We use patterns also to specify targets we intend to strip, so either use a different shell or fix all occurances, i'd say.

Bernhard Fischer

2007-05-12 10:31 UTC #5 lore raw

Quoted 7 lines · David Claffey

The braces expansion issue is different.
kernel-headers-new.makefile and linux26.mk .patched targets overlap.
$(LINUX_HEADERS_UNPACK_DIR)/.patched:
$(LINUX26_DIR)/.patched:

Quoted 6 lines

The kernel-headers target pulls in linux-$(LINUX_HEADERS_VERSION)-* patches, while the linux26.mk is explicitly pulling in any patches placed in the $(BR2_BOARD_PATH)/kernel-patches directory.
The latter does not occur because the kernel-headers rule satisfies the dependency early on.

Thanks for the explanation. I think that we want to apply _any_ patches even for the kernel-headers, since a later applied patch could render parts of the headers to be incorrect ?). Can you please try to apply $(BR2_BOARD_PATH)/kernel-patches/linux-$(LINUX_HEADERS_VERSION)*.patch* in kernel-headers-new.makefile and after successful verification send the patch to me? TIA

?) Suppose i have a patch that removes the VT layer. This patch would lead to inconsistency if applied after the headers are installed.

David Claffey

author

2007-05-29 20:52 UTC #6 lore raw

Quoted 4 lines

Can you please try to apply $(BR2_BOARD_PATH)/kernel-patches/linux-$(LINUX_HEADERS_VERSION)*.patch* in kernel-headers-new.makefile and after successful verification send the patch to me? TIA

Finally got a chance to do a fresh build. This simple patch now pulls in custom device-specific kernel patches at kernel-header build time, as you suggested. However, it differs from target/linux26.mk where the patch files are not filtered by "linux-$(LINUX_HEADERS_VERSION)*". Not sure if this will affect other builds.

kernel-headers/kernel-headers-new.makefile (working copy) renamed from kernel-headers/kernel-headers-new.makefile (revision 18607) +0 -0

@@ -30,6 +30,7 @@
 $(LINUX_HEADERS_UNPACK_DIR)/.patched: $(LINUX_HEADERS_UNPACK_DIR)/.unpacked
        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)

toolchain/kernel-headers \
                linux-$(LINUX_HEADERS_VERSION)-\*.patch{,.gz,.bz2}
+       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
$(BR2_BOARD_PATH)/kernel-patches linux-$(LINUX_HEADERS_VERSION)*.patch{,.gz,.bz2}
 ifeq ($(BR2_PACKAGE_OPENSWAN),y)
        toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
                linux-$(LINUX_HEADERS_VERSION)-\*.patch{,.gz,.bz2}

Hans-Christian Egtvedt

2007-05-14 05:21 UTC #7 lore raw

In reply to Bernhard Fischer

Quoted 1 line · Bernhard Fischer

On Fri, May 11, 2007 at 04:31:49PM +0200, Hans-Christian Egtvedt wrote:

<cut>

Quoted 10 lines

Quoted 8 lines
$(LINUX_HEADERS_UNPACK_DIR)/.patched:
$(LINUX_HEADERS_UNPACK_DIR)/.unpacked
       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
toolchain/kernel-headers \
               linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
ifeq ($(BR2_PACKAGE_OPENSWAN),y)
       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
               linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
which means that your shell just doesn't expand ba{r,z}

Weird, I tried zsh, bash and sh. I am building on Ubuntu 7.04.

Quoted 2 lines

We use patterns also to specify targets we intend to strip, so either use a different shell or fix all occurances, i'd say.

Which shell on which distribution works?

Signature · 2 lines

Best regards
Hans-Christian Egtvedt

Bernhard Fischer

2007-05-14 07:11 UTC #8 lore raw

Quoted 14 lines · Hans-Christian Egtvedt

Quoted 1 line · Bernhard Fischer
On Fri, May 11, 2007 at 04:31:49PM +0200, Hans-Christian Egtvedt wrote:
<cut>
Quoted 9 lines
Quoted 8 lines
$(LINUX_HEADERS_UNPACK_DIR)/.patched:
$(LINUX_HEADERS_UNPACK_DIR)/.unpacked
       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
toolchain/kernel-headers \
               linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
ifeq ($(BR2_PACKAGE_OPENSWAN),y)
       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
               linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*

Quoted 3 lines

Quoted 1 line
which means that your shell just doesn't expand ba{r,z}
Weird, I tried zsh, bash and sh. I am building on Ubuntu 7.04.

IIRC ubuntu defaults to dash as sh, so make sure that
a) SHELL points to /bin/bash (ash may work too) or,
b) symlink sh to be bash

a) is of course the preferred solution, didn't look if there are direct references to /bin/sh instead of $SHELL in the makefiles, though.

Quoted 5 lines

Quoted 3 lines
We use patterns also to specify targets we intend to strip, so either use a different shell or fix all occurances, i'd say.
Which shell on which distribution works?

Christopher Reder

2007-05-14 12:41 UTC #9 lore raw

[Buildroot] Matchbox Support

Hello all. I am using buildroot for a project with an ARM at91rm9200 and it is working nicely after getting some assistance building. It is building a file system with busybox and tiny-x and I'd like to incorporate a desktop like matchbox in with it. I read that there were a few people incorporating it into the build but I could not find it in there. Can someone let me know if it is in there or if they have a patch to add it in?

Thanks in advance!
Christopher Reder

Assen Stoyanov

2007-05-15 08:46 UTC #10 lore raw

[Buildroot] Matchbox Support

Hello All,

I am 99% ready with the port of matchbox project. Incl.:
- Matchbox Window Manager
- Matchbox Startup Notification
- Matchbox Desktop
- Matchbox Virtual Keyboard

Also other thinks that are 100% done are:

1) lilo 22.8 (x86 boot loader)
2) tslib 1.0 (touchscreen lib and utils)
3) X11R7 libs (libX11.so)
3.1) libICE.so - Inter Client Exchange library
3.2) libXdmcp.so - X Display Manager Control Protocol library 3.3) libXfixes.so - X Fixes extension library
3.4) libXfont.so - X font libary (used by the X server) 3.5) libXext.so - X Extension library
3.6) libXtst.so - X Test Extensions library
3.7) libXdamage.so - X Damage library
3.8) libXcomposite.so - X Composite library
3.9) libXres.so - X Resources library
3.10) libXrender.so - X Render extension library
3.11) libXrandr.so - X Resize and Rotate extension library 3.12) libXcursor.so - Client-side cursor loading library 3.13) libXft.so - X FreeType library. Client-side fonts with FreeType 3.14) libSM.so - X Session Management library.
3.15) libxkbfile.so - X KBFile utils library.
3.16) libXt.so - X Toolkit library.
3.17) libXmu.so - X Xmu/Xmuu library.
3.18) libXpm.so - X Pixmap library.
3.19) libXaw.so - X Athena Extensions.
4) X11R7 Kdrive (TinyX) Servers (incl. tslib support)

TODOs (this week):
- refactor cairo;
- refactor glib/gtk;
- add jikes java compiler in toolchain;
- add JamVM (java virtual machine)
- add GNU Classpath 0.95 with (optional) GTK/Cairo peers for full awt/swing support.

My question is - what is the best way to submit all these changes to the buildroot repository?

Best Regards,
Assen Stoyanov

----- Original Message -----
From: "Christopher Reder" <[email protected]>
To: <[email protected]>
Sent: Monday, May 14, 2007 15:41
Subject: [Buildroot] Matchbox Support

Quoted 29 lines

Hello all. I am using buildroot for a project with an ARM at91rm9200 and it
is working nicely after getting some assistance building. It is building a
file system with busybox and tiny-x and I'd like to incorporate a desktop like matchbox in with it. I read that there were a few people incorporating
it into the build but I could not find it in there. Can someone let me know
if it is in there or if they have a patch to add it in?
Thanks in advance!
Christopher Reder
_______________________________________________
buildroot mailing list
buildroot at uclibc.org
http://busybox.net/mailman/listinfo/buildroot
Signature · 4 lines
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.0/804 - Release Date: 5/14/2007 
4:46 PM

Signature · 3 lines

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.467 / Virus Database: 269.7.0/804 - Release Date: 5/14/2007 4:46 PM

Peter Korsgaard

2007-05-15 10:55 UTC #11 lore raw

[Buildroot] Matchbox Support

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"AS" == Assen Stoyanov <[email protected]> writes:

Hi,

AS> Hello All, I am 99% ready with the port of matchbox AS> project. Incl.: - Matchbox Window Manager - Matchbox Startup AS> Notification - Matchbox Desktop - Matchbox Virtual Keyboard

AS> Also other thinks that are 100% done are:

Cool!

AS> My question is - what is the best way to submit all these changes AS> to the buildroot repository?

Send patches to the bug tracker or this ml.

Signature · 1 line

Bye, Peter Korsgaard

Hans-Christian Egtvedt

2007-05-14 15:25 UTC #12 lore raw

In reply to Bernhard Fischer

Quoted 3 lines · Bernhard Fischer

Quoted 2 lines · Hans-Christian Egtvedt
Quoted 1 line · Bernhard Fischer
On Fri, May 11, 2007 at 04:31:49PM +0200, Hans-Christian Egtvedt wrote:

<cut>

Quoted 5 lines

Quoted 1 line
Weird, I tried zsh, bash and sh. I am building on Ubuntu 7.04.
IIRC ubuntu defaults to dash as sh, so make sure that
a) SHELL points to /bin/bash (ash may work too) or,

Aha, setting SHELL to /bin/bash makes this work, thanks.

Perhaps the top level Makefile should modify SHELL for you?

Signature · 2 lines

Mvh
Hans-Christian Egtvedt

Bernhard Fischer

2007-05-14 15:34 UTC #13 lore raw

Quoted 9 lines · Hans-Christian Egtvedt

Quoted 5 lines
Quoted 1 line
Weird, I tried zsh, bash and sh. I am building on Ubuntu 7.04.
IIRC ubuntu defaults to dash as sh, so make sure that
a) SHELL points to /bin/bash (ash may work too) or,
Aha, setting SHELL to /bin/bash makes this work, thanks.
Perhaps the top level Makefile should modify SHELL for you?

The user is supposed to set the environment he wants to use. This includes but is not limited to SHELL, HOSTCXX, HOSTCC, MAKE etc, etc.

Hans-Christian Egtvedt

2007-05-15 07:47 UTC #14 lore raw

Quoted 1 line · Bernhard Fischer

On Mon, May 14, 2007 at 05:25:53PM +0200, Hans-Christian Egtvedt wrote:

<cut>

Quoted 7 lines

Quoted 3 lines
Aha, setting SHELL to /bin/bash makes this work, thanks.
Perhaps the top level Makefile should modify SHELL for you?
The user is supposed to set the environment he wants to use. This includes but is not limited to SHELL, HOSTCXX, HOSTCC, MAKE etc, etc.

I understand HOST..., MAKE, etc. But since some of the scripts really depend on you using the bash shell, then I think it should be either forced or at least given a warning when starting to build.

Will keep the noise a bit down on this email list if people know why some parts of the build process fails :)

Signature · 2 lines

Mvh
Hans-Christian Egtvedt

Bernhard Fischer

2007-05-15 08:53 UTC #15 lore raw

Quoted 13 lines · Hans-Christian Egtvedt

Quoted 1 line · Bernhard Fischer
On Mon, May 14, 2007 at 05:25:53PM +0200, Hans-Christian Egtvedt wrote:
<cut>
Quoted 7 lines
Quoted 3 lines
Aha, setting SHELL to /bin/bash makes this work, thanks.
Perhaps the top level Makefile should modify SHELL for you?
The user is supposed to set the environment he wants to use. This includes but is not limited to SHELL, HOSTCXX, HOSTCC, MAKE etc, etc.

Quoted 6 lines

I understand HOST..., MAKE, etc. But since some of the scripts really depend on you using the bash shell, then I think it should be either forced or at least given a warning when starting to build.
Will keep the noise a bit down on this email list if people know why some parts of the build process fails :)

I don't think depending on bash is desirable. The scripts should also work at least with ash, imo. Short of that, $(wildcard ) comes to mind, which would fix this proper in the realm of make (patches welcome).

Ulf Samuelsson

2007-05-15 10:35 UTC #16 lore raw

[Buildroot] Whats happened to Eric?

He does not answer mails...

Best Regards
Ulf Samuelsson

Erik Andersen

2007-05-15 19:04 UTC #17 lore raw

[Buildroot] Whats happened to Eric?

Quoted 1 line · Ulf Samuelsson

He does not answer mails...

Erik is buried in a huge project for his work. While I do run a small consulting business doing embedded Linux stuff, mainly for the fun and diversion it affords me, my main job is doing computer forensics work, which has at best only a peripheral relationship with embedded Linux. With my main job taking up most of my time, between work and family (I'm happily married with 4 young kids) I have had almost no surplus time for my usual leisure time work on uClibc, buildroot, for the past few months. I remain hundreds of emails behind most of the time of late... Sortof sucks, but that is the way it is.

If you would like to obtain svn commit privs I would be happy to get you setup, at which point you would be able to get your board support work in place on your own. I agree with having it included in buildroot but I do not presently have the personal bandwidth to shepherd it into place and it seems noone else has done so either. Sorry I've been so busy/absent/negligent,

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Julien Boibessot

2008-11-04 18:19 UTC #18 lore raw

In reply to Bernhard Fischer

Hi,

It's quite a long time now, since first email, but I was faced to the problem today, when updating my old buildroot to the latest svn one.

Bernhard Fischer a ?crit :

Quoted 23 lines · Hans-Christian Egtvedt

Quoted 17 lines · Bernhard Fischer
Quoted 3 lines · Hans-Christian Egtvedt
<cut>
Quoted 9 lines
Quoted 9 lines
$(LINUX_HEADERS_UNPACK_DIR)/.patched:
$(LINUX_HEADERS_UNPACK_DIR)/.unpacked
       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
toolchain/kernel-headers \
               linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
ifeq ($(BR2_PACKAGE_OPENSWAN),y)
       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
               linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
Quoted 4 lines
Quoted 2 lines
which means that your shell just doesn't expand ba{r,z}
Weird, I tried zsh, bash and sh. I am building on Ubuntu 7.04.

Quoted 8 lines

IIRC ubuntu defaults to dash as sh, so make sure that
a) SHELL points to /bin/bash (ash may work too) or,
b) symlink sh to be bash
a) is of course the preferred solution, didn't look if there are direct references to /bin/sh instead of $SHELL in the makefiles, though.

I'm working on KUbuntu 7.10. (yes, I know it's bad :-) ).
a) doesn't work for me (even if my SHELL env is pointing to /bin/bash)

only b) or "make SHELL=/bin/bash" are working.

It's just a 2 cents feedback, so I'm not waiting for an answer ;-)

Regards,
Julien

Bernhard Reutner-Fischer

2008-11-04 19:54 UTC #19 lore raw

Quoted 34 lines · Julien Boibessot

Hi,
It's quite a long time now, since first email, but I was faced to the problem today, when updating my old buildroot to the latest svn one.
Bernhard Fischer a ?crit :
Quoted 28 lines · Hans-Christian Egtvedt
Quoted 17 lines · Bernhard Fischer
Quoted 3 lines · Hans-Christian Egtvedt
<cut>
Quoted 9 lines
Quoted 9 lines
$(LINUX_HEADERS_UNPACK_DIR)/.patched:
$(LINUX_HEADERS_UNPACK_DIR)/.unpacked
       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR)
toolchain/kernel-headers \
               linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
ifeq ($(BR2_PACKAGE_OPENSWAN),y)
       toolchain/patch-kernel.sh $(LINUX_HEADERS_UNPACK_DIR) package/openswan \
               linux-$(LINUX_HEADERS_VERSION)-\*.patch.\*
Quoted 4 lines
Quoted 2 lines
which means that your shell just doesn't expand ba{r,z}
Weird, I tried zsh, bash and sh. I am building on Ubuntu 7.04.
IIRC ubuntu defaults to dash as sh, so make sure that
a) SHELL points to /bin/bash (ash may work too) or,
b) symlink sh to be bash

Quoted 7 lines

Quoted 3 lines
a) is of course the preferred solution, didn't look if there are direct references to /bin/sh instead of $SHELL in the makefiles, though.
I'm working on KUbuntu 7.10. (yes, I know it's bad :-) ).
a) doesn't work for me (even if my SHELL env is pointing to /bin/bash)
only b) or "make SHELL=/bin/bash" are working.

yes. Note that there is also CONFIG_SHELL (which should be used in a consistent manner everywhere) for $(shell ....) invocations.

Quoted 2 lines

It's just a 2 cents feedback, so I'm not waiting for an answer ;-)

Thanks for the feedback, I could imagine that it proves helpful for somebody.

cheers,