* [Buildroot] [pull request] Pull request for branch for-2010.11/kernel-image-formats
From: Peter Korsgaard @ 2010-09-29 10:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1285712084.git.thomas.petazzoni@free-electrons.com>
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Thomas> Hello,
Thomas> Two relatively minor improvements to the kernel build infrastructure.
Thomas> Thomas
Thomas> The following changes since commit 3e5e39a8a25a4a085afe08bdcf46933c8d569ed7:
Thomas> Peter Korsgaard (1):
Thomas> barebox/u-boot/linux: don't error out on missing config when make source
Thomas> are available in the git repository at:
Thomas> git://git.busybox.net/~tpetazzoni/git/buildroot for-2010.11/kernel-image-formats
Pulled, thanks!
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [git commit master 1/1] linux: fix uImage location on AVR32
From: Thomas Petazzoni @ 2010-09-29 10:36 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=96652637ccfd94442224019c54341bf86094366a
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
On most architectures, the kernel image can be found in
arch/<ARCH>/boot, but on AVR32, it's in arch/<ARCH>/boot/images.
Issue initially reported by Joachim Pihl
<joachim.pihl@sensordevelopments.com>.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
linux/linux.mk | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/linux/linux.mk b/linux/linux.mk
index 4490023..55dc2bf 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -42,7 +42,11 @@ else ifeq ($(BR2_LINUX_KERNEL_VMLINUX_BIN),y)
LINUX26_IMAGE_NAME=vmlinux.bin
endif
+ifeq ($(KERNEL_ARCH),avr32)
+LINUX26_IMAGE_PATH=$(LINUX26_DIR)/arch/$(KERNEL_ARCH)/boot/images/$(LINUX26_IMAGE_NAME)
+else
LINUX26_IMAGE_PATH=$(LINUX26_DIR)/arch/$(KERNEL_ARCH)/boot/$(LINUX26_IMAGE_NAME)
+endif
# Download
$(LINUX26_DIR)/.stamp_downloaded:
--
1.7.1
^ permalink raw reply related
* [Buildroot] [git commit master 1/1] linux: restrict output image formats to the appropriate arches
From: Thomas Petazzoni @ 2010-09-29 10:36 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=b626dc0791002d61f47c53b619fcba048c40171d
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Some Linux kernel output image formats are available on some archs,
some not. For example 'uImage' is not supported on MIPS, so let's
prevent the user from making this selection.
Issue initially reported by Choi, David <David.Choi@Micrel.Com>.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
linux/Config.in | 10 ++++++----
linux/linux.mk | 2 +-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/linux/Config.in b/linux/Config.in
index a7109a5..1e015b7 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -111,20 +111,22 @@ config BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE
choice
prompt "Kernel binary format"
- default BR2_LINUX_KERNEL_UIMAGE if !BR2_i386 && !BR2_x86_64
- default BR2_LINUX_KERNEL_BZIMAGE if BR2_i386 || BR2_x86_64
config BR2_LINUX_KERNEL_UIMAGE
bool "uImage"
+ depends on BR2_arm || BR2_armeb || BR2_powerpc || BR2_avr32 || BR2_sh || BR2_sh64
config BR2_LINUX_KERNEL_BZIMAGE
bool "bzImage"
+ depends on BR2_i386 || BR2_x86_64
config BR2_LINUX_KERNEL_ZIMAGE
bool "zImage"
+ depends on BR2_arm || BR2_armeb || BR2_powerpc || BR2_sparc || BR2_sh || BR2_sh64 || BR2_xtensa
-config BR2_LINUX_KERNEL_VMLINUX
- bool "vmlinux"
+config BR2_LINUX_KERNEL_VMLINUX_BIN
+ bool "vmlinux.bin"
+ depends on BR2_mips || BR2_mipsel || BR2_sh || BR2_sh64
endchoice
diff --git a/linux/linux.mk b/linux/linux.mk
index aabecc1..4490023 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -38,7 +38,7 @@ else ifeq ($(BR2_LINUX_KERNEL_BZIMAGE),y)
LINUX26_IMAGE_NAME=bzImage
else ifeq ($(BR2_LINUX_KERNEL_ZIMAGE),y)
LINUX26_IMAGE_NAME=zImage
-else ifeq ($(BR2_LINUX_KERNEL_VMLINUX),y)
+else ifeq ($(BR2_LINUX_KERNEL_VMLINUX_BIN),y)
LINUX26_IMAGE_NAME=vmlinux.bin
endif
--
1.7.1
^ permalink raw reply related
* [Buildroot] [git commit master 1/1] fix buildroot.html typos
From: Yegor Yefremov @ 2010-09-29 10:36 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=3f1d79d379aaf1a0d1e6431575539043a777d160
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
docs/buildroot.html | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/docs/buildroot.html b/docs/buildroot.html
index b7a8641..fc754e5 100644
--- a/docs/buildroot.html
+++ b/docs/buildroot.html
@@ -171,7 +171,7 @@ or
<p>All of these "make" commands will need to build a configuration
utility, so you may need to install "development" packages for
- relevent libraries used by the configuration utilities.
+ relevant libraries used by the configuration utilities.
On Debian-like systems, the
<code>libncurses5-dev</code> package is required to use the
<i>menuconfig</i> interface, <code>libqt3-mt-dev</code> is
@@ -345,7 +345,7 @@ $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD
toolchain and tools, these changes will be lost. </li>
<li>Customize the target filesystem skeleton available under
- <code>target/generic/target_skeleton/</code>. You can customize
+ <code>fs/skeleton/</code>. You can customize
configuration files or other stuff here. However, the full file hierarchy
is not yet present because it's created during the compilation process.
Therefore, you can't do everything on this target filesystem skeleton, but
@@ -486,12 +486,12 @@ $ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD
and which steps remain to be done, Buildroot maintains stamp
files (empty files that just tell whether this or that action
has been done). The problem is that these stamp files are not
- uniformely named and handled by the different packages, so some
+ uniformly named and handled by the different packages, so some
understanding of the particular package is needed.</p>
<p>For packages relying on Buildroot packages infrastructures (see
<a href="#add_packages">this section</a> for details), the
- following stamp files are relevent:</p>
+ following stamp files are relevant:</p>
<ul>
@@ -704,7 +704,7 @@ endif
<p>The toolchain generated by Buildroot is located by default in
<code>output/staging/</code>. The simplest way to use it
is to add <code>output/staging/usr/bin/</code> to your PATH
- environnement variable and then to use
+ environment variable and then to use
<code>ARCH-linux-gcc</code>, <code>ARCH-linux-objdump</code>,
<code>ARCH-linux-ld</code>, etc. </p>
@@ -885,7 +885,7 @@ source "package/libfoo/Config.in"
href="#generic-reference">reference</a>.</li>
<li>Makefiles for autotools-based (autoconf, automake, etc.)
- softwares. We provide a dedicated infrastructure for such
+ software. We provide a dedicated infrastructure for such
packages, since autotools is a very common build system. This
infrastructure <i>must</i> be used for new packages that rely on
the autotools as their build system.<br/>We cover them through a
@@ -1614,8 +1614,8 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
gettext library should not be compiled, because it creates various
kind of build failures.</p>
- <p>Additionnaly, some packages (such as libglib2) do require
- gettext unconditionnally, while other packages (those who
+ <p>Additionally, some packages (such as libglib2) do require
+ gettext unconditionally, while other packages (those who
support <code>--disable-nls</code> in general) only require
gettext when locale support is enabled.</p>
@@ -1631,7 +1631,7 @@ LIBFOO_POST_PATCH_HOOKS += LIBFOO_POST_PATCH_FIXUP
</ul>
- <p>Therefore, packages that unconditionnally need gettext should:</p>
+ <p>Therefore, packages that unconditionally need gettext should:</p>
<ol>
<li>Use <code>select BR2_PACKAGE_GETTEXT if
--
1.7.1
^ permalink raw reply related
* [Buildroot] Libtool work: a tentative summary
From: Thomas Petazzoni @ 2010-09-29 8:51 UTC (permalink / raw)
To: buildroot
In-Reply-To: <AANLkTi=Sf1+acAXfCgJcTv+4Yrtw0nEH+_Ugv3+0dVk0@mail.gmail.com>
Hello Paulius,
On Wed, 29 Sep 2010 11:32:29 +0300
Paulius Zaleckas <paulius.zaleckas@gmail.com> wrote:
> I would go for a conservative solution.
> The main reason here is compile speed.
> Currently my configuration takes ~1 hour to compile on my 4x3.4GHz
> machine with DDR3 RAM...
Are you using internal toolchain or external toolchain ?
> The worst part here is that autoreconfigure and ./configure scripts doesn't
> scale on multicore CPU :(
> So adding a lot more autoreconfigure usage would drastically reduce
> build time.
Thanks for your feedback.
For what it's worth, I've started to experiment the modification of our
package infrastructure in order to use real file targets instead of
phony targets for the steps sequencing (download -> extract -> patch ->
configure, etc.). This is one of the requirements to be able to do
top-level parallel builds, which I think, definitely becomes necessary
to parallelize the autoreconf/configure steps of packages. This is
however a lot of work, and I don't expect this to be ready anytime soon.
Regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] auotgen.sh running before ./configure
From: Paulius Zaleckas @ 2010-09-29 8:47 UTC (permalink / raw)
To: buildroot
In-Reply-To: <AANLkTinQeDF2F6zEm6gfmn7qvzbtkQyMF_XB3m81Bv5p@mail.gmail.com>
On Wed, Sep 29, 2010 at 11:28 AM, Belisko Marek <marek.belisko@gmail.com> wrote:
> On Wed, Sep 29, 2010 at 10:23 AM, Paulius Zaleckas
> <paulius.zaleckas@gmail.com> wrote:
>> On Wed, Sep 29, 2010 at 10:57 AM, Belisko Marek <marek.belisko@gmail.com> wrote:
>>> Hi,
>>>
>>> On Mon, Sep 27, 2010 at 10:16 AM, Paulius Zaleckas
>>> <paulius.zaleckas@gmail.com> wrote:
>>>> On Mon, Sep 27, 2010 at 8:36 AM, Belisko Marek <marek.belisko@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> I want to add navit package (navigation sw) to buildroot.
>>>>> Compilation steps described on navit wiki is:
>>>>> 1. run ./autogen.sh
>>>>> 2. then ./configure; make ....
>>>>>
>>>>> How can I add autogen.sh script running before ./configure?
>>>>> It is done automatically?
>>>>>
>>>>> Thanks in advance,
>>>>
>>>> I have a patch for navit:
>>>> http://sourceforge.net/apps/trac/navitux/export/128/trunk/buildroot/patches/navit.patch
>>>>
>>>> SVN revision is old... so you may want to update it.
>>> Did you try compile navit with qt_painter? I try and have some
>>> troubles with include when
>>> compiling qt_painter.cpp. It seems include paths are somehow
>>> incorrectly handled for QtGui and
>>> QtCore. Did you have similar problems?
>>
>> No, I haven't tried Qt, I am always compiling with GTK+.
>>
>>> e.g.: -I/home/open-nandra/projects/buildroot_new/output/staging/home/open-nandra/projects/buildroot_new/output/staging/usr/include/QtGui
>>> is wrong because
>>> /home/open-nandra/projects/buildroot_new/output/staging shouldn't be
>>> at the beginning of the string.
>>
>> Looks like a problem with ./configure script...
>> What version of Navit are you trying to compile?
> Version 3537.
Can you show me 'grep QT_GUI_CFLAGS= config.log' output from navit
build directory (most likely output/build/navit-3537)
^ permalink raw reply
* [Buildroot] Build failure of xlib_libX11 for mipsel
From: Thomas Petazzoni @ 2010-09-29 8:46 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20100919182345.GB28625@tarshish>
Hello,
On Sun, 19 Sep 2010 20:23:46 +0200
Baruch Siach <baruch@tkos.co.il> wrote:
> I'm trying to get TinyX running on a mipsel target (the Alchemy Au1250). I'm
> using the latest CodeSourcery toolchain (version 4.4). The build of the
> xlib_libX11 package fails at the very start with the following error:
>
> cd /home/baruch/git/buildroot/output/build/xlib_libX11-1.3.2/src/util && /usr/bin/gcc \
> -I/home/baruch/git/buildroot/output/build/staging_dir/usr/include -o makekeys makekeys.c
> In file included from /home/baruch/git/buildroot/output/build/staging_dir/usr/include/sys/types.h:31,
> from /home/baruch/git/buildroot/output/build/staging_dir/usr/include/X11/Xos.h:42,
> from makekeys.c:35:
> /home/baruch/git/buildroot/output/build/staging_dir/usr/include/bits/types.h:129:3: error: #error
>
> The strange thing here is that the host gcc is getting run instead of the
> cross compiler.
>
> Anyone got a clue?
Reproduced here. The fact that makekeys is build with the host compiler
is normal. makekeys is needed on the build machine, not on the target
machine, so we hack around in package/x11r7/xlib_libX11/xlib_libX11.mk
to build makekeys for the host. Unfortunately, we have to tell it to
look for include files in $(STAGING_DIR)/usr/include and this messes up
the compilation. Not sure what the fix is for the moment. I'll have a
look later if no-one steps up before to fix it.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH 1/4] Added new menu item to specify a custom port for /etc/inittab
From: Yegor Yefremov @ 2010-09-29 8:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20100928192629.1717d83c@surf>
> Would people cry/complain if instead of the following patch we simply
> replace the TARGET_GENERIC_GETTY_PORT parameter by a single free-form
> text-field ?
I wouldn't ;-) Let's make it this way.
Yegor
^ permalink raw reply
* [Buildroot] Libtool work: a tentative summary
From: Paulius Zaleckas @ 2010-09-29 8:32 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20100928223652.6dc72083@surf>
On Tue, Sep 28, 2010 at 11:36 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
[...]
> Conclusion
> ==========
>
> Therefore, the choice seems to be between :
>
> ?* A conservative solution, only extending what we have today, with
> ? limited changes and impact, but keeping the existing hacks in place.
>
> ?* A radically different solution, with wider changes, more in line
> ? with libtool future, but requiring an autoreconfiguration of all
> ? packages that will not have libtool 2.4 by default.
>
> In my opinion, we should settle on a solution before mid-october, in
> order to merge it before the end of october and give us enough time for
> testing before the release at the end of november. Considering how much
> time Martin and Lionel have dedicated to this issue, I think that their
> respective work deserve some attention.
>
> Thoughts ? Comments ?
I would go for a conservative solution.
The main reason here is compile speed.
Currently my configuration takes ~1 hour to compile on my 4x3.4GHz
machine with DDR3 RAM...
The worst part here is that autoreconfigure and ./configure scripts doesn't
scale on multicore CPU :(
So adding a lot more autoreconfigure usage would drastically reduce
build time.
^ permalink raw reply
* [Buildroot] [PATCH 2/4] Enable terminal type configuration for /etc/inittab
From: Yegor Yefremov @ 2010-09-29 8:31 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20100928192828.2fb6ac19@surf>
Am 28.09.2010 19:28, schrieb Thomas Petazzoni:
> On Fri, 24 Sep 2010 09:37:34 +0200
> Yegor Yefremov <yegor_sub1@visionsystems.de> wrote:
>
>> diff --git a/target/generic/Config.in b/target/generic/Config.in
>> index 286b0a3..e7b2c9f 100644
>> --- a/target/generic/Config.in
>> +++ b/target/generic/Config.in
>> @@ -164,6 +164,12 @@ config BR2_TARGET_GENERIC_GETTY_BAUDRATE_115200
>> bool "115200"
>> endchoice
>>
>> +config BR2_TARGET_GENERIC_GETTY_TERMINAL_TYPE
>> + string "Terminal type"
>> + default "vt100"
>> + help
>> + Specify a terminal type like vt100, linux etc.
> Need only one tab + 2 spaces for the indentation of the help text.
>
> Just out of curiosity, in what cases isn't vt100 an appropriate value ?
Good question. We just use TERM=linux for our Debian installations, so I wanted to do it also for Buildroot. But you're right vt100 should be sufficient, that's why I made it default, so the old behavior is preserved.
Best regards,
Yegor
^ permalink raw reply
* [Buildroot] [PATCH] introducing transmission bittorrent client
From: Thomas Petazzoni @ 2010-09-29 8:22 UTC (permalink / raw)
To: buildroot
In-Reply-To: <4CA110CC.8030009@googlemail.com>
On Mon, 27 Sep 2010 23:46:52 +0200
Marcus Osdoba <marcus.osdoba@googlemail.com> wrote:
> Btw: Thomas preferres another solution for the init-d skript (without
> sleep 5 init). I wasn't able to figure out clearly, why and where the
> IP_ADDR variable is used, so I'm experimenting with the "official"
> init-d-skript from the transmission wiki.
> Would this be a problem in your eyes?
Well, for the moment, we can keep this loop. Fix the other problems
mentionned in my latest review, and resend a new version. We'll merge
that one.
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCHv2 2/4] Enable terminal type configuration for /etc/inittab
From: Yegor Yefremov @ 2010-09-29 8:21 UTC (permalink / raw)
To: buildroot
String value BR2_TARGET_GENERIC_GETTY_TERMINAL_TYPE will be used
to store a terminal type like vt100, ansi, linux etc.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Index: b/target/generic/Config.in
===================================================================
--- a/target/generic/Config.in 2010-09-29 10:00:30.000000000 +0200
+++ b/target/generic/Config.in 2010-09-29 10:02:34.000000000 +0200
@@ -155,6 +155,12 @@
bool "115200"
endchoice
+config BR2_TARGET_GENERIC_GETTY_TERMINAL_TYPE
+ string "Terminal type"
+ default "vt100"
+ help
+ Specify a terminal type like vt100, linux etc.
+
config BR2_TARGET_GENERIC_GETTY_BAUDRATE
string
default "0" if BR2_TARGET_GENERIC_GETTY_BAUDRATE_KEEP
Index: b/target/generic/Makefile.in
===================================================================
--- a/target/generic/Makefile.in 2010-09-29 10:00:30.000000000 +0200
+++ b/target/generic/Makefile.in 2010-09-29 10:01:41.000000000 +0200
@@ -2,6 +2,7 @@
TARGET_GENERIC_ISSUE:=$(call qstrip,$(BR2_TARGET_GENERIC_ISSUE))
TARGET_GENERIC_GETTY:=$(call qstrip,$(BR2_TARGET_GENERIC_GETTY_PORT))
TARGET_GENERIC_GETTY_BAUDRATE:=$(call qstrip,$(BR2_TARGET_GENERIC_GETTY_BAUDRATE))
+TARGET_GENERIC_GETTY_TERMINAL_TYPE:=$(call qstrip,$(BR2_TARGET_GENERIC_GETTY_TERMINAL_TYPE))
target-generic-hostname:
mkdir -p $(TARGET_DIR)/etc
@@ -12,7 +13,7 @@
echo "$(TARGET_GENERIC_ISSUE)" > $(TARGET_DIR)/etc/issue
target-generic-getty:
- $(SED) '/# GENERIC_SERIAL$$/s~^.*#~$(TARGET_GENERIC_GETTY)::respawn:/sbin/getty -L $(TARGET_GENERIC_GETTY) $(TARGET_GENERIC_GETTY_BAUDRATE) vt100 #~' \
+ $(SED) '/# GENERIC_SERIAL$$/s~^.*#~$(TARGET_GENERIC_GETTY)::respawn:/sbin/getty -L $(TARGET_GENERIC_GETTY) $(TARGET_GENERIC_GETTY_BAUDRATE) $(TARGET_GENERIC_GETTY_TERMINAL_TYPE) #~' \
$(TARGET_DIR)/etc/inittab
ifneq ($(TARGET_GENERIC_HOSTNAME),)
^ permalink raw reply
* [Buildroot] [PATCH 4/7] bison: add host rules
From: Thomas Petazzoni @ 2010-09-29 7:03 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1284832789-22631-5-git-send-email-llandwerlin@gmail.com>
On Sat, 18 Sep 2010 19:59:46 +0200
llandwerlin at gmail.com wrote:
> +$(eval $(call AUTOTARGETS,package,bison,host))
Bison is part of our set of mandatory dependencies on the host, as
checked in toolchain/dependencies/dependencies.sh. Therefore,
host-bison shouldn't be needed.
However, flex is also part of the mandatory dependencies on the host,
but we still have a couple of package that depend on host-flex.
Interesting.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] pcmciautils: New package. Patch against current git attached
From: Thomas Petazzoni @ 2010-09-29 6:45 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201009290019.33325.patrikd@telia.com>
Hello Patrik,
Thanks for this patch. First comment: the usual practice is to include
the patch inline in the e-mail, to make it easier to comment on. You
can achieve this very easily without having any problem related to your
e-mail client by using "git send-email" (you just need to teach Git
about your SMTP server and configuration).
No, on your patch!
On Wed, 29 Sep 2010 00:19:33 +0200
Patrik Dahlstr?m <patrikd@telia.com> wrote:
> diff --git a/package/pcmciautils/Config.in b/package/pcmciautils/Config.in
> new file mode 100644
> index 0000000..ad8b26a
> --- /dev/null
> +++ b/package/pcmciautils/Config.in
> @@ -0,0 +1,40 @@
> +config BR2_PACKAGE_PCMCIAUTILS
> + bool "pcmciautils"
> + depends on BR2_PACKAGE_LIBSYSFS && BR2_PACKAGE_UDEV || BR2_PACKAGE_LIBSYSFS && BR2_PACKAGE_HOTPLUG
> + help
> + Set of tools needed to use PC-card slots usually found in laptops
There are indentation issues here. The indentation rules :
* Nothing before the "config"
* One tab before all sub-specifiers such as "bool", "depends",
"select" and "help"
* One tab + two spaces before each line of the help text.
Regarding the dependencies :
* We usually use a "select" type of dependency for libraries. So you
could "select BR2_PACKAGE_LIBSYSFS"
* Hotplug is deprecated, so I'm not sure it's worth supporting it.
* It's usual to add a comment when something can't be selected due to
a missing dependency.
So you could have :
config BR2_PACKAGE_PCMCIAUTILS
select BR2_PACKAGE_LIBSYSFS
depends on BR2_PACKAGE_UDEV
comment "pcmciautils requires udev"
depends on !BR2_PACKAGE_UDEV
> +if BR2_PACKAGE_PCMCIAUTILS
> +
> +config BR2_PACKAGE_PCMCIAUTILS_STARTUP
> + bool "Build socket-startup script"
> + default y
> + help
> + Enable this if you need the socket-startup script
> +
> + You don't need it if the socket driver does not select
> + PCCARD_NONSTATIC -- that is the case for many embedded systems --
> + and for yenta_socket if the cardbus bridge is either below a
> + PCI-PCI bridge, or where the PCI bus is not equivalent to the host
> + bus (e.g. on PPC)
Not sure to understand this help text, but probably it's because I'm
not familiar with pcmcia support.
> +choice
> + prompt "pcmciautils invocation system"
> + default BR2_PACKAGE_PCMCIAUTILS_HOTPLUG
> + help
> + Select which system to use to invoke the necessary pcmciautils commands.
> +
> + config BR2_PACKAGE_PCMCIAUTILS_HOTPLUG
> + bool "linux hotplug"
> +
> + config BR2_PACKAGE_PCMCIAUTILS_UDEV
> + bool "udev"
> +endchoice
As per the suggestion above, I'd get rid of the "hotplug" thing.
Do you have any idea on whether pcmciautils can work on top of mdev
(the light Busybox reimplementation of udev) ?
> +config BR2_PACKAGE_PCMCIAUTILS_STATIC
> + bool "Static build"
> + default y
> + help
> + Enable this if you want to statically link the binaries
> + to be compiled.
It's not usual for packages to have such options. There's a global
option BR2_PREFER_STATIC that can be used instead, even though it's
usage is not very widespread and therefore fairly broken.
> +# pcmciautils also depends on module-init-tool (according to
> +# their manual, but that package might also be provided by busybox.
> +# Not really shure if it's really necessary to list module-init-tools
> +# as a dependency for pcmciautils though.
> +#ifeq ($(BR2_PACKAGE_MODULE_INIT_TOOLS),y)
> +# PCMCIAUTILS_DEPENDENCIES += module-init-tools
> +#endif
pcmciautils does not need module-init-tools at build time, it's only
the udev/hotplug rules that need modprobe to load the appropriate
kernel module automatically.
The insmod/rmmod/lsmod/modprobe commands are part of our default
Busybox configuration file, so I think we can safely assume that those
will be present on the target. We may improve this later if we want to
properly support building target systems without Busybox, but I think
many of our packages are broken with regard to this, so let's not make
the rules more complicated for this package than for all the other we
already have.
> +define PCMCIAUTILS_BUILD_CMDS
> + $(MAKE) CC="$(TARGET_CC)" LD="$(TARGET_CC)" -C "$(@D)" \
> + STARTUP=$(BR2_PACKAGE_PCMCIAUTILS_BUILD_STARTUP) \
> + UDEV=$(BR2_PACKAGE_PCMCIAUTILS_BUILD_UDEV) \
> + STATIC=$(BR2_PACKAGE_PCMCIAUTILS_BUILD_STATIC) \
> + DESTDIR="$(TARGET_DIR)" \
> + KERNEL_DIR="$(BUILD_DIR)/linux-$(LINUX26_VERSION)" \
Any idea why KERNEL_DIR is needed ? It's indeed defined in their main
Makefile, but doesn't seem to be used anywhere. Because if pcmciautils
really needs to have access to the kernel sources, then you need to add
a dependency on linux26, otherwise you have no guarantees that
$(BUILD_DIR)/linux-$(LINUX26_VERSION) will contain something.
> + HOSTCC="$(HOSTCC)" \
> + V="true"
> +endef
> +
> +define PCMCIAUTILS_INSTALL_TARGET_CMDS
> + $(MAKE) CC="$(TARGET_CC)" LD="$(TARGET_CC)" -C "$(@D)" \
> + DESTDIR="$(TARGET_DIR)" \
> + INSTALL="$(INSTALL)" \
> + INSTALL_PROGRAM="$(INSTALL)" \
> + install
> +# Buildroot seems to remove /usr/share/man already.
> +# $(MAKE) CC="$(TARGET_CC)" LD="$(TARGET_CC)" -C "$(@D)" \
> +# DESTDIR="$(TARGET_DIR)" \
> +# INSTALL="$(INSTALL)" \
> +# INSTALL_PROGRAM="$(INSTALL)" \
> +# uninstall-man
Yes, manpages are already removed globally by Buildroot in the
top-level Makefile, unless BR2_HAVE_DOCUMENTATION is enabled (and by
default this option is not set). So there's no need to do this
uninstallation of manpages directly in your package .mk file.
Thanks again for this contribution!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH 1/3] libgtk2: bump to version 2.20.1 and mark Gtk/DirectFB as broken
From: Thomas Petazzoni @ 2010-09-29 6:29 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1285716520.27944.304.camel@coalu.atr>
On Wed, 29 Sep 2010 01:28:40 +0200
Lionel Landwerlin <llandwerlin@gmail.com> wrote:
> Gtk+ 2.22 has been released early this week, it brings back
> compiling/quite-good-working DirectFB backend.
>
> Would you consider bumping to 2.22 ?
Argh, I checked http://www.gtk.org/download-linux.html yesterday, and
it still advertise Gtk 2.20 and Glib 2.24.
I will bump those versions, yes, and mark the DirectFB support as
working again.
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH 2/3] libglib2: bump version to 2.24.2
From: Lionel Landwerlin @ 2010-09-28 23:29 UTC (permalink / raw)
To: buildroot
In-Reply-To: <4521f45c3a8a87d3cdbbc774dfbb935b58e587e8.1285711883.git.thomas.petazzoni@free-electrons.com>
Just for information, Glib 2.26 has been released 2 days ago.
Le mercredi 29 septembre 2010 ? 00:12 +0200, Thomas Petazzoni a ?crit :
> This is a mechanical bump, no other changes involved.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> package/libglib2/libglib2.mk | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/package/libglib2/libglib2.mk b/package/libglib2/libglib2.mk
> index 61e8c1c..e45e89c 100644
> --- a/package/libglib2/libglib2.mk
> +++ b/package/libglib2/libglib2.mk
> @@ -4,7 +4,7 @@
> #
> #############################################################
> LIBGLIB2_VERSION_MAJOR = 2.24
> -LIBGLIB2_VERSION_MINOR = 1
> +LIBGLIB2_VERSION_MINOR = 2
> LIBGLIB2_VERSION = $(LIBGLIB2_VERSION_MAJOR).$(LIBGLIB2_VERSION_MINOR)
> LIBGLIB2_SOURCE = glib-$(LIBGLIB2_VERSION).tar.bz2
> LIBGLIB2_SITE = http://ftp.gnome.org/pub/gnome/sources/glib/$(LIBGLIB2_VERSION_MAJOR)
^ permalink raw reply
* [Buildroot] [PATCH 1/3] libgtk2: bump to version 2.20.1 and mark Gtk/DirectFB as broken
From: Lionel Landwerlin @ 2010-09-28 23:28 UTC (permalink / raw)
To: buildroot
In-Reply-To: <ca402fe6cbeeefeb15711d9e7f2390fab54c17b8.1285711883.git.thomas.petazzoni@free-electrons.com>
Gtk+ 2.22 has been released early this week, it brings back
compiling/quite-good-working DirectFB backend.
Would you consider bumping to 2.22 ?
Le mercredi 29 septembre 2010 ? 00:12 +0200, Thomas Petazzoni a ?crit :
> Finally, we bump Gtk from the old and ancient 2.12 version to the
> latest 2.20.1 version currently available.
>
> As noted in the 2010.08 release, the DirectFB back-end is broken in
> Gtk, so libgtk2 cannot be selected anymore with the DirectFB
> back-end. For the moment, we keep the Gtk/DirectFB code around, as
> it's possible that a fixed DirectFB back-end will be part of Gtk 2.22.
>
> In addition to this, we :
>
> * Upgrade the "reduce-dependencies" patch
>
> * Remove the "configure" and "no-tests" patches which do not seem to
> be useful anymore
>
> * Add a libtool patch
>
> We also remove references to a non-existant 2.15 gtk version in
> libgtk2.mk.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> package/libgtk2/Config.in | 12 +-
> ... host-libgtk2-2.20.1-reduce-dependencies.patch} | 123 ++++------
> package/libgtk2/libgtk2-2.12.6-configure.patch | 256 --------------------
> package/libgtk2/libgtk2-2.12.6-no-tests.patch | 11 -
> package/libgtk2/libgtk2-2.20.1-libtool.patch | 60 +++++
> package/libgtk2/libgtk2.mk | 14 +-
> 6 files changed, 118 insertions(+), 358 deletions(-)
> rename package/libgtk2/{host-libgtk2-2.12.12-reduce-dependencies.patch => host-libgtk2-2.20.1-reduce-dependencies.patch} (58%)
> delete mode 100644 package/libgtk2/libgtk2-2.12.6-configure.patch
> delete mode 100644 package/libgtk2/libgtk2-2.12.6-no-tests.patch
> create mode 100644 package/libgtk2/libgtk2-2.20.1-libtool.patch
>
> diff --git a/package/libgtk2/Config.in b/package/libgtk2/Config.in
> index bc4ca9d..d578f33 100644
> --- a/package/libgtk2/Config.in
> +++ b/package/libgtk2/Config.in
> @@ -4,14 +4,14 @@ config BR2_PACKAGE_LIBGTK2
> select BR2_PACKAGE_CAIRO
> select BR2_PACKAGE_CAIRO_PS
> select BR2_PACKAGE_CAIRO_PDF
> + select BR2_PACKAGE_CAIRO_SVG
> select BR2_PACKAGE_LIBGLIB2
> select BR2_PACKAGE_PANGO
> - # libgtk2 on DirectFB is deprecated because it is no longer
> - # supported in recent versions of Gtk. We will remove support
> - # for Gtk over DirectFB in the next Buildroot version unless
> - # support for DirectFB in mainline Gtk is improved in the mean
> - # time.
> - depends on BR2_PACKAGE_XORG7||(BR2_PACKAGE_DIRECTFB && BR2_DEPRECATED)
> + # libgtk2 on DirectFB is broken because it is no longer
> + # supported in recent versions of Gtk. However, as it is
> + # likely that support for DirectFB will be re-added in Gtk
> + # 2.22, we are keeping this around until Gtk 2.22 is released.
> + depends on BR2_PACKAGE_XORG7||(BR2_PACKAGE_DIRECTFB && BR2_BROKEN)
> depends on BR2_USE_WCHAR # glib2
> depends on BR2_INSTALL_LIBSTDCPP # pango
> help
> diff --git a/package/libgtk2/host-libgtk2-2.12.12-reduce-dependencies.patch b/package/libgtk2/host-libgtk2-2.20.1-reduce-dependencies.patch
> similarity index 58%
> rename from package/libgtk2/host-libgtk2-2.12.12-reduce-dependencies.patch
> rename to package/libgtk2/host-libgtk2-2.20.1-reduce-dependencies.patch
> index f0ac6bf..7e463a9 100644
> --- a/package/libgtk2/host-libgtk2-2.12.12-reduce-dependencies.patch
> +++ b/package/libgtk2/host-libgtk2-2.20.1-reduce-dependencies.patch
> @@ -1,18 +1,18 @@
> -Index: gtk+-2.12.12/configure.in
> +Hack the configure.in file to add a "none" gdktarget which removes
> +dependencies on graphic backends such as X.org or DirectFB. Gtk does
> +not fully build in this mode, but it builds sufficiently to build the
> +host tools that are needed to build the target Gtk.
> +
> +Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> +---
> + configure.in | 101 ++---------------------------------------------------------
> + 1 file changed, 5 insertions(+), 96 deletions(-)
> +
> +Index: gtk+-2.20.1/configure.in
> ===================================================================
> ---- gtk+-2.12.12.orig/configure.in 2008-09-13 02:01:07.000000000 +0200
> -+++ gtk+-2.12.12/configure.in 2010-02-21 10:42:40.000000000 +0100
> -@@ -32,9 +32,6 @@
> -
> - # required versions of other packages
> - m4_define([glib_required_version], [2.13.5])
> --m4_define([pango_required_version], [1.17.3])
> --m4_define([atk_required_version], [1.9.0])
> --m4_define([cairo_required_version], [1.2.0])
> -
> -
> - AC_INIT([gtk+], [gtk_version],
> -@@ -239,12 +236,12 @@
> +--- gtk+-2.20.1.orig/configure.in
> ++++ gtk+-2.20.1/configure.in
> +@@ -270,12 +270,12 @@
> gdktarget=x11
> fi
>
> @@ -27,7 +27,7 @@ Index: gtk+-2.12.12/configure.in
> *) AC_MSG_ERROR([Invalid target for GDK: use x11, quartz, directfb or win32.]);;
> esac
>
> -@@ -349,10 +346,7 @@
> +@@ -384,10 +384,7 @@
> ## the version requirements since those make the module lists
> ## annoying to construct
> PKG_CHECK_MODULES(BASE_DEPENDENCIES,
> @@ -37,54 +37,21 @@ Index: gtk+-2.12.12/configure.in
> - cairo >= cairo_required_version])
> + [glib-2.0 >= glib_required_version])
>
> + ## In addition to checking that cairo is present, we also need to
> + ## check that the correct cairo backend is there. E.g. if the GDK
> +@@ -399,8 +396,6 @@
> + if test "x$cairo_backend" = "xx11"; then
> + cairo_backend=xlib
> + fi
> +-PKG_CHECK_MODULES(CAIRO_BACKEND,
> +- [cairo-$cairo_backend >= cairo_required_version])
> +
> if test "$os_win32" != yes; then
> # libtool option to control which symbols are exported
> -@@ -1061,7 +1055,7 @@
> - GDK_PIXBUF_XLIB_EXTRA_CFLAGS=
> - GDK_PIXBUF_XLIB_EXTRA_LIBS=
> -
> --X_PACKAGES=fontconfig
> -+X_PACKAGES=
> - GDK_EXTRA_LIBS="$GDK_WLIBS"
> - GDK_EXTRA_CFLAGS=
> -
> -@@ -1070,14 +1064,6 @@
> - GTK_DEP_LIBS_FOR_X=
> -
> - if test "x$gdktarget" = "xx11"; then
> -- #
> -- # We use fontconfig very peripherally when decoding the default
> -- # settings.
> -- #
> -- if $PKG_CONFIG --exists fontconfig; then : ; else
> -- AC_MSG_ERROR([
> --*** fontconfig (http://www.fontconfig.org) is required by the X11 backend.])
> -- fi
> -
> - #
> - # Check for basic X packages; we use pkg-config if available
> -@@ -1124,16 +1110,6 @@
> - gtk_save_LIBS=$LIBS
> - LIBS="$x_libs_for_checks $LIBS"
> -
> -- # Sanity check for the X11 and Xext libraries. While everything we need from
> -- # Xext is optional, the chances a system has *none* of these things is so
> -- # small that we just unconditionally require it.
> -- AC_CHECK_FUNC(XOpenDisplay, :,
> -- AC_MSG_ERROR([*** libX11 not found. Check 'config.log' for more details.]))
> -- AC_CHECK_FUNC(XextFindDisplay, :,
> -- AC_MSG_ERROR([*** libXext not found. Check 'config.log' for more details.]))
> -- AC_CHECK_FUNC(XRenderQueryExtension, :,
> -- AC_MSG_ERROR([*** libXrender not found. Check 'config.log' for more details.]))
> --
> - # Check for xReply
> -
> - AC_MSG_CHECKING([if <X11/extensions/XIproto.h> is needed for xReply])
> -@@ -1418,48 +1394,6 @@
> - AM_CONDITIONAL(USE_DIRECTFB, false)
> +@@ -1682,50 +1677,6 @@
> fi
>
> --
> +
> -# Check for Pango flags
> -
> -if test "x$gdktarget" = "xwin32"; then
> @@ -122,14 +89,17 @@ Index: gtk+-2.12.12/configure.in
> -CFLAGS="$saved_cflags"
> -LDFLAGS="$saved_ldflags"
> -
> --GDK_PACKAGES="$PANGO_PACKAGES"
> +-# Pull in gio-unix for GDesktopAppInfo usage, see at least gdkapplaunchcontext-x11.c
> -if test "x$gdktarget" = "xx11"; then
> -- GDK_PACKAGES="$GDK_PACKAGES $X_PACKAGES"
> +- GDK_PACKAGES="$PANGO_PACKAGES gio-unix-2.0 $X_PACKAGES cairo-$cairo_backend"
> +-else
> +- GDK_PACKAGES="$PANGO_PACKAGES $X_PACKAGES cairo-$cairo_backend"
> -fi
> +-
> GDK_DEP_LIBS="$GDK_EXTRA_LIBS `$PKG_CONFIG --libs $GDK_PIXBUF_PACKAGES $GDK_PACKAGES` $GDK_PIXBUF_EXTRA_LIBS"
> GDK_DEP_CFLAGS="`$PKG_CONFIG --cflags gthread-2.0 $GDK_PIXBUF_PACKAGES $GDK_PACKAGES` $GDK_PIXBUF_EXTRA_CFLAGS $GDK_EXTRA_CFLAGS"
> -
> -@@ -1468,7 +1402,7 @@
> + #
> +@@ -1733,7 +1684,7 @@
> # into the pkg-config files
> #
> if test $enable_explicit_deps != yes ; then
> @@ -138,14 +108,14 @@ Index: gtk+-2.12.12/configure.in
> GDK_EXTRA_LIBS=
> fi
>
> -@@ -1479,39 +1413,10 @@
> +@@ -1744,36 +1695,8 @@
> AC_SUBST(GDK_DEP_CFLAGS)
>
>
> -########################################
> -# Check for Accessibility Toolkit flags
> -########################################
> --
> +
> -ATK_PACKAGES=atk
> -AC_MSG_CHECKING(ATK flags)
> -if $PKG_CONFIG --exists $ATK_PACKAGES ; then
> @@ -171,20 +141,15 @@ Index: gtk+-2.12.12/configure.in
> - LIBS="$gtk_save_LIBS"
> -fi
> -
> --GTK_PACKAGES="atk cairo"
> +-GTK_PACKAGES="atk cairo gio-2.0"
> +GTK_PACKAGES=
> - GTK_EXTRA_LIBS=
> - GTK_EXTRA_CFLAGS=
> --GTK_DEP_LIBS="$GDK_EXTRA_LIBS $GTK_DEP_LIBS_FOR_X `$PKG_CONFIG --libs $GDK_PIXBUF_PACKAGES $PANGO_PACKAGES $GTK_PACKAGES_FOR_X $GTK_PACKAGES` $GTK_EXTRA_LIBS $GDK_PIXBUF_EXTRA_LIBS"
> -+GTK_DEP_LIBS="$GDK_EXTRA_LIBS $GTK_DEP_LIBS_FOR_X `$PKG_CONFIG --libs $GDK_PIXBUF_PACKAGES $GTK_PACKAGES_FOR_X $GTK_PACKAGES` $GTK_EXTRA_LIBS $GDK_PIXBUF_EXTRA_LIBS"
> - GTK_DEP_CFLAGS="`$PKG_CONFIG --cflags gthread-2.0 $GDK_PIXBUF_PACKAGES $GDK_PACKAGES $GTK_PACKAGES` $GDK_PIXBUF_EXTRA_CFLAGS $GDK_EXTRA_CFLAGS $GTK_EXTRA_CFLAGS"
> -
> - if test x"$os_win32" = xyes; then
> -@@ -1601,17 +1506,6 @@
> -
> + if test "x$gdktarget" = "xx11"; then
> + GTK_PACKAGES="$GTK_PACKAGES pangoft2"
> + fi
> +@@ -1936,20 +1859,6 @@
> gtk_save_cppflags="$CPPFLAGS"
> - CPPFLAGS="$CPPFLAGS $GTK_DEP_CFLAGS"
> --
> + CPPFLAGS="$CPPFLAGS $GTK_DEP_CFLAGS $GDK_DEP_CFLAGS"
> +
> -AC_CHECK_HEADER(cairo-pdf.h,,AC_MSG_ERROR([
> -*** Can't find cairo-pdf.h. You must build Cairo with the pdf
> -*** backend enabled.]))
> @@ -193,6 +158,10 @@ Index: gtk+-2.12.12/configure.in
> - AC_CHECK_HEADER(cairo-ps.h,,AC_MSG_ERROR([
> -*** Can't find cairo-ps.h. You must build Cairo with the
> -*** postscript backend enabled.]))
> +-
> +- AC_CHECK_HEADER(cairo-svg.h,,AC_MSG_ERROR([
> +-*** Can't find cairo-svg.h. You must build Cairo with the
> +-*** svg backend enabled.]))
> -fi
> -
> CPPFLAGS="$gtk_save_cppflags"
> diff --git a/package/libgtk2/libgtk2-2.12.6-configure.patch b/package/libgtk2/libgtk2-2.12.6-configure.patch
> deleted file mode 100644
> index ea60d2d..0000000
> --- a/package/libgtk2/libgtk2-2.12.6-configure.patch
> +++ /dev/null
> @@ -1,256 +0,0 @@
> -diff -urN libgtk2-2.12.6-0rig/configure libgtk2-2.12.6/configure
> ---- libgtk2-2.12.6-0rig/configure 2008-01-29 04:38:14.000000000 +0100
> -+++ libgtk2-2.12.6/configure 2008-07-08 10:54:39.000000000 +0200
> -@@ -5094,7 +5094,7 @@
> - ;;
> -
> - # This must be Linux ELF.
> --linux* | k*bsd*-gnu)
> -+*-linux-gnu | linux* | k*bsd*-gnu)
> - lt_cv_deplibs_check_method=pass_all
> - ;;
> -
> -@@ -6973,7 +6973,7 @@
> - lt_cv_sys_global_symbol_to_cdecl="sed -n -e 's/^T .* \(.*\)$/extern int \1();/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'"
> - lt_cv_sys_global_symbol_to_c_name_address="sed -n -e 's/^: \([^ ]*\) $/ {\\\"\1\\\", (lt_ptr) 0},/p' -e 's/^$symcode* \([^ ]*\) \([^ ]*\)$/ {\"\2\", (lt_ptr) \&\2},/p'"
> - ;;
> --linux* | k*bsd*-gnu)
> -+*-linux-gnu | linux* | k*bsd*-gnu)
> - if test "$host_cpu" = ia64; then
> - symcode='[ABCDGIRSTW]'
> - lt_cv_sys_global_symbol_to_cdecl="sed -n -e 's/^T .* \(.*\)$/extern int \1();/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'"
> -@@ -7943,7 +7943,7 @@
> - lt_prog_compiler_static='-Bstatic'
> - ;;
> -
> -- linux* | k*bsd*-gnu)
> -+ *-linux-gnu | linux* | k*bsd*-gnu)
> - case $cc_basename in
> - icc* | ecc*)
> - lt_prog_compiler_wl='-Wl,'
> -@@ -8402,7 +8402,7 @@
> - archive_expsym_cmds='sed "s,^,_," $export_symbols >$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
> - ;;
> -
> -- gnu* | linux* | k*bsd*-gnu)
> -+ *-linux-gnu | gnu* | linux* | k*bsd*-gnu)
> - if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
> - tmp_addflag=
> - case $cc_basename,$host_cpu in
> -@@ -9336,6 +9336,7 @@
> - if (lt_freq[lt_foo] == 1) { print lt_foo; }
> - }'`
> - sys_lib_search_path_spec=`echo $lt_search_path_spec`
> -+
> - else
> - sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"
> - fi
> -@@ -9667,8 +9668,9 @@
> - dynamic_linker=no
> - ;;
> -
> -+
> - # This must be Linux ELF.
> --linux* | k*bsd*-gnu)
> -+*-linux-gnu | linux* | k*bsd*-gnu)
> - version_type=linux
> - need_lib_prefix=no
> - need_version=no
> -@@ -9681,8 +9683,22 @@
> - # Some rework will be needed to allow for fast_install
> - # before this can be enabled.
> - hardcode_into_libs=yes
> -- sys_lib_search_path_spec="/usr/lib${libsuff} /lib${libsuff} /usr/local/lib${libsuff}"
> -- sys_lib_dlsearch_path_spec="/usr/lib${libsuff} /lib${libsuff}"
> -+ # sys_lib_dlsearch_path_spec="/usr/lib${libsuff} /lib${libsuff}"
> -+ # Buildroot: New sys_lib_search_path_spec taken from atk!
> -+if test "$GCC" = yes; then
> -+ sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" | $SED -e "s/^libraries://" -e "s,=/,/,g"`
> -+ if echo "$sys_lib_search_path_spec" | grep ';' >/dev/null ; then
> -+ # if the path contains ";" then we assume it to be the separator
> -+ # otherwise default to the standard path separator (i.e. ":") - it is
> -+ # assumed that no part of a normal pathname contains ";" but that should
> -+ # okay in the real world where ";" in dirpaths is itself problematic.
> -+ sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | $SED -e 's/;/ /g'`
> -+ else
> -+ sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | $SED -e "s/$PATH_SEPARATOR/ /g"`
> -+ fi
> -+else
> -+ sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"
> -+fi
> -
> - # Append ld.so.conf contents to the search path
> - if test -f /etc/ld.so.conf; then
> -@@ -10780,6 +10796,7 @@
> - # Now quote all the things that may contain metacharacters while being
> - # careful not to overquote the AC_SUBSTed values. We take copies of the
> - # variables and quote the copies for generation of the libtool script.
> -+
> - for var in echo old_CC old_CFLAGS AR AR_FLAGS EGREP RANLIB LN_S LTCC LTCFLAGS NM \
> - SED SHELL STRIP \
> - libname_spec library_names_spec soname_spec extract_expsyms_cmds \
> -@@ -12109,7 +12126,7 @@
> - hardcode_libdir_flag_spec_CXX='${wl}-rpath ${wl}$libdir'
> - hardcode_libdir_separator_CXX=:
> - ;;
> -- linux* | k*bsd*-gnu)
> -+ *-linux-gnu | linux* | k*bsd*-gnu)
> - case $cc_basename in
> - KCC*)
> - # Kuck and Associates, Inc. (KAI) C++ Compiler
> -@@ -12680,7 +12697,7 @@
> - postdeps_CXX=
> - ;;
> -
> --linux*)
> -+*-linux-gnu | linux*)
> - case `$CC -V 2>&1 | sed 5q` in
> - *Sun\ C*)
> - # Sun C++ 5.9
> -@@ -12884,7 +12901,7 @@
> - ;;
> - esac
> - ;;
> -- linux* | k*bsd*-gnu)
> -+ *-linux-gnu | linux* | k*bsd*-gnu)
> - case $cc_basename in
> - KCC*)
> - # KAI C++ Compiler
> -@@ -13636,7 +13653,7 @@
> - ;;
> -
> - # This must be Linux ELF.
> --linux* | k*bsd*-gnu)
> -+*-linux-gnu | linux* | k*bsd*-gnu)
> - version_type=linux
> - need_lib_prefix=no
> - need_version=no
> -@@ -13649,7 +13666,24 @@
> - # Some rework will be needed to allow for fast_install
> - # before this can be enabled.
> - hardcode_into_libs=yes
> -- sys_lib_search_path_spec="/usr/lib${libsuff} /lib${libsuff} /usr/local/lib${libsuff}"
> -+
> -+ # sys_lib_search_path_spec="/usr/lib${libsuff} /lib${libsuff} /usr/local/lib${libsuff}"
> -+ # Buildroot: New sys_lib_search_path_spec taken from atk!
> -+if test "$GCC" = yes; then
> -+ sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" | $SED -e "s/^libraries://" -e "s,=/,/,g"`
> -+ if echo "$sys_lib_search_path_spec" | grep ';' >/dev/null ; then
> -+ # if the path contains ";" then we assume it to be the separator
> -+ # otherwise default to the standard path separator (i.e. ":") - it is
> -+ # assumed that no part of a normal pathname contains ";" but that should
> -+ # okay in the real world where ";" in dirpaths is itself problematic.
> -+ sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | $SED -e 's/;/ /g'`
> -+ else
> -+ sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | $SED -e "s/$PATH_SEPARATOR/ /g"`
> -+ fi
> -+else
> -+ sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"
> -+fi
> -+
> - sys_lib_dlsearch_path_spec="/usr/lib${libsuff} /lib${libsuff}"
> -
> - # Append ld.so.conf contents to the search path
> -@@ -14586,7 +14620,7 @@
> - lt_prog_compiler_static_F77='-Bstatic'
> - ;;
> -
> -- linux* | k*bsd*-gnu)
> -+ *-linux-gnu | linux* | k*bsd*-gnu)
> - case $cc_basename in
> - icc* | ecc*)
> - lt_prog_compiler_wl_F77='-Wl,'
> -@@ -15045,7 +15079,7 @@
> - archive_expsym_cmds_F77='sed "s,^,_," $export_symbols >$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
> - ;;
> -
> -- gnu* | linux* | k*bsd*-gnu)
> -+ gnu* | *-linux-gnu | linux* | k*bsd*-gnu)
> - if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
> - tmp_addflag=
> - case $cc_basename,$host_cpu in
> -@@ -16239,7 +16273,7 @@
> - ;;
> -
> - # This must be Linux ELF.
> --linux* | k*bsd*-gnu)
> -+*-linux-gnu | linux* | k*bsd*-gnu)
> - version_type=linux
> - need_lib_prefix=no
> - need_version=no
> -@@ -16252,7 +16286,23 @@
> - # Some rework will be needed to allow for fast_install
> - # before this can be enabled.
> - hardcode_into_libs=yes
> -- sys_lib_search_path_spec="/usr/lib${libsuff} /lib${libsuff} /usr/local/lib${libsuff}"
> -+ # sys_lib_search_path_spec="/usr/lib${libsuff} /lib${libsuff} /usr/local/lib${libsuff}"
> -+ # Buildroot: New sys_lib_search_path_spec taken from atk!
> -+if test "$GCC" = yes; then
> -+ sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" | $SED -e "s/^libraries://" -e "s,=/,/,g"`
> -+ if echo "$sys_lib_search_path_spec" | grep ';' >/dev/null ; then
> -+ # if the path contains ";" then we assume it to be the separator
> -+ # otherwise default to the standard path separator (i.e. ":") - it is
> -+ # assumed that no part of a normal pathname contains ";" but that should
> -+ # okay in the real world where ";" in dirpaths is itself problematic.
> -+ sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | $SED -e 's/;/ /g'`
> -+ else
> -+ sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | $SED -e "s/$PATH_SEPARATOR/ /g"`
> -+ fi
> -+else
> -+ sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"
> -+fi
> -+
> - sys_lib_dlsearch_path_spec="/usr/lib${libsuff} /lib${libsuff}"
> -
> - # Append ld.so.conf contents to the search path
> -@@ -17169,7 +17219,7 @@
> - lt_prog_compiler_static_GCJ='-Bstatic'
> - ;;
> -
> -- linux* | k*bsd*-gnu)
> -+ *-linux-gnu | linux* | k*bsd*-gnu)
> - case $cc_basename in
> - icc* | ecc*)
> - lt_prog_compiler_wl_GCJ='-Wl,'
> -@@ -17628,7 +17678,7 @@
> - archive_expsym_cmds_GCJ='sed "s,^,_," $export_symbols >$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
> - ;;
> -
> -- gnu* | linux* | k*bsd*-gnu)
> -+ gnu* | *-linux-gnu | linux* | k*bsd*-gnu)
> - if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
> - tmp_addflag=
> - case $cc_basename,$host_cpu in
> -@@ -18842,7 +18892,7 @@
> - ;;
> -
> - # This must be Linux ELF.
> --linux* | k*bsd*-gnu)
> -+*-linux-gnu | linux* | k*bsd*-gnu)
> - version_type=linux
> - need_lib_prefix=no
> - need_version=no
> -@@ -18855,7 +18905,22 @@
> - # Some rework will be needed to allow for fast_install
> - # before this can be enabled.
> - hardcode_into_libs=yes
> -- sys_lib_search_path_spec="/usr/lib${libsuff} /lib${libsuff} /usr/local/lib${libsuff}"
> -+ #sys_lib_search_path_spec="/usr/lib${libsuff} /lib${libsuff} /usr/local/lib${libsuff}"
> -+ # Buildroot: New sys_lib_search_path_spec taken from atk!
> -+if test "$GCC" = yes; then
> -+ sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" | $SED -e "s/^libraries://" -e "s,=/,/,g"`
> -+ if echo "$sys_lib_search_path_spec" | grep ';' >/dev/null ; then
> -+ # if the path contains ";" then we assume it to be the separator
> -+ # otherwise default to the standard path separator (i.e. ":") - it is
> -+ # assumed that no part of a normal pathname contains ";" but that should
> -+ # okay in the real world where ";" in dirpaths is itself problematic.
> -+ sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | $SED -e 's/;/ /g'`
> -+ else
> -+ sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | $SED -e "s/$PATH_SEPARATOR/ /g"`
> -+ fi
> -+else
> -+ sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"
> -+fi
> - sys_lib_dlsearch_path_spec="/usr/lib${libsuff} /lib${libsuff}"
> -
> - # Append ld.so.conf contents to the search path
> diff --git a/package/libgtk2/libgtk2-2.12.6-no-tests.patch b/package/libgtk2/libgtk2-2.12.6-no-tests.patch
> deleted file mode 100644
> index ea92433..0000000
> --- a/package/libgtk2/libgtk2-2.12.6-no-tests.patch
> +++ /dev/null
> @@ -1,11 +0,0 @@
> ---- a/Makefile.in 2008-01-28 22:38:09.000000000 -0500
> -+++ b/Makefile.in 2008-02-11 12:52:45.000000000 -0500
> -@@ -330,7 +330,7 @@ sharedstatedir = @sharedstatedir@
> - sysconfdir = @sysconfdir@
> - target_alias = @target_alias@
> -
> --SRC_SUBDIRS = gdk-pixbuf gdk gtk modules demos tests perf contrib
> -+SRC_SUBDIRS = gdk-pixbuf gdk gtk modules demos perf contrib
> - SUBDIRS = po po-properties $(SRC_SUBDIRS) docs m4macros
> -
> - # require automake 1.4
> diff --git a/package/libgtk2/libgtk2-2.20.1-libtool.patch b/package/libgtk2/libgtk2-2.20.1-libtool.patch
> new file mode 100644
> index 0000000..12b69a4
> --- /dev/null
> +++ b/package/libgtk2/libgtk2-2.20.1-libtool.patch
> @@ -0,0 +1,60 @@
> +Fix the usual libtool-related problems, but since libgtk2 uses libtool
> +2.2, we need a specific patch.
> +
> +This is an exact copy of the patch proposed by Martin Banky.
> +
> +Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> +
> +--- a/ltmain.sh 2006-03-11 13:49:04.000000000 -0500
> ++++ b/ltmain.sh 2008-04-30 09:55:28.000000000 -0400
> +@@ -2239,8 +2239,11 @@ func_mode_install ()
> + # At present, this check doesn't affect windows .dll's that
> + # are installed into $libdir/../bin (currently, that works fine)
> + # but it's something to keep an eye on.
> +- test "$inst_prefix_dir" = "$destdir" && \
> +- func_fatal_error "error: cannot install \`$file' to a directory not ending in $libdir"
> ++ #
> ++ # This breaks install into our staging area. -PB
> ++ #
> ++ # test "$inst_prefix_dir" = "$destdir" && \
> ++ # func_fatal_error "error: cannot install \`$file' to a directory not ending in $libdir"
> +
> + if test -n "$inst_prefix_dir"; then
> + # Stick the inst_prefix_dir data into the link command.
> +@@ -5739,8 +5742,14 @@ func_mode_link ()
> + absdir="$abs_ladir"
> + libdir="$abs_ladir"
> + else
> +- dir="$libdir"
> +- absdir="$libdir"
> ++ # Adding 'libdir' from the .la file to our library search paths
> ++ # breaks crosscompilation horribly. We cheat here and don't add
> ++ # it, instead adding the path where we found the .la. -CL
> ++ dir="$abs_ladir"
> ++ absdir="$abs_ladir"
> ++ libdir="$abs_ladir"
> ++ #dir="$libdir"
> ++ #absdir="$libdir"
> + fi
> + test "X$hardcode_automatic" = Xyes && avoidtemprpath=yes
> + else
> +@@ -5891,7 +5900,7 @@ func_mode_link ()
> + *)
> + if test "$installed" = no; then
> + notinst_deplibs="$notinst_deplibs $lib"
> +- need_relink=yes
> ++ need_relink=no
> + fi
> + ;;
> + esac
> +@@ -8373,6 +8382,10 @@ func_mode_link ()
> + # Replace all uninstalled libtool libraries with the installed ones
> + newdependency_libs=
> + for deplib in $dependency_libs; do
> ++ # Replacing uninstalled with installed can easily break crosscompilation,
> ++ # since the installed path is generally the wrong architecture. -CL
> ++ newdependency_libs="$newdependency_libs $deplib"
> ++ continue
> + case $deplib in
> + *.la)
> + func_basename "$deplib"
> diff --git a/package/libgtk2/libgtk2.mk b/package/libgtk2/libgtk2.mk
> index d669622..a2321d1 100644
> --- a/package/libgtk2/libgtk2.mk
> +++ b/package/libgtk2/libgtk2.mk
> @@ -3,8 +3,8 @@
> # libgtk2.0
> #
> #############################################################
> -LIBGTK2_VERSION_MAJOR:=2.12
> -LIBGTK2_VERSION_MINOR:=12
> +LIBGTK2_VERSION_MAJOR:=2.20
> +LIBGTK2_VERSION_MINOR:=1
> LIBGTK2_VERSION = $(LIBGTK2_VERSION_MAJOR).$(LIBGTK2_VERSION_MINOR)
>
> LIBGTK2_SOURCE = gtk+-$(LIBGTK2_VERSION).tar.bz2
> @@ -12,6 +12,7 @@ LIBGTK2_SITE = ftp://ftp.gtk.org/pub/gtk/$(LIBGTK2_VERSION_MAJOR)
> LIBGTK2_AUTORECONF = NO
> LIBGTK2_INSTALL_STAGING = YES
> LIBGTK2_INSTALL_TARGET = YES
> +LIBGTK2_LIBTOOL_PATCH = NO
>
> LIBGTK2_CONF_ENV = ac_cv_func_posix_getpwuid_r=yes glib_cv_stack_grows=no \
> glib_cv_uscore=no \
> @@ -64,7 +65,8 @@ LIBGTK2_CONF_ENV = ac_cv_func_posix_getpwuid_r=yes glib_cv_stack_grows=no \
> ac_cv_path_GTK_UPDATE_ICON_CACHE=$(HOST_DIR)/usr/bin/gtk-update-icon-cache \
> ac_cv_path_GDK_PIXBUF_CSOURCE=$(HOST_DIR)/usr/bin/gdk-pixbuf-csource \
> ac_cv_prog_F77=no \
> - ac_cv_path_CUPS_CONFIG=no
> + ac_cv_path_CUPS_CONFIG=no \
> + gio_can_sniff=no
>
> LIBGTK2_CONF_OPT = --enable-shared \
> --enable-static \
> @@ -90,11 +92,6 @@ else
> LIBGTK2_CONF_OPT += --without-x
> endif
>
> -# Buildroot does not support JPEG2000 library
> -ifeq ($(LIBGTK2_VERSION_MAJOR),2.15)
> -LIBGTK2_CONF_OPT += --without-libjasper
> -endif
> -
> ifeq ($(BR2_PACKAGE_LIBPNG),y)
> LIBGTK2_DEPENDENCIES += libpng
> else
> @@ -135,6 +132,7 @@ LIBGTK2_POST_INSTALL_TARGET_HOOKS += LIBGTK_POST_INSTALL_TWEAKS
>
> HOST_LIBGTK2_DEPENDENCIES = host-libglib2 host-libpng
> HOST_LIBGTK2_AUTORECONF = YES
> +HOST_LIBGTK2_LIBTOOL_PATCH = NO
> HOST_LIBGTK2_CONF_OPT = \
> --disable-static \
> --disable-glibtest \
^ permalink raw reply
* [Buildroot] Libtool work: a tentative summary
From: Lionel Landwerlin @ 2010-09-28 23:26 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20100928223652.6dc72083@surf>
Thanks a lot to Thomas, for having made this summary.
Le mardi 28 septembre 2010 ? 22:36 +0200, Thomas Petazzoni a ?crit :
>
> Drawbacks of this approach :
>
> *) We need to autoreconfigure *ALL* autotools-based packages. This may
> be an issue for two reasons: 1/ speed, 2/ packages for which
> autoreconfiguration does not work properly (yes those packages
> should be fixed, but anyway, this may add some work to us).
> Obviously, as packages will start using libtool 2.4 by default,
> this shouldn't be a problem, but we all know that it's going to
> take years before everybody moves to that newer libtool version.
To be correct, autoreconfigure would not apply to all autotools-based
packages, but just to autotools-based ones using libtool. For example,
the at package which uses autotools, wouldn't require to be
autoreconfigured to work properly.
I confess that packages using libtool represent the majority of the
packages, and surely the most complex ones to autoreconfigure.
Regards,
--
Lionel Landwerlin
^ permalink raw reply
* [Buildroot] [PATCH] Makefile: Force make to run serially in the top-level Makefile
From: Thomas Petazzoni @ 2010-09-28 22:27 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1285710658-17096-1-git-send-email-yann.morin.1998@anciens.enib.fr>
Hello,
On Tue, 28 Sep 2010 23:50:58 +0200
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> wrote:
> The top-level Makefile can be executed in parallel, as it causes problems.
> We can force make to be not parallel.
>
> It's been reported many times, and recent discussions on IRC with kos_tom,
> and user nick-named knee, led to this patch.
>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] pcmciautils: New package. Patch against current git attached
From: Patrik Dahlström @ 2010-09-28 22:19 UTC (permalink / raw)
To: buildroot
Hello,
I've made a patch to add pcmciautils to the list of packages in buildroot.
Please review and reply with comments and improvement
--
Yours sincerely
Patrik Dahlstr?m
"all animals except man know that the principal business of life is to enjoy
it!" --Samuel Butler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_pcmciautils.patch
Type: text/x-patch
Size: 4661 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20100929/e18481db/attachment.bin>
^ permalink raw reply
* [Buildroot] [PATCH 2/2] linux: fix uImage location on AVR32
From: Thomas Petazzoni @ 2010-09-28 22:15 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1285712084.git.thomas.petazzoni@free-electrons.com>
On most architectures, the kernel image can be found in
arch/<ARCH>/boot, but on AVR32, it's in arch/<ARCH>/boot/images.
Issue initially reported by Joachim Pihl
<joachim.pihl@sensordevelopments.com>.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
linux/linux.mk | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/linux/linux.mk b/linux/linux.mk
index 4490023..55dc2bf 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -42,7 +42,11 @@ else ifeq ($(BR2_LINUX_KERNEL_VMLINUX_BIN),y)
LINUX26_IMAGE_NAME=vmlinux.bin
endif
+ifeq ($(KERNEL_ARCH),avr32)
+LINUX26_IMAGE_PATH=$(LINUX26_DIR)/arch/$(KERNEL_ARCH)/boot/images/$(LINUX26_IMAGE_NAME)
+else
LINUX26_IMAGE_PATH=$(LINUX26_DIR)/arch/$(KERNEL_ARCH)/boot/$(LINUX26_IMAGE_NAME)
+endif
# Download
$(LINUX26_DIR)/.stamp_downloaded:
--
1.7.0.4
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] linux: restrict output image formats to the appropriate arches
From: Thomas Petazzoni @ 2010-09-28 22:15 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1285712084.git.thomas.petazzoni@free-electrons.com>
Some Linux kernel output image formats are available on some archs,
some not. For example 'uImage' is not supported on MIPS, so let's
prevent the user from making this selection.
Issue initially reported by Choi, David <David.Choi@Micrel.Com>.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
linux/Config.in | 10 ++++++----
linux/linux.mk | 2 +-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/linux/Config.in b/linux/Config.in
index a7109a5..1e015b7 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -111,20 +111,22 @@ config BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE
choice
prompt "Kernel binary format"
- default BR2_LINUX_KERNEL_UIMAGE if !BR2_i386 && !BR2_x86_64
- default BR2_LINUX_KERNEL_BZIMAGE if BR2_i386 || BR2_x86_64
config BR2_LINUX_KERNEL_UIMAGE
bool "uImage"
+ depends on BR2_arm || BR2_armeb || BR2_powerpc || BR2_avr32 || BR2_sh || BR2_sh64
config BR2_LINUX_KERNEL_BZIMAGE
bool "bzImage"
+ depends on BR2_i386 || BR2_x86_64
config BR2_LINUX_KERNEL_ZIMAGE
bool "zImage"
+ depends on BR2_arm || BR2_armeb || BR2_powerpc || BR2_sparc || BR2_sh || BR2_sh64 || BR2_xtensa
-config BR2_LINUX_KERNEL_VMLINUX
- bool "vmlinux"
+config BR2_LINUX_KERNEL_VMLINUX_BIN
+ bool "vmlinux.bin"
+ depends on BR2_mips || BR2_mipsel || BR2_sh || BR2_sh64
endchoice
diff --git a/linux/linux.mk b/linux/linux.mk
index aabecc1..4490023 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -38,7 +38,7 @@ else ifeq ($(BR2_LINUX_KERNEL_BZIMAGE),y)
LINUX26_IMAGE_NAME=bzImage
else ifeq ($(BR2_LINUX_KERNEL_ZIMAGE),y)
LINUX26_IMAGE_NAME=zImage
-else ifeq ($(BR2_LINUX_KERNEL_VMLINUX),y)
+else ifeq ($(BR2_LINUX_KERNEL_VMLINUX_BIN),y)
LINUX26_IMAGE_NAME=vmlinux.bin
endif
--
1.7.0.4
^ permalink raw reply related
* [Buildroot] [pull request] Pull request for branch for-2010.11/kernel-image-formats
From: Thomas Petazzoni @ 2010-09-28 22:15 UTC (permalink / raw)
To: buildroot
Hello,
Two relatively minor improvements to the kernel build infrastructure.
Thomas
The following changes since commit 3e5e39a8a25a4a085afe08bdcf46933c8d569ed7:
Peter Korsgaard (1):
barebox/u-boot/linux: don't error out on missing config when make source
are available in the git repository at:
git://git.busybox.net/~tpetazzoni/git/buildroot for-2010.11/kernel-image-formats
Thomas Petazzoni (2):
linux: restrict output image formats to the appropriate arches
linux: fix uImage location on AVR32
linux/Config.in | 10 ++++++----
linux/linux.mk | 6 +++++-
2 files changed, 11 insertions(+), 5 deletions(-)
Thanks,
--
Thomas Petazzoni
^ permalink raw reply
* [Buildroot] [PATCH 3/3] pango: bump version to 1.28.2
From: Thomas Petazzoni @ 2010-09-28 22:12 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1285711882.git.thomas.petazzoni@free-electrons.com>
This is a mechanical bump, no other changes involved.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/pango/pango.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/package/pango/pango.mk b/package/pango/pango.mk
index dc04b55..373eb8b 100644
--- a/package/pango/pango.mk
+++ b/package/pango/pango.mk
@@ -4,7 +4,7 @@
#
#############################################################
PANGO_VERSION_MAJOR = 1.28
-PANGO_VERSION_MINOR = 0
+PANGO_VERSION_MINOR = 2
PANGO_VERSION = $(PANGO_VERSION_MAJOR).$(PANGO_VERSION_MINOR)
PANGO_SOURCE = pango-$(PANGO_VERSION).tar.bz2
--
1.7.0.4
^ permalink raw reply related
* [Buildroot] [PATCH 2/3] libglib2: bump version to 2.24.2
From: Thomas Petazzoni @ 2010-09-28 22:12 UTC (permalink / raw)
To: buildroot
In-Reply-To: <cover.1285711882.git.thomas.petazzoni@free-electrons.com>
This is a mechanical bump, no other changes involved.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/libglib2/libglib2.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/package/libglib2/libglib2.mk b/package/libglib2/libglib2.mk
index 61e8c1c..e45e89c 100644
--- a/package/libglib2/libglib2.mk
+++ b/package/libglib2/libglib2.mk
@@ -4,7 +4,7 @@
#
#############################################################
LIBGLIB2_VERSION_MAJOR = 2.24
-LIBGLIB2_VERSION_MINOR = 1
+LIBGLIB2_VERSION_MINOR = 2
LIBGLIB2_VERSION = $(LIBGLIB2_VERSION_MAJOR).$(LIBGLIB2_VERSION_MINOR)
LIBGLIB2_SOURCE = glib-$(LIBGLIB2_VERSION).tar.bz2
LIBGLIB2_SITE = http://ftp.gnome.org/pub/gnome/sources/glib/$(LIBGLIB2_VERSION_MAJOR)
--
1.7.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox