* [Buildroot] [PATCH 09/33] linux-fusion: fix build
From: Peter Korsgaard @ 2012-11-30 0:34 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353543503-8952-10-git-send-email-s.martin49@gmail.com>
>>>>> "Samuel" == Samuel Martin <s.martin49@gmail.com> writes:
Samuel> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [git commit] linux-fusion: fix build
From: Peter Korsgaard @ 2012-11-30 0:33 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=ba66de55ffc6a331a69ceac42a065da2200f905e
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: Simon Dawson <spdawson@gmail.com>
Tested-by: Simon Dawson <spdawson@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
.../linux-fusion/linux-fusion-fix-include.patch | 52 ++++++++++++++++++++
1 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/package/linux-fusion/linux-fusion-fix-include.patch b/package/linux-fusion/linux-fusion-fix-include.patch
new file mode 100644
index 0000000..fe91488
--- /dev/null
+++ b/package/linux-fusion/linux-fusion-fix-include.patch
@@ -0,0 +1,52 @@
+Fix directfb-fusion kernel module build.
+
+This patch avoids the following error occurs:
+
+/usr/bin/make -f scripts/Makefile.build obj=/opt/br/output/build/linux-fusion-8.8.1/linux/drivers/char/fusion /opt/br/output/host/usr/bin/ccache
+ /opt/br/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -Wp,-MD,/opt/br/output/build/linux-fusion-8.8.1/linux/drivers/char/fusion/single/.fusioncore_impl.o.d
+ -nostdinc -isystem /opt/br/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/include -I/opt/br/output/build/linux-3.6/arch/arm/include
+ -Iarch/arm/include/generated -Iinclude -include /opt/br/output/build/linux-3.6/include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-versatile/include
+ -Iarch/arm/plat-versatile/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/opt/br/output/build/linux-fusion-8.8.1/linux/include -Wall -Wundef
+ -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -marm
+ -fno-dwarf2-cfi-asm -mabi=aapcs-linux -mno-thumb-interwork -funwind-tables -D__LINUX_ARM_ARCH__=5 -march=armv5te -mtune=arm9tdmi -msoft-float -Uarm -Wframe-larger-than=1024
+ -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DMODULE
+ -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(fusioncore_impl)" -D"KBUILD_MODNAME=KBUILD_STR(fusion)" -c -o
+/opt/br/output/build/linux-fusion-8.8.1/linux/drivers/char/fusion/single/fusioncore_impl.o /opt/br/output/build/linux-fusion-8.8.1/linux/drivers/char/fusion/single/fusioncore_impl.c
+/opt/br/output/build/linux-fusion-8.8.1/linux/drivers/char/fusion/single/fusioncore_impl.c:25:19: fatal error: debug.h: No such file or directory
+compilation terminated.
+make[3]: *** [/opt/br/output/build/linux-fusion-8.8.1/linux/drivers/char/fusion/single/fusioncore_impl.o] Error 1
+make[2]: *** [_module_/opt/br/output/build/linux-fusion-8.8.1/linux/drivers/char/fusion] Error 2
+make[2]: Leaving directory `/opt/br/output/build/linux-3.6'
+make[1]: *** [modules] Error 2
+make[1]: Leaving directory `/opt/br/output/build/linux-fusion-8.8.1'
+
+
+Signed-off-by: Samuel Martin <s.martin49@gmail.com>
+
+diff -purN linux-fusion-8.8.1.orig/linux/drivers/char/fusion/fusioncore.h linux-fusion-8.8.1/linux/drivers/char/fusion/fusioncore.h
+--- linux-fusion-8.8.1.orig/linux/drivers/char/fusion/fusioncore.h 2012-10-15 21:47:53.881834496 +0200
++++ linux-fusion-8.8.1/linux/drivers/char/fusion/fusioncore.h 2012-10-15 22:05:27.232401023 +0200
+@@ -17,7 +17,7 @@
+
+ #include <linux/stddef.h>
+
+-#include "fusioncore_impl.h"
++#include "single/fusioncore_impl.h"
+
+ typedef enum {
+ FC_OK,
+diff -purN linux-fusion-8.8.1.orig/linux/drivers/char/fusion/single/fusioncore_impl.c linux-fusion-8.8.1/linux/drivers/char/fusion/single/fusioncore_impl.c
+--- linux-fusion-8.8.1.orig/linux/drivers/char/fusion/single/fusioncore_impl.c 2012-10-15 21:47:53.878501243 +0200
++++ linux-fusion-8.8.1/linux/drivers/char/fusion/single/fusioncore_impl.c 2012-10-15 22:05:38.585511304 +0200
+@@ -22,9 +22,9 @@
+ #include <linux/slab.h>
+ #include <linux/sched.h>
+
+-#include "debug.h"
++#include "../debug.h"
+
+-#include "fusioncore.h"
++#include "../fusioncore.h"
+
+
+
^ permalink raw reply related
* [Buildroot] [PATCH 1/1] strace: remove undef-CTL_PROC patch
From: Peter Korsgaard @ 2012-11-30 0:32 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354209118-12653-1-git-send-email-james.hogan@imgtec.com>
>>>>> "James" == James Hogan <james.hogan@imgtec.com> writes:
James> This patch is no longer necessary since strace-v4.5.15 which always
James> defines CTL_PROC. Specifically strace git commit
James> 35a55785ea8ff44d214af52085e3a5ea624730aa.
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [git commit] strace: remove undef-CTL_PROC patch
From: Peter Korsgaard @ 2012-11-30 0:32 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=d490bb6c371468d027e228a445c258af4a272ba7
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
This patch is no longer necessary since strace-v4.5.15 which always
defines CTL_PROC. Specifically strace git commit
35a55785ea8ff44d214af52085e3a5ea624730aa.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/strace/strace-undef-CTL_PROC.patch | 12 ------------
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/package/strace/strace-undef-CTL_PROC.patch b/package/strace/strace-undef-CTL_PROC.patch
deleted file mode 100644
index d841999..0000000
--- a/package/strace/strace-undef-CTL_PROC.patch
+++ /dev/null
@@ -1,12 +0,0 @@
---- a/system.c
-+++ b/system.c
-@@ -1614,7 +1614,9 @@ static const struct xlat sysctl_root[] =
- { CTL_KERN, "CTL_KERN" },
- { CTL_VM, "CTL_VM" },
- { CTL_NET, "CTL_NET" },
-+#ifdef CTL_PROC
- { CTL_PROC, "CTL_PROC" },
-+#endif
- { CTL_FS, "CTL_FS" },
- { CTL_DEBUG, "CTL_DEBUG" },
- { CTL_DEV, "CTL_DEV" },
^ permalink raw reply related
* [Buildroot] [PATCH] [PATCH][RFC] new target: live filesystem
From: Steve Calfee @ 2012-11-30 0:04 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354003953-10875-1-git-send-email-jeremy.rosen@openwide.fr>
I don't understand why you need this. It is a one line "sudo tar -xf
..." to unpack the tarball into your nfs directory. Either type this
line or add a one line script to your ~/bin directory to do it for
each of your buildroot trees/environments. Don't add clutter to the
buildroot makefile.
Regards, Steve
On Tue, Nov 27, 2012 at 12:12 AM, J?r?my Rosen <jeremy.rosen@openwide.fr> wrote:
> add a new target to deploy a live filesystem to be used by NFS
>
> ---
>
> Hello everybody
>
> this patch is not ready for commit, it's a proposal to help me solve the very common use case of
> a developement FS deployed on NFS. I am not very happy of how it's done at this point but I would
> like to discuss it to see if it has a chance to get merged... What I don't like (and would gladly
> have ideas on how to solve this)
> * no dependency on host-sudo, i'm not sure how to add that
> * using sudo to break out of fakeroot is not clean
> * I am abusing the fs building framework, but I don't know of a cleaner way
> * filesystem can only be under output/images at this point
>
> so this patch is more to start a discussion than anything, i'll gladly take any comments or plain
> 'ol rejection if the project doesn't want it... but if there is some interest i'll work it into
> something mainline worthy
>
> Regards
>
> J?r?my Rosen
> ---
> fs/Config.in | 1 +
> fs/live/Config.in | 16 ++++++++++++++++
> fs/live/live.mk | 23 +++++++++++++++++++++++
> 3 files changed, 40 insertions(+)
> create mode 100644 fs/live/Config.in
> create mode 100644 fs/live/live.mk
>
> diff --git a/fs/Config.in b/fs/Config.in
> index 94154ea..de2377e 100644
> --- a/fs/Config.in
> +++ b/fs/Config.in
> @@ -11,5 +11,6 @@ source "fs/cpio/Config.in"
> source "fs/iso9660/Config.in"
> source "fs/initramfs/Config.in"
> source "fs/romfs/Config.in"
> +source "fs/live/Config.in"
>
> endmenu
> diff --git a/fs/live/Config.in b/fs/live/Config.in
> new file mode 100644
> index 0000000..bf24754
> --- /dev/null
> +++ b/fs/live/Config.in
> @@ -0,0 +1,16 @@
> +config BR2_TARGET_ROOTFS_LIVE
> + bool "live root filesystem"
> + help
> + uses sudo to create a live image of the filesystem
> + this is mainly usefull if you want to use your filesystem
> + over NFS
> +config BR2_TARGET_ROOTFS_LIVE_DEST
> + string "directory to put the live image"
> + depends on BR2_TARGET_ROOTFS_LIVE
> + default "live"
> + help
> + The directory where the image should be stored.
> + this directory will be emptied and recreated, it is given
> + relative to the buildroot output/images directory
> +
> +
> diff --git a/fs/live/live.mk b/fs/live/live.mk
> new file mode 100644
> index 0000000..73bcd3e
> --- /dev/null
> +++ b/fs/live/live.mk
> @@ -0,0 +1,23 @@
> +#############################################################
> +#
> +# Build the live root filesystem directory
> +#
> +#############################################################
> +
> +LIVE_OPTS :=
> +
> +
> +ROOTFS_LIVE_DEPENDENCIES = #host-sudo
> +
> +define ROOTFS_LIVE_CMD
> + sudo cp -r $(TARGET_DIR)/* $(BINARIES_DIR)/$(BR2_TARGET_ROOTFS_LIVE_DEST)/
> +endef
> +
> +define ROOTFS_LIVE_INIT
> + sudo rm -rf $(BINARIES_DIR)/$(BR2_TARGET_ROOTFS_LIVE_DEST)
> + sudo mkdir $(BINARIES_DIR)/$(BR2_TARGET_ROOTFS_LIVE_DEST)
> +endef
> +
> +ROOTFS_LIVE_PRE_GEN_HOOKS += ROOTFS_LIVE_INIT
> +
> +$(eval $(call ROOTFS_TARGET,live))
> --
> 1.7.10.4
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply
* [Buildroot] [PATCH][RFC] new target: live filesystem
From: Arnout Vandecappelle @ 2012-11-29 23:43 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354003953-10875-1-git-send-email-jeremy.rosen@openwide.fr>
On 27/11/12 09:12, J?r?my Rosen wrote:
> add a new target to deploy a live filesystem to be used by NFS
>
> ---
>
> Hello everybody
>
> this patch is not ready for commit, it's a proposal to help me solve the very common use case of
> a developement FS deployed on NFS. I am not very happy of how it's done at this point but I would
> like to discuss it to see if it has a chance to get merged... What I don't like (and would gladly
> have ideas on how to solve this)
> * no dependency on host-sudo, i'm not sure how to add that
That's impossible. The sudo executable must be setuid root, and to make
it setuid root you have to be root, so sudo must already exist...
You could instead add a check in live.mk if sudo actually works. But since
sudo may ask for a password this can get tricky - you should e.g. probably check
if stdin is a terminal as well.
That said, I don't know if Peter will accept running sudo within buildroot.
> * using sudo to break out of fakeroot is not clean
I don't see much of a problem there.
> * I am abusing the fs building framework, but I don't know of a cleaner way
You're not abusing it.
> * filesystem can only be under output/images at this point
That's not good but easy to solve.
>
> so this patch is more to start a discussion than anything, i'll gladly take any comments or plain
> 'ol rejection if the project doesn't want it... but if there is some interest i'll work it into
> something mainline worthy
>
> Regards
>
> J?r?my Rosen
> ---
> fs/Config.in | 1 +
> fs/live/Config.in | 16 ++++++++++++++++
> fs/live/live.mk | 23 +++++++++++++++++++++++
> 3 files changed, 40 insertions(+)
> create mode 100644 fs/live/Config.in
> create mode 100644 fs/live/live.mk
>
> diff --git a/fs/Config.in b/fs/Config.in
> index 94154ea..de2377e 100644
> --- a/fs/Config.in
> +++ b/fs/Config.in
> @@ -11,5 +11,6 @@ source "fs/cpio/Config.in"
> source "fs/iso9660/Config.in"
> source "fs/initramfs/Config.in"
> source "fs/romfs/Config.in"
> +source "fs/live/Config.in"
Sort alphabetically please.
>
> endmenu
> diff --git a/fs/live/Config.in b/fs/live/Config.in
> new file mode 100644
> index 0000000..bf24754
> --- /dev/null
> +++ b/fs/live/Config.in
> @@ -0,0 +1,16 @@
> +config BR2_TARGET_ROOTFS_LIVE
> + bool "live root filesystem"
> + help
> + uses sudo to create a live image of the filesystem
> + this is mainly usefull if you want to use your filesystem
useful
> + over NFS
or as a chroot
> +config BR2_TARGET_ROOTFS_LIVE_DEST
> + string "directory to put the live image"
"live image location"
> + depends on BR2_TARGET_ROOTFS_LIVE
> + default "live"
Use an empty default, and give an error in live.mk if it's
empty.
> + help
> + The directory where the image should be stored.
> + this directory will be emptied and recreated, it is given
> + relative to the buildroot output/images directory
Make it an absolute path instead.
> +
> diff --git a/fs/live/live.mk b/fs/live/live.mk
> new file mode 100644
> index 0000000..73bcd3e
> --- /dev/null
> +++ b/fs/live/live.mk
> @@ -0,0 +1,23 @@
> +#############################################################
> +#
> +# Build the live root filesystem directory
> +#
> +#############################################################
> +
> +LIVE_OPTS :=
This is unneeded.
> +
> +
> +ROOTFS_LIVE_DEPENDENCIES = #host-sudo
This as well.
> +
> +define ROOTFS_LIVE_CMD
> + sudo cp -r $(TARGET_DIR)/* $(BINARIES_DIR)/$(BR2_TARGET_ROOTFS_LIVE_DEST)/
That won't work, because device nodes, symlinks etc. are not
copied correctly. Use cp -a. Or even better, rsync -a --delete-during
(then you don't need to remove it first).
For the target, just use $(BR2_TARGET_ROOTFS_LIVE_DEST).
Regards,
Arnout
> +endef
> +
> +define ROOTFS_LIVE_INIT
> + sudo rm -rf $(BINARIES_DIR)/$(BR2_TARGET_ROOTFS_LIVE_DEST)
> + sudo mkdir $(BINARIES_DIR)/$(BR2_TARGET_ROOTFS_LIVE_DEST)
> +endef
> +
> +ROOTFS_LIVE_PRE_GEN_HOOKS += ROOTFS_LIVE_INIT
> +
> +$(eval $(call ROOTFS_TARGET,live))
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] Improving config navigation for mtd tools
From: Arnout Vandecappelle @ 2012-11-29 23:22 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAE21AQqPOGLxFVdCjaFpPo1x2kXCSo3+VbwvYk=THKfRbk+-UQ@mail.gmail.com>
On 28/11/12 01:12, Charles Manning wrote:
> Hello All
>
> The mtd utilities are part flash utilities and part file system
> utilities. This makes it a bit cryptic to put them under "Filesystem
> utilities".
>
> I suggest this can be resolved by remaining the heading to "Filesystem
> and flash utilities"
Thank you, that's a good idea. Could you post a proper patch?
That means:
- Write a commit message that documents the change (more
or less what you wrote above).
- Add a Signed-off-by line for yourself. This is a short way for you to
assert that you are entitled to contribute the patch under buildroot's
GPL license. See http://elinux.org/Developer_Certificate_Of_Origin
for more details.
- Preferably send it with git-send-email.
This will also add you to the list of buildroot contributors :-)
Regards,
Arnout
>
>
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -177,7 +177,7 @@ source "package/xterm/Config.in"
> source "package/xvkbd/Config.in"
> endmenu
>
> -menu "Filesystem utilities"
> +menu "Filesystem and flash utilities"
> source "package/cifs-utils/Config.in"
> source "package/cramfs/Config.in"
> source "package/dosfstools/Config.in"
>
>
> Regards
>
> Charles
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH] flex: fix build for nommu systems
From: Arnout Vandecappelle @ 2012-11-29 23:19 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354113314-30687-1-git-send-email-gustavo@zacarias.com.ar>
On 28/11/12 15:35, Gustavo Zacarias wrote:
> The flex binary uses fork() so it breaks on !MMU builds.
> Since we usually don't require flex in the target and the common
> scenario is that we just want libfl in staging reverse the options so
> that BR2_PACKAGE_FLEX just builds and install libfl.a and change the
> LIBFL option to BR2_PACKAGE_FLEX_BINARY to install the binary in the
> target.
>
> Signed-off-by: Gustavo Zacarias<gustavo@zacarias.com.ar>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(untested, visual review only)
Two small comments.
[snip]
> +ifeq ($(BR2_PACKAGE_FLEX_BINARY),)
I would prefer to compare with y and swap the two branches
(that will also make the diff much more readable...)
> +define FLEX_DISABLE_PROGRAM
> + $(SED) 's/^bin_PROGRAMS.*//' $(@D)/Makefile.in
> endef
>
> -define FLEX_UNINSTALL_LEX
> - -rm $(TARGET_DIR)/usr/bin/lex
> -endef
> +FLEX_POST_EXTRACT_HOOKS += FLEX_DISABLE_PROGRAM
POST_PATCH_HOOKS would be more appropriate.
Regards,
Arnout
>
> -FLEX_POST_INSTALL_HOOKS += FLEX_INSTALL_LEX
> -FLEX_POST_CLEAN_HOOKS += FLEX_UNINSTALL_LEX
> +else
>
> -# libfl installation
> -ifeq ($(BR2_PACKAGE_FLEX_LIBFL),y)
> -define FLEX_INSTALL_LIBFL
> - install -D $(FLEX_DIR)/libfl.a $(STAGING_DIR)/usr/lib/libfl.a
> +# lex -> flex
> +define FLEX_INSTALL_LEX
> + cd $(TARGET_DIR)/usr/bin&& ln -snf flex lex
> endef
>
> -define FLEX_UNINSTALL_LIBFL
> - -rm $(STAGING_DIR)/lib/libfl.a
> -endef
> +FLEX_POST_INSTALL_HOOKS += FLEX_INSTALL_LEX
>
> -FLEX_POST_INSTALL_HOOKS += FLEX_INSTALL_LIBFL
> -FLEX_POST_CLEAN_HOOKS += FLEX_UNINSTALL_LIBFL
> endif
>
> $(eval $(autotools-package))
[snip]
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] Problem building libglib2
From: Thomas Petazzoni @ 2012-11-29 23:11 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50B7C54C.3010103@mind.be>
Dear Arnout Vandecappelle,
On Thu, 29 Nov 2012 21:27:56 +0100, Arnout Vandecappelle wrote:
> We could obviously solve this by unexporting PKG_CONFIG_SYSROOT_DIR, but
> perhaps the better approach is to remove those environment variables from our
> custom pkgconf?
No, we use PKG_CONFIG_SYSROOT_DIR="/" when we build packages for the
host, so we can't simply remove support for the PKG_CONFIG_SYSROOT_DIR
environment variable. Unexporting PKG_CONFIG_SYSROOT_DIR sounds like
the good solution here.
Best 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] [PATCH 1/1] strace: remove undef-CTL_PROC patch
From: Arnout Vandecappelle @ 2012-11-29 22:44 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354209118-12653-1-git-send-email-james.hogan@imgtec.com>
On 29/11/12 18:11, James Hogan wrote:
> This patch is no longer necessary since strace-v4.5.15 which always
> defines CTL_PROC. Specifically strace git commit
> 35a55785ea8ff44d214af52085e3a5ea624730aa.
>
> Signed-off-by: James Hogan<james.hogan@imgtec.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH v2 6/6] manual: add generated *-list.txt
From: Arnout Vandecappelle @ 2012-11-29 22:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354175268-6909-3-git-send-email-s.martin49@gmail.com>
On 29/11/12 08:47, Samuel Martin wrote:
> diff --git a/docs/manual/pkg-list.txt b/docs/manual/package-list.txt
> similarity index 99%
> rename from docs/manual/pkg-list.txt
> rename to docs/manual/package-list.txt
> index 5d9b54f..d06316f 100644
> --- a/docs/manual/pkg-list.txt
> +++ b/docs/manual/package-list.txt
> @@ -1,3 +1,12 @@
> +
> +//
> +// Autogenerated file
> +//
> +
> +[[package-list]]
> +Available packages
> +------------------
> +
> * acl
> * acpid
> * alsa-lib
> @@ -346,6 +355,7 @@
> * luaexpat
> * luafilesystem
> * luajit
> +* lua-msgpack-native
> * luasocket
> * lvm2
> * lzma
I love this! Now you can easily see what has changed between two versions.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH v2 3/6] manual: add deprecated-list.txt generation support
From: Arnout Vandecappelle @ 2012-11-29 22:41 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354175268-6909-2-git-send-email-s.martin49@gmail.com>
On 29/11/12 08:47, Samuel Martin wrote:
> The whole deprecated-list.txt file is generated by the deprecated.py
> script by searching for symbols depending on BR2_DEPRECATED in the
> Buildroot code base.
>
> Signed-off-by: Samuel Martin<s.martin49@gmail.com>
> ---
>
> Change since v1:
>
> * rename the script deprecated.py -> gen-deprecated-list.py (to keep consistency)
>
> ---
> docs/manual/manual.mk | 3 +
> support/scripts/gen-deprecated-list.py | 144 +++++++++++++++++++++++++++++++++
> 2 files changed, 147 insertions(+)
> create mode 100755 support/scripts/gen-deprecated-list.py
>
> diff --git a/docs/manual/manual.mk b/docs/manual/manual.mk
> index d8437ba..4cd5839 100644
> --- a/docs/manual/manual.mk
> +++ b/docs/manual/manual.mk
> @@ -27,6 +27,9 @@ endef
> $(TOPDIR)/docs/manual/package-list.txt:
> $(TOPDIR)/support/scripts/gen-manual-pkg-list.sh> $@
>
> +$(TOPDIR)/docs/manual/deprecated-list.txt:
> + python2 $(TOPDIR)/support/scripts/gen-deprecated-list.py> $@
We don't have python2 in dependencies.sh, and anyway some things
don't currently work if python is python3. So I'd just call the
script without the python2. Anyway, does it not work with python3?
> +
> ################################################################################
> # GENDOC -- generates the make targets needed to build asciidoc documentation.
> #
> diff --git a/support/scripts/gen-deprecated-list.py b/support/scripts/gen-deprecated-list.py
> new file mode 100755
> index 0000000..cd8c288
> --- /dev/null
> +++ b/support/scripts/gen-deprecated-list.py
> @@ -0,0 +1,144 @@
> +#!/usr/bin/env python
> +##
> +## deprecated-packages.py
> +##
> +## Author(s):
> +## - Samuel MARTIN<s.martin49@gmail.com>
> +##
> +## Copyright (C) 2012 Samuel MARTIN
> +##
> +
> +# Python 2.7 script searching for kconfig symbols depending on 'BR2_DEPRECATED'
> +# and generating (printing to the standard output) the manual file in asciidoc.
> +
> +import os
> +import re
> +import sys
> +
> +
> +ASCIIDOC_HEADER = """\
> +//
> +// Autogenerated file
> +//
> +
> +[[deprecated]]
> +Deprecated list
> +---------------
> +
> +The following stuff are marked as _deprecated_ in Buildroot due to
> +their status either too old or unmaintained.
Better:
The following packages are marked as _deprecated_ because they are
either too old or unmaintained in buildroot.
> +
> +// Please check and sort by grepping the source running:
> +//
> +// $ git grep -EB4 'depends on BR2_DEPRECATED'
> +//
> +// and:
> +//
> +// $ git grep -EB4 'depends on BR2_DEPRECATED' | \\
> +// grep -Eo '(:|-).*?(config|comment) BR2_.*'
This is redundant now. Instead, mention the make target
after 'Autogenerated'.
> +"""
> +
> +NOT_SEARCHED = (".git", "board", "configs", "docs", "output", "support")
> +
> +# Relative path to category data map
> +# key: relative path from buildroot topdir to the search location
> +# value: (rank_in_menuconfig, category_name, recursive_search)
> +# rank_in_menuconfig is used for ordering the diplaying
> +# category_name is used in the diplaying
> +# recursive_search when searching for deprecated stuff
> +CAT_DIR2DATA = {
> + 'arch' : (0, "target architecture", True),
> + '.' : (1, "build options", False),
> + 'toolchain' : (2, "toolchain", True),
> + 'system' : (3, "system configuration", True),
> + 'package' : (4, "package selection", True),
> + 'fs' : (5, "filesystem images", True),
> + 'boot' : (6, "bootloaders", True),
> + 'linux' : (7, "kernel", True),
> + }
> +
> +DEPR_SYMBOL = "BR2_DEPRECATED"
> +
> +_REGEX = r"config BR2_(.*?)\n" + \
> + "((.*?(?!config)(prompt|bool|string|int) \"(.*?)\".*?|[^\n]+)\n)*" + \
> + "(.*?(?!config )" + DEPR_SYMBOL + ".*?)\n" + \
> + "((.*?(?!config)(prompt|bool|string|int) \"(.*?)\".*?|[^\n]+)\n)*"
This regex warrants some documentation :-) perhaps with re.VERBOSE
Why is the !config needed in the prompt lines?
Is there a reason to use the non-greedy .*? (except between the quotes)?
I would also name the "interesting" parts with (?P<...>) and use finditer()
and m.group() to retrieve them. But that's a matter of taste, I guess.
> +
> +REGEX = re.compile(_REGEX, flags=re.MULTILINE)
> +
> +
> +def _get_buildroot_topdir():
> + topdir = os.path.join(os.path.dirname(__file__), "..", "..")
> + topdir = os.path.abspath(topdir)
> + return topdir
I would just use the current directory as topdir. All the rest of
buildroot anyway assumes it's being run from the topdir.
> +
> +def get_dir_list():
> + root = _get_buildroot_topdir()
> + dirs = ['.']
> + for dir_ in os.listdir(root):
> + if dir_ in NOT_SEARCHED:
> + continue
> + dir__ = os.path.join(root, dir_)
> + if not os.path.isdir(dir__):
> + continue
> + dirs += [dir_]
> + return dirs
> +
> +def find_deprecated(root, recursive):
> + deprecated = list()
> + for root_, _, files_ in os.walk(root):
> + if not recursive and root_ != root:
> + break
> + for file_ in files_:
> + if not file_.startswith("Config.in"):
> + continue
> + with open(os.path.join(root_, file_), "r") as f:
> + content = f.read()
> + if not DEPR_SYMBOL in content:
> + continue
> + found = REGEX.findall(content)
> + if found:
> + deprecated += found
> + return deprecated
It's quite a big change, but: why not use the source statements
in Config.in to do the recursion? The regex it easy enough:
r'^\s*source "(?<path>.*?)"$' This would be more future-safe:
when new directories are added, they will be handled correctly.
It would also be good if you could add a warning when
len(found) != len(re.findall(DEPR_SYMBOL, content))
> +
> +
> +class Category():
> +
> + def __init__(self, directory):
> + self.path = os.path.join(_get_buildroot_topdir(), directory)
> + rank, name, rec = CAT_DIR2DATA.get(directory, (99, directory, True))
> + self.name = name
> + self.rank = rank
You can directly do
self.rank, self.name, rec = CAT_DIR2DATA.get(directory, (99, directory, True))
> + self.depr_items = find_deprecated(self.path, rec)
> +
> + def __str__(self):
> + items_ = list()
> + for item in self.depr_items:
> + name_ = item[0].lower().replace("_", " ")
> + name_ = re.sub("^package ", "", name_)
> + vers = re.sub(".*?(version )?([0-9].*)", r'\2', name_)
> + if vers:
> + vers = re.sub(" ", ".", vers)
> + name_ = re.sub("(version )?([0-9].*)", vers, name_)
> + symbol = item[4]
> + if not symbol:
> + symbol = item[9]
> + items_ += ["** %-25s +[%s]+" % (name_, symbol)]
I don't think the name_ part adds much value. In most cases, symbol
is either the same or more descriptive. There are a few exceptions,
but these could be fixed by changing the Config.in. These need to be
modified: gcc target, squashfs3 rootfs, uboot 11.06 and 11.09.
BTW, symbol is not really symbol but rather 'description' or something
similar.
> + items_.sort()
> + output = "\n* %s:\n\n" % self.name.capitalize()
> + output += "\n".join(items_)
> + output += "\n"
> + return output
> +
> +def main():
> + categories = [Category(directory) for directory in get_dir_list()]
> + categories = [category for category in categories if category.depr_items]
> + categories.sort(cmp=lambda x, y: x.rank - y.rank if x.rank != y.rank \
> + else cmp(x.name, y.name))
categories.sort(key=lambda x: (x.rank, x.name))
> + output = ASCIIDOC_HEADER
> + for category in categories:
> + output += str(category)
> + print output
Don't concat the output, just print directly.
print ASCIIDOC_HEADER
for category in categories:
print category
Regards,
Arnout
> +
> +if __name__ == "__main__":
> + main()
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] [PATCH v2 2/6] manual: add package-list.txt generation support
From: Arnout Vandecappelle @ 2012-11-29 20:48 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354175268-6909-1-git-send-email-s.martin49@gmail.com>
On 29/11/12 08:47, Samuel Martin wrote:
>
> Signed-off-by: Samuel Martin<s.martin49@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(untested)
But since I'm pedantic, I still have some comments :-)
[snip]
> diff --git a/support/scripts/gen-manual-pkg-list.sh b/support/scripts/gen-manual-pkg-list.sh
> new file mode 100755
> index 0000000..f11b4de
> --- /dev/null
> +++ b/support/scripts/gen-manual-pkg-list.sh
> @@ -0,0 +1,19 @@
> +#!/bin/sh
> +##
> +## gen-manual-pkg-list.sh
> +##
> +## Author(s):
> +## - Samuel MARTIN<s.martin49@gmail.com>
> +##
> +## Copyright (C) 2012 Samuel MARTIN
If you add a copyright statement, ideally you should also refer to the GPL:
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
(The fact that you put the Copyright statement there makes it look as if
it's proprietary. Adding the GPL reference disambiguates it. Of course,
it is implied by the global buildroot license even if you leave out the
GPL reference.)
> +##
> +
> +# Generate the manual package-list.txt content (in asciidoc format) and print it
> +# to the standard output.
> +
> +printf "\n//\n// Autogenerated file\n//\n\n"
> +printf "[[package-list]]\n"
> +printf "Available packages\n"
> +printf -- "------------------\n\n"
Since this is now part of a script, you can just cat a here document.
Much more readable.
> +grep -rlE --color=never '\((autotools|cmake|generic)-package\)' package | \
We globally unexport GREP_OPTIONS, so the --color=never is redundant.
In addition, it would barf on non-gnu-grep.
Regards,
Arnout
> + sed -ne '/.*\/\(.*\).mk$/ s//* \1/p' | sort
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] Problem building libglib2
From: Arnout Vandecappelle @ 2012-11-29 20:27 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201211300731.53056.manningc2@actrix.gen.nz>
On 29/11/12 19:31, Charles Manning wrote:
> export
> PKG_CONFIG_SYSROOT_DIR=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi
That's the one.
Charles, could you verify by setting this variable and rebuilding libglib2:
PKG_CONFIG_SYSROOT_DIR=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi \
make libglib2-dirclean libglib2
All,
We could obviously solve this by unexporting PKG_CONFIG_SYSROOT_DIR, but
perhaps the better approach is to remove those environment variables from our
custom pkgconf?
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] Buildroot for avr32
From: Thiago A. Corrêa @ 2012-11-29 18:48 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129193123.503b489b@skate>
On Thu, Nov 29, 2012 at 4:31 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> Ok, so your suggestion is to just maintain the AVR32 support in
> Buildroot as is, and not spend time improving it. Is that correct?
>
Actually I was trying not to suggest that, while trying to inform of
my past experience that might help somehow. I had edited the message a
few times before sending :)
Clearly there are still users, I don't feel it's right by them for me
to suggest that, but I don't know what the policy will be on this
case. I mean, gcc patches probably will not be accepted mainstream,
and I have a hard time believing someone will put in the effort after
Atmel droped the ball. It's also not realistic to expect buildroot, qt
or the kernel to carry that support indefinetly.
So, I guess what I'm saying is: I'm sure we would all appreciate if
the support can be improved, but if it's not possible, at least kept
for a while.
Althought you haven't said it, I believe you wish to drop the old gcc
options, and the avr32 toolchain is in the way.
^ permalink raw reply
* [Buildroot] Problem building libglib2
From: Charles Manning @ 2012-11-29 18:31 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129190813.5dc97298@skate>
On Friday 30 November 2012 07:08:13 Thomas Petazzoni wrote:
> Dear Charles Manning,
>
> On Fri, 30 Nov 2012 06:52:44 +1300, Charles Manning wrote:
> > > Maybe there's something fishy in your environment. Can you run
> > > env | grep /lib
> >
> > Aaaarrrrggghhhh!!!!
> >
> > I have this system set up to automatically set up for openembedded.
> > That defines PKG_CONFIG_PATH and adds some stuff to PATH which is
> > probably messing things up.
> >
> > I turned off the openembedded auto configuration, nuked output/ and make
> > ran to completion.
> >
> > I have now also learned a lot more about digging around in buildroot.
>
> Wait, wait, could you please reproduce the problem, and reply to
> Arnout's questions (sending us the output of env | grep /lib, or even
> the entire output of env if it doesn't contain any sensitive
> information).
>
> I would like to this which environment variable was causing the
> problem, and if we can add a check in Buildroot for this environment
> variable, in order to avoid similar issues in the future.
>
The problem was cause by running the openembedded toolchain env setup script
shown below and attached incase it gets too badly messed up by mail.
export PATH=/usr/local/angstrom/arm/bin:$PATH
export LIBTOOL_SYSROOT_PATH=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi
export
PKG_CONFIG_SYSROOT_DIR=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi
export
PKG_CONFIG_PATH=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib/pkgconfig
export QTDIR=/usr/local/angstrom/arm
export CONFIG_SITE=/usr/local/angstrom/arm/site-config
alias
opkg='LD_LIBRARY_PATH=/usr/local/angstrom/arm/lib /usr/local/angstrom/arm/bin/opkg-cl -f /usr/local/angstrom/arm/etc/opkg-sdk.conf -o /usr/local/angstrom/arm'
alias
opkg-target='LD_LIBRARY_PATH=/usr/local/angstrom/arm/lib /usr/local/angstrom/arm/bin/opkg-cl -f /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/etc/opkg.conf -o /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi'
I had added the following line to bashrc:
. /path/environment-setup
that caused it to always be added.
I see the Makefile has a line
unexport PKG_CONFIG_PATH
perhaps that should be
unset PKG_CONFIG_PATH
Is that enough info?
Sorry I have to go to the day job now, so if you want more I will have to work
on that later.
Thanks for your efforts!
-- CHarles
-------------- next part --------------
export PATH=/usr/local/angstrom/arm/bin:$PATH
export LIBTOOL_SYSROOT_PATH=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi
export PKG_CONFIG_SYSROOT_DIR=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi
export PKG_CONFIG_PATH=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib/pkgconfig
export QTDIR=/usr/local/angstrom/arm
export CONFIG_SITE=/usr/local/angstrom/arm/site-config
alias opkg='LD_LIBRARY_PATH=/usr/local/angstrom/arm/lib /usr/local/angstrom/arm/bin/opkg-cl -f /usr/local/angstrom/arm/etc/opkg-sdk.conf -o /usr/local/angstrom/arm'
alias opkg-target='LD_LIBRARY_PATH=/usr/local/angstrom/arm/lib /usr/local/angstrom/arm/bin/opkg-cl -f /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/etc/opkg.conf -o /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi'
^ permalink raw reply
* [Buildroot] Buildroot for avr32
From: Thomas Petazzoni @ 2012-11-29 18:31 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAExDhva8qpnukgyEAogo=cJhxZkdWaFU9ekPAujCgBtgMbaTOw@mail.gmail.com>
Dear Thiago A. Corr?a,
On Thu, 29 Nov 2012 16:25:23 -0200, Thiago A. Corr?a wrote:
> I'm talking from memory, because I haven't touched much of this for a while.
> Back then I tried patches from them and from Atmel, but complex
> software such as Qt had problems with them. They might have been
> updated since, but the most stable option was the current 4.2.2.
>
> I suspect that at some point the AVR32 support will be dropped, even
> from kernel.
Ok, so your suggestion is to just maintain the AVR32 support in
Buildroot as is, and not spend time improving it. Is that correct?
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] Buildroot for avr32
From: Thiago A. Corrêa @ 2012-11-29 18:25 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129190955.416f2373@skate>
Hi Thomas,
On Thu, Nov 29, 2012 at 4:09 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thiago A. Corr?a,
>
> On Thu, 29 Nov 2012 14:10:36 -0200, Thiago A. Corr?a wrote:
>
>> I have bugged them in support ticket and even in public forum which
>> they keep in avrfreaks.net before the EOL announcement.
>> The answer was that they would after finishing porting their patches
>> to gcc 3.4.x, but I guess they never did.
>
> OpenWRT has gcc 4.4.7 patches and binutils 2.21.1 patches. I've tried
> them, but unfortunately ld segfaults when linking uClibc. I'll do a
> quick investigation, but I don't think I want to invest too much time
> in this architecture...
>
I'm talking from memory, because I haven't touched much of this for a while.
Back then I tried patches from them and from Atmel, but complex
software such as Qt had problems with them. They might have been
updated since, but the most stable option was the current 4.2.2.
I suspect that at some point the AVR32 support will be dropped, even
from kernel.
^ permalink raw reply
* [Buildroot] Problem building libglib2
From: Arnout Vandecappelle @ 2012-11-29 18:22 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129190813.5dc97298@skate>
On 29/11/12 19:08, Thomas Petazzoni wrote:
> Dear Charles Manning,
>
> On Fri, 30 Nov 2012 06:52:44 +1300, Charles Manning wrote:
>>> Maybe there's something fishy in your environment. Can you run
>>> env | grep /lib
>>
>> Aaaarrrrggghhhh!!!!
>>
>> I have this system set up to automatically set up for openembedded.
>> That defines PKG_CONFIG_PATH and adds some stuff to PATH which is probably
>> messing things up.
>>
>> I turned off the openembedded auto configuration, nuked output/ and make ran
>> to completion.
>>
>> I have now also learned a lot more about digging around in buildroot.
>
> Wait, wait, could you please reproduce the problem, and reply to
> Arnout's questions (sending us the output of env | grep /lib, or even
> the entire output of env if it doesn't contain any sensitive
> information).
>
> I would like to this which environment variable was causing the
> problem, and if we can add a check in Buildroot for this environment
> variable, in order to avoid similar issues in the future.
After a second look in config.log:
pkg_cv_DBUS1_CFLAGS='-I/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/dbus-1.0
-I/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib/dbus-1.0/include '
pkg_cv_DBUS1_LIBS='-L/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib -ldbus-1 -lpthread -lrt '
pkg_cv_LIBFFI_CFLAGS=' '
pkg_cv_LIBFFI_LIBS='-L/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib -lffi '
pkg_cv_ZLIB_CFLAGS='-I/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include '
pkg_cv_ZLIB_LIBS='-L/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib -lz '
I really don't see how this can happen: we unexport PKG_CONFIG_PATH and set
PKG_CONFIG explicitly in the Makefile...
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply
* [Buildroot] Buildroot for avr32
From: Thomas Petazzoni @ 2012-11-29 18:09 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAExDhvZUT2KpJfuxqg__y=PqpLYQsHXaSEa6s1Ni61UW6D4skQ@mail.gmail.com>
Dear Thiago A. Corr?a,
On Thu, 29 Nov 2012 14:10:36 -0200, Thiago A. Corr?a wrote:
> I have bugged them in support ticket and even in public forum which
> they keep in avrfreaks.net before the EOL announcement.
> The answer was that they would after finishing porting their patches
> to gcc 3.4.x, but I guess they never did.
OpenWRT has gcc 4.4.7 patches and binutils 2.21.1 patches. I've tried
them, but unfortunately ld segfaults when linking uClibc. I'll do a
quick investigation, but I don't think I want to invest too much time
in this architecture...
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] Problem building libglib2
From: Thomas Petazzoni @ 2012-11-29 18:08 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201211300652.45293.manningc2@actrix.gen.nz>
Dear Charles Manning,
On Fri, 30 Nov 2012 06:52:44 +1300, Charles Manning wrote:
> > Maybe there's something fishy in your environment. Can you run
> > env | grep /lib
>
> Aaaarrrrggghhhh!!!!
>
> I have this system set up to automatically set up for openembedded.
> That defines PKG_CONFIG_PATH and adds some stuff to PATH which is probably
> messing things up.
>
> I turned off the openembedded auto configuration, nuked output/ and make ran
> to completion.
>
> I have now also learned a lot more about digging around in buildroot.
Wait, wait, could you please reproduce the problem, and reply to
Arnout's questions (sending us the output of env | grep /lib, or even
the entire output of env if it doesn't contain any sensitive
information).
I would like to this which environment variable was causing the
problem, and if we can add a check in Buildroot for this environment
variable, in order to avoid similar issues in the future.
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] Problem building libglib2
From: Charles Manning @ 2012-11-29 17:52 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50B72AAB.2020402@mind.be>
On Thursday 29 November 2012 22:28:11 Arnout Vandecappelle wrote:
> On 28/11/12 23:21, Charles Manning wrote:
> > On Thursday 29 November 2012 10:59:04 Arnout Vandecappelle wrote:
>
> [snip]
>
> >> Could you (and Alex):
> >> - tell us which host environment you have;
> >> - re-run the failed build with 'V=1 make libglib2' and
> >> post the failed command (should be something starting with:
> >> /bin/sh ../../libtool --tag=CC --mode=link ...)
> >> - post output/build/libglib2-2.30.3/config.log
> >> - post output/build/libglib2-2.30.3/gobject/Makefile
> >>
> >>
> >> I vaguely remember having seen this problem before, but can't
> >> remember if and how I solved it :-(
> >
> > Thanks for the help so far...
> >
> > I get this problem on my main work PC which is running Ubuntu 10.10 x32.
> > It works OK on a machine with Ubuntu 10.04 x64.
>
> So the link command ran by libtool is:
>
> /opt/buildroot/buildroot/output/host/usr/bin/arm-none-linux-gnueabi-gcc
> -shared -fPIC -DPIC .libs/libgobject_2_0_la-gatomicarray.o
> .libs/libgobject_2_0_la-gbinding.o .libs/libgobject_2_0_la-gboxed.o
> .libs/libgobject_2_0_la-gclosure.o .libs/libgobject_2_0_la-genums.o
> .libs/libgobject_2_0_la-gmarshal.o .libs/libgobject_2_0_la-gobject.o
> .libs/libgobject_2_0_la-gparam.o .libs/libgobject_2_0_la-gparamspecs.o
> .libs/libgobject_2_0_la-gsignal.o .libs/libgobject_2_0_la-gsourceclosure.o
> .libs/libgobject_2_0_la-gtype.o .libs/libgobject_2_0_la-gtypemodule.o
> .libs/libgobject_2_0_la-gtypeplugin.o .libs/libgobject_2_0_la-gvalue.o
> .libs/libgobject_2_0_la-gvaluearray.o
> .libs/libgobject_2_0_la-gvaluetransform.o
> .libs/libgobject_2_0_la-gvaluetypes.o -Wl,-rpath
> -Wl,/opt/buildroot/buildroot/output/build/libglib2-2.30.3/glib/.libs
> -Wl,-rpath
> -Wl,/opt/buildroot/buildroot/output/build/libglib2-2.30.3/gthread/.libs
> -L/opt/buildroot/buildroot/output/build/libglib2-2.30.3/glib/.libs
> ../glib/.libs/libglib-2.0.so ../ gthread/.libs/libgthread-2.0.so -lpthread
> /opt/buildroot/buildroot/output/build/libglib2-2.30.3/glib/.libs/libglib-2.
>0.so -lrt -L/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib -lffi
> -Os -Wl,-Bsymbolic-functions -Wl,-soname -Wl,libgobject-2.0.so.0
> -Wl,-version-script -Wl,.libs/libgobject-2.0.ver -o
> .libs/libgobject-2.0.so.0.3000.3
>
> (Just to be sure, could you go to the gobject directory and run the
> above command to verify that it fails in the same way? And also add the
> -v option to it, so we can see how exactly gcc calls ld.)
>
> There are two strange things with this:
>
> 1. There is no mention at all of /lib or /usr/lib so why is ld looking
> for pthread in those paths?
>
> 2. libtool adds
> -L/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib -- where does
> that come from?
>
> Maybe there's something fishy in your environment. Can you run
> env | grep /lib
Aaaarrrrggghhhh!!!!
I have this system set up to automatically set up for openembedded.
That defines PKG_CONFIG_PATH and adds some stuff to PATH which is probably
messing things up.
I turned off the openembedded auto configuration, nuked output/ and make ran
to completion.
I have now also learned a lot more about digging around in buildroot.
Thanks.
Charles
^ permalink raw reply
* [Buildroot] [PATCH 1/1] strace: remove undef-CTL_PROC patch
From: James Hogan @ 2012-11-29 17:11 UTC (permalink / raw)
To: buildroot
This patch is no longer necessary since strace-v4.5.15 which always
defines CTL_PROC. Specifically strace git commit
35a55785ea8ff44d214af52085e3a5ea624730aa.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
---
package/strace/strace-undef-CTL_PROC.patch | 12 ------------
1 files changed, 0 insertions(+), 12 deletions(-)
delete mode 100644 package/strace/strace-undef-CTL_PROC.patch
diff --git a/package/strace/strace-undef-CTL_PROC.patch b/package/strace/strace-undef-CTL_PROC.patch
deleted file mode 100644
index d841999..0000000
--- a/package/strace/strace-undef-CTL_PROC.patch
+++ /dev/null
@@ -1,12 +0,0 @@
---- a/system.c
-+++ b/system.c
-@@ -1614,7 +1614,9 @@ static const struct xlat sysctl_root[] =
- { CTL_KERN, "CTL_KERN" },
- { CTL_VM, "CTL_VM" },
- { CTL_NET, "CTL_NET" },
-+#ifdef CTL_PROC
- { CTL_PROC, "CTL_PROC" },
-+#endif
- { CTL_FS, "CTL_FS" },
- { CTL_DEBUG, "CTL_DEBUG" },
- { CTL_DEV, "CTL_DEV" },
--
1.7.7.6
^ permalink raw reply related
* [Buildroot] Buildroot for avr32
From: Thiago A. Corrêa @ 2012-11-29 16:10 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAHt8ZCO6Be2V+qPZ6Lu5y8kMaKipt2J=JgbbU7ZHqRXSF0c=tg@mail.gmail.com>
On Thu, Nov 29, 2012 at 2:05 PM, Simon Dawson <spdawson@gmail.com> wrote:
> Hi Thomas,
>
> On 29 Nov 2012 15:29, "Thomas Petazzoni"
> <thomas.petazzoni@free-electrons.com> wrote:
>> Do you know what is the status of AVR32 support in upstream gcc,
>> binutils and gdb?
>
> No, I don't. I suspect Atmel have all but stopped attempting to upstream
> patches for the architecture, but that is pure conjecture.
>
I have bugged them in support ticket and even in public forum which
they keep in avrfreaks.net before the EOL announcement.
The answer was that they would after finishing porting their patches
to gcc 3.4.x, but I guess they never did.
^ permalink raw reply
* [Buildroot] Buildroot for avr32
From: Simon Dawson @ 2012-11-29 16:05 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129162848.5a761c63@skate>
Hi Thomas,
On 29 Nov 2012 15:29, "Thomas Petazzoni" <
thomas.petazzoni@free-electrons.com> wrote:
> Do you know what is the status of AVR32 support in upstream gcc,
> binutils and gdb?
No, I don't. I suspect Atmel have all but stopped attempting to upstream
patches for the architecture, but that is pure conjecture.
Simon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121129/5020c7ae/attachment.html>
^ permalink raw reply
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