[Buildroot] Pull request buildroot.git (vapier branch)

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

The following changes since commit c2abc61d028b9e9cc602108ce1ad03942092bed2:

  tcpdump: add patch for nommu systems (2011-01-19 22:52:30 +0100)

are available in the git repository at:
  git://sources.blackfin.uclinux.org/git/users/vapier/buildroot.git vapier

Mike Frysinger (4):
      libpcap: update static handling
      debugging: do not require no stripping
      initial support for Blackfin processors
      gdb: add support for Blackfin gdbserver

 Config.in                                      |    4 +-
 Makefile                                       |    1 +
 boot/u-boot/Config.in                          |    4 +
 boot/u-boot/u-boot.mk                          |    2 +
 linux/Config.in                                |    2 +-
 linux/linux.mk                                 |    5 +
 package/libpcap/libpcap.mk                     |    6 +-
 target/Config.in.arch                          |   19 ++-
 toolchain/gdb/6.6/gdb-6.6-bfin-gdbserver.patch |  238 ++++++++++++++++++++++++
 toolchain/gdb/Config.in                        |    7 +-
 toolchain/toolchain-common.in                  |    2 +-
 11 files changed, 277 insertions(+), 13 deletions(-)
 create mode 100644 toolchain/gdb/6.6/gdb-6.6-bfin-gdbserver.patch

[Buildroot] [PATCH 1/4] libpcap: update static handling

[Mike Frysinger]

The new version of libpcap changed how its install targets work.  The
main "install" target now always depends on "install-shared", so we
need to force the DYEXT variable to "none" in order to bypass shared.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
 package/libpcap/libpcap.mk |    6 +-----
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/package/libpcap/libpcap.mk b/package/libpcap/libpcap.mk
index eebfc03..1c5f6e6 100644
--- a/package/libpcap/libpcap.mk
+++ b/package/libpcap/libpcap.mk
@@ -8,12 +8,8 @@ LIBPCAP_VERSION:=1.1.1
 LIBPCAP_SITE:=http://www.tcpdump.org/release
 LIBPCAP_SOURCE:=libpcap-$(LIBPCAP_VERSION).tar.gz
 LIBPCAP_INSTALL_STAGING:=YES
-# doesn't have an install-strip
-LIBPCAP_INSTALL_TARGET_OPT= DESTDIR="$(TARGET_DIR)" \
-	$(if $(BR2_PREFER_STATIC_LIB),install,install-shared)
-LIBPCAP_INSTALL_STAGING_OPT= DESTDIR="$(STAGING_DIR)" install \
-	$(if $(BR2_PREFER_STATIC_LIB),,install-shared)
 LIBPCAP_DEPENDENCIES:=zlib
+LIBPCAP_MAKE_OPT:=DYEXT=none
 LIBPCAP_CONF_ENV:=ac_cv_linux_vers=$(firstword $(subst .,$(space),$(firstword $(call qstrip,$(BR2_DEFAULT_KERNEL_HEADERS))))) \
 		  ac_cv_header_linux_wireless_h=yes # configure misdetects this
 LIBPCAP_CONF_OPT:=--disable-yydebug --with-pcap=linux
-- 
1.7.4.rc2

[Buildroot] [PATCH 2/4] debugging: do not require no stripping

[Mike Frysinger]

The stripping options operate on the final image and not the intermediate
builds, so requiring stripping to be disabled just to enable debugging
options doesn't make much sense.  Especially when working with gdbserver:
only the host needs the debugging information to be available.  The board
can run & debug perfectly fine without it.

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
 Config.in |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Config.in b/Config.in
index df0c7ce..a1cc57a 100644
--- a/Config.in
+++ b/Config.in
@@ -209,14 +209,14 @@ choice
 
 config BR2_STRIP_strip
 	bool "strip"
-	depends on !BR2_ENABLE_DEBUG && !BR2_ELF2FLT
+	depends on !BR2_ELF2FLT
 	help
 	  strip   is the normal strip command
 
 config BR2_STRIP_sstrip
 	bool "sstrip"
 	select BR2_PACKAGE_SSTRIP_HOST
-	depends on !BR2_ENABLE_DEBUG && !BR2_ELF2FLT
+	depends on !BR2_ELF2FLT
 	help
 	  sstrip  is a strip that discards more than the normal strip
 
-- 
1.7.4.rc2

[Buildroot] [PATCH 3/4] initial support for Blackfin processors

[Mike Frysinger]

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
 Makefile                      |    1 +
 boot/u-boot/Config.in         |    4 ++++
 boot/u-boot/u-boot.mk         |    2 ++
 linux/Config.in               |    2 +-
 linux/linux.mk                |    5 +++++
 target/Config.in.arch         |   19 ++++++++++++++++++-
 toolchain/toolchain-common.in |    2 +-
 7 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index cf2a7dc..f39a355 100644
--- a/Makefile
+++ b/Makefile
@@ -263,6 +263,7 @@ endif
 KERNEL_ARCH:=$(shell echo "$(ARCH)" | sed -e "s/-.*//" \
 	-e s/i.86/i386/ -e s/sun4u/sparc64/ \
 	-e s/arm.*/arm/ -e s/sa110/arm/ \
+	-e s/bfin/blackfin/ \
 	-e s/parisc64/parisc/ \
 	-e s/powerpc64/powerpc/ \
 	-e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
diff --git a/boot/u-boot/Config.in b/boot/u-boot/Config.in
index 60aeb1a..78c03ff 100644
--- a/boot/u-boot/Config.in
+++ b/boot/u-boot/Config.in
@@ -75,6 +75,10 @@ config BR2_TARGET_UBOOT_FORMAT_KWB
 	depends on BR2_arm
 	bool "u-boot.kwb (Marvell)"
 
+config BR2_TARGET_UBOOT_FORMAT_LDR
+	depends on BR2_bfin
+	bool "u-boot.ldr"
+
 endchoice
 
 config BR2_TARGET_UBOOT_TOOL_MKIMAGE
diff --git a/boot/u-boot/u-boot.mk b/boot/u-boot/u-boot.mk
index d520bb8..7c67d97 100644
--- a/boot/u-boot/u-boot.mk
+++ b/boot/u-boot/u-boot.mk
@@ -31,6 +31,8 @@ U_BOOT_CAT:=$(BZCAT)
 ifeq ($(BR2_TARGET_UBOOT_FORMAT_KWB),y)
 U_BOOT_BIN:=u-boot.kwb
 U_BOOT_MAKE_OPT:=$(U_BOOT_BIN)
+else ifeq ($(BR2_TARGET_UBOOT_FORMAT_LDR),y)
+U_BOOT_BIN:=u-boot.ldr
 else
 U_BOOT_BIN:=u-boot.bin
 endif
diff --git a/linux/Config.in b/linux/Config.in
index 17aa29a..bdb1abe 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -115,7 +115,7 @@ choice
 
 config BR2_LINUX_KERNEL_UIMAGE
 	bool "uImage"
-	depends on BR2_arm || BR2_armeb || BR2_powerpc || BR2_avr32 || BR2_sh || BR2_sh64
+	depends on BR2_arm || BR2_armeb || BR2_bfin || BR2_powerpc || BR2_avr32 || BR2_sh || BR2_sh64
 
 config BR2_LINUX_KERNEL_BZIMAGE
 	bool "bzImage"
diff --git a/linux/linux.mk b/linux/linux.mk
index d3c06db..68b43d3 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -31,7 +31,12 @@ LINUX26_MAKE_FLAGS = \
 LINUX26_VERSION_PROBED = $(shell $(MAKE) $(LINUX26_MAKE_FLAGS) -C $(LINUX26_DIR) --no-print-directory -s kernelrelease)
 
 ifeq ($(BR2_LINUX_KERNEL_UIMAGE),y)
+ifeq ($(KERNEL_ARCH),blackfin)
+# a uImage, but with a diff file name
+LINUX26_IMAGE_NAME=vmImage
+else
 LINUX26_IMAGE_NAME=uImage
+endif
 LINUX26_DEPENDENCIES+=$(MKIMAGE)
 else ifeq ($(BR2_LINUX_KERNEL_BZIMAGE),y)
 LINUX26_IMAGE_NAME=bzImage
diff --git a/target/Config.in.arch b/target/Config.in.arch
index 0774d55..7c80945 100644
--- a/target/Config.in.arch
+++ b/target/Config.in.arch
@@ -14,6 +14,8 @@ config BR2_armeb
 config BR2_avr32
 	bool "avr32"
 	select BR2_SOFT_FLOAT
+config BR2_bfin
+	bool "bfin"
 config BR2_i386
 	bool "i386"
 config BR2_m68k
@@ -128,6 +130,20 @@ config BR2_ARM_OABI
 endchoice
 
 choice
+	prompt "Target ABI"
+	depends on BR2_bfin
+	default BR2_BFIN_FLAT
+config BR2_BFIN_FDPIC
+	bool "FDPIC"
+config BR2_BFIN_FLAT
+	bool "FLAT"
+config BR2_BFIN_FLAT_SEP_DATA
+	bool "FLAT (Separate data)"
+config BR2_BFIN_SHARED_FLAT
+	bool "Shared FLAT"
+endchoice
+
+choice
 	prompt "Target Architecture Variant"
 	depends on BR2_mips || BR2_mipsel
 	default BR2_mips_3 if BR2_mips
@@ -444,6 +460,7 @@ config BR2_ARCH
 	default "arm"		if BR2_arm
 	default "armeb"		if BR2_armeb
 	default "avr32"		if BR2_avr32
+	default "bfin"		if BR2_bfin
 	default "i386"		if BR2_x86_i386
 	default "i486"		if BR2_x86_i486
 	default "i586"		if BR2_x86_i586
@@ -485,7 +502,7 @@ config BR2_ARCH
 
 config BR2_ENDIAN
 	string
-	default "LITTLE" if BR2_arm || BR2_i386 || BR2_mipsel || \
+	default "LITTLE" if BR2_arm || BR2_bfin || BR2_i386 || BR2_mipsel || \
 			    BR2_sh3 || BR2_sh4 || BR2_x86_64 || BR2_sh64
 	default "BIG"    if BR2_armeb || BR2_avr32 || BR2_m68k || BR2_mips || \
 			    BR2_powerpc || BR2_sh2a_nofpueb || BR2_sh2eb || \
diff --git a/toolchain/toolchain-common.in b/toolchain/toolchain-common.in
index eb3628a..cdfd56a 100644
--- a/toolchain/toolchain-common.in
+++ b/toolchain/toolchain-common.in
@@ -67,7 +67,7 @@ config BR2_NEEDS_GETTEXT_IF_LOCALE
 	default y if (BR2_NEEDS_GETTEXT && BR2_ENABLE_LOCALE)
 
 config BR2_USE_MMU
-	bool "Enable MMU support" if BR2_arm || BR2_armeb || BR2_mips || BR2_mipsel || BR2_sh || BR2_xtensa
+	bool "Enable MMU support" if BR2_arm || BR2_armeb || BR2_bfin || BR2_mips || BR2_mipsel || BR2_sh || BR2_xtensa
 	default y
 	help
 	  If your target has a MMU, you should say Y here.  If you
-- 
1.7.4.rc2

[Buildroot] [PATCH 4/4] gdb: add support for Blackfin gdbserver

[Mike Frysinger]

This requires removing "deprecated" markings from gdb-6.6, but this isn't
that big of a deal.  That is the last version with Blackfin support at the
moment and we're in the process of getting mainlined.

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
 toolchain/gdb/6.6/gdb-6.6-bfin-gdbserver.patch |  238 ++++++++++++++++++++++++
 toolchain/gdb/Config.in                        |    7 +-
 2 files changed, 242 insertions(+), 3 deletions(-)
 create mode 100644 toolchain/gdb/6.6/gdb-6.6-bfin-gdbserver.patch

diff --git a/toolchain/gdb/6.6/gdb-6.6-bfin-gdbserver.patch b/toolchain/gdb/6.6/gdb-6.6-bfin-gdbserver.patch
new file mode 100644
index 0000000..65c4b90
--- /dev/null
+++ b/toolchain/gdb/6.6/gdb-6.6-bfin-gdbserver.patch
@@ -0,0 +1,238 @@
+--- gdb-6.6/gdb/gdbserver/configure.srv
++++ gdb-6.6/gdb/gdbserver/configure.srv
+@@ -23,6 +23,11 @@ case "${target}" in
+ 			srv_linux_usrregs=yes
+ 			srv_linux_thread_db=yes
+ 			;;
++  bfin-*-*)		srv_regobj=reg-bfin.o
++			srv_tgtobj="linux-low.o linux-bfin-low.o"
++			srv_linux_usrregs=yes
++			srv_linux_thread_db=yes
++			;;
+   crisv32-*-linux*)	srv_regobj=reg-crisv32.o
+ 			srv_tgtobj="linux-low.o linux-crisv32-low.o"
+ 			srv_linux_regsets=yes
+--- gdb-6.6/gdb/gdbserver/linux-bfin-low.c
++++ gdb-6.6/gdb/gdbserver/linux-bfin-low.c
+@@ -0,0 +1,101 @@
++/* GNU/Linux/BFIN specific low level interface, for the remote server for GDB.
++
++   Copyright (C) 2005 Free Software Foundation, Inc.
++   Contributed by Analog Devices.
++
++   This file is part of GDB.
++
++   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.
++
++   This program is distributed in the hope that it will be useful,
++   but WITHOUT ANY WARRANTY; without even the implied warranty of
++   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
++   GNU General Public License for more details.
++
++   You should have received a copy of the GNU General Public License
++   along with this program; if not, write to the Free Software
++   Foundation, Inc., 51 Franklin Street, Fifth Floor,
++   Boston, MA 02110-1301, USA.  */
++
++#include "server.h"
++#include "linux-low.h"
++#include <asm/ptrace.h>
++ 
++static int bfin_regmap[] =
++{
++  PT_R0, PT_R1, PT_R2, PT_R3, PT_R4, PT_R5, PT_R6, PT_R7,
++  PT_P0, PT_P1, PT_P2, PT_P3, PT_P4, PT_P5, PT_USP, PT_FP,
++  PT_I0, PT_I1, PT_I2, PT_I3, PT_M0, PT_M1, PT_M2, PT_M3,
++  PT_B0, PT_B1, PT_B2, PT_B3, PT_L0, PT_L1, PT_L2, PT_L3,
++  PT_A0X, PT_A0W, PT_A1X, PT_A1W, PT_ASTAT, PT_RETS,
++  PT_LC0, PT_LT0, PT_LB0, PT_LC1, PT_LT1, PT_LB1,
++  -1 /* PT_CYCLES */, -1 /* PT_CYCLES2 */,
++  -1 /* PT_USP */, PT_SEQSTAT, PT_SYSCFG, PT_PC, PT_RETX, PT_RETN, PT_RETE,
++  PT_PC, -1 /* PT_CC */, PT_TEXT_ADDR, PT_TEXT_END_ADDR, PT_DATA_ADDR,
++  PT_FDPIC_EXEC, PT_FDPIC_INTERP,
++  PT_IPEND
++};
++
++#define bfin_num_regs  (sizeof(bfin_regmap) / sizeof(bfin_regmap[0]))
++
++static int
++bfin_cannot_store_register (int regno)
++{
++  return (regno >= bfin_num_regs);
++}
++
++static int
++bfin_cannot_fetch_register (int regno)
++{
++  return (regno >= bfin_num_regs);
++}
++
++static CORE_ADDR
++bfin_get_pc ()
++{
++  unsigned long pc;
++  collect_register_by_name ("pc", &pc);
++  return pc;
++}
++
++static void
++bfin_set_pc (CORE_ADDR pc)
++{
++  unsigned long newpc = pc;
++  supply_register_by_name ("pc", &newpc);
++}
++
++#define bfin_breakpoint_len 2
++static const unsigned char bfin_breakpoint[bfin_breakpoint_len]={0xa1, 0x00};
++
++static int
++bfin_breakpoint_at (CORE_ADDR where)
++{
++  unsigned char insn[bfin_breakpoint_len];
++
++  read_inferior_memory(where, insn, bfin_breakpoint_len);
++  if (insn[0] == bfin_breakpoint[0]
++      && insn[1] == bfin_breakpoint[1])
++    return 1;
++
++  /* If necessary, recognize more trap instructions here.  GDB only uses the
++     one.  */
++  return 0;
++}
++
++struct linux_target_ops the_low_target = {
++  bfin_num_regs,
++  bfin_regmap,
++  bfin_cannot_fetch_register,
++  bfin_cannot_store_register,
++  bfin_get_pc,
++  bfin_set_pc,
++  bfin_breakpoint,
++  bfin_breakpoint_len,
++  0,
++  2,
++  bfin_breakpoint_at,
++};
+--- gdb-6.6/gdb/gdbserver/linux-low.c
++++ gdb-6.6/gdb/gdbserver/linux-low.c
+@@ -1592,6 +1592,10 @@ linux_stopped_data_address (void)
+ #define PT_TEXT_ADDR 49*4
+ #define PT_DATA_ADDR 50*4
+ #define PT_TEXT_END_ADDR  51*4
++#elif defined(BFIN)
++#define PT_TEXT_ADDR 220
++#define PT_TEXT_END_ADDR 224
++#define PT_DATA_ADDR 228
+ #endif
+ 
+ /* Under uClinux, programs are loaded at non-zero offsets, which we need
+--- gdb-6.6/gdb/gdbserver/Makefile.in
++++ gdb-6.6/gdb/gdbserver/Makefile.in
+@@ -119,9 +119,9 @@ SFILES=	$(srcdir)/gdbreplay.c $(srcdir)/
+ 	$(srcdir)/mem-break.c $(srcdir)/proc-service.c $(srcdir)/regcache.c \
+ 	$(srcdir)/remote-utils.c $(srcdir)/server.c $(srcdir)/target.c \
+ 	$(srcdir)/thread-db.c $(srcdir)/utils.c \
+-	$(srcdir)/linux-arm-low.c $(srcdir)/linux-cris-low.c \
+-	$(srcdir)/linux-crisv32-low.c $(srcdir)/linux-i386-low.c \
+-	$(srcdir)/i387-fp.c \
++	$(srcdir)/linux-arm-low.c $(srcdir)/linux-bfin-low.c \
++	$(srcdir)/linux-cris-low.c $(srcdir)/linux-crisv32-low.c \
++	$(srcdir)/linux-i386-low.c $(srcdir)/i387-fp.c \
+ 	$(srcdir)/linux-ia64-low.c $(srcdir)/linux-low.c \
+ 	$(srcdir)/linux-m32r-low.c \
+ 	$(srcdir)/linux-m68k-low.c $(srcdir)/linux-mips-low.c \
+@@ -207,6 +207,7 @@ clean:
+ 	rm -f reg-arm.c reg-i386.c reg-ia64.c reg-m32r.c reg-m68k.c reg-mips.c
+ 	rm -f reg-ppc.c reg-sh.c reg-spu.c reg-x86-64.c reg-i386-linux.c
+ 	rm -f reg-cris.c reg-crisv32.c reg-x86-64-linux.c
++	rm -f reg-bfin.c
+ 
+ maintainer-clean realclean distclean: clean
+ 	rm -f nm.h tm.h xm.h config.status config.h stamp-h config.log
+@@ -272,6 +273,7 @@ linux-low.o: linux-low.c $(linux_low_h) 
+ 
+ linux-arm-low.o: linux-arm-low.c $(linux_low_h) $(server_h) \
+ 	$(gdb_proc_service_h)
++linux-bfin-low.o: linux-bfin-low.c $(linux_low_h) $(server_h)
+ linux-cris-low.o: linux-cris-low.c $(linux_low_h) $(server_h)
+ linux-crisv32-low.o: linux-crisv32-low.c $(linux_low_h) $(server_h)
+ linux-i386-low.o: linux-i386-low.c $(linux_low_h) $(server_h) \
+@@ -294,6 +297,9 @@ spu-low.o: spu-low.c $(server_h)
+ reg-arm.o : reg-arm.c $(regdef_h)
+ reg-arm.c : $(srcdir)/../regformats/reg-arm.dat $(regdat_sh)
+ 	sh $(regdat_sh) $(srcdir)/../regformats/reg-arm.dat reg-arm.c
++reg-bfin.o : reg-bfin.c $(regdef_h)
++reg-bfin.c : $(srcdir)/../regformats/reg-bfin.dat $(regdat_sh)
++	sh $(regdat_sh) $(srcdir)/../regformats/reg-bfin.dat reg-bfin.c
+ reg-cris.o : reg-cris.c $(regdef_h)
+ reg-cris.c : $(srcdir)/../regformats/reg-cris.dat $(regdat_sh)
+ 	sh $(regdat_sh) $(srcdir)/../regformats/reg-cris.dat reg-cris.c
+--- gdb-6.6/gdb/regformats/reg-bfin.dat
++++ gdb-6.6/gdb/regformats/reg-bfin.dat
+@@ -0,0 +1,63 @@
++name:bfin
++expedite:pc,sp,fp
++32:r0
++32:r1
++32:r2
++32:r3
++32:r4
++32:r5
++32:r6
++32:r7
++32:p0
++32:p1
++32:p2
++32:p3
++32:p4
++32:p5
++32:sp
++32:fp
++32:i0
++32:i1
++32:i2
++32:i3
++32:m0
++32:m1
++32:m2
++32:m3
++32:b0
++32:b1
++32:b2
++32:b3
++32:l0
++32:l1
++32:l2
++32:l3
++32:a0x
++32:a0w
++32:a1x
++32:a1w
++32:astat
++32:rets 
++32:lc0
++32:lt0
++32:lb0
++32:lc1
++32:lt1
++32:lb1
++32:cycles
++32:cycles2
++32:usp
++32:seqstat
++32:syscfg
++32:reti
++32:retx
++32:retn
++32:rete
++32:pc
++32:cc
++32:text_addr
++32:text_end_addr
++32:data_addr
++32:fdpic_exec
++32:fdpic_interp
++32:ipend
diff --git a/toolchain/gdb/Config.in b/toolchain/gdb/Config.in
index b45de9a..f7347ad 100644
--- a/toolchain/gdb/Config.in
+++ b/toolchain/gdb/Config.in
@@ -35,10 +35,9 @@ choice
 	config BR2_GDB_VERSION_6_6
 		bool "gdb 6.6"
 		depends on !BR2_avr32
-		depends on BR2_DEPRECATED
 
 	config BR2_GDB_VERSION_6_7_1
-		depends on !BR2_avr32
+		depends on !(BR2_avr32 || BR2_bfin)
 		bool "gdb 6.7.1"
 
 	config BR2_GDB_VERSION_6_7_1_AVR32_2_1_5
@@ -47,14 +46,16 @@ choice
 
 	config BR2_GDB_VERSION_6_8
 		bool "gdb 6.8"
-		depends on !BR2_avr32
+		depends on !(BR2_avr32 || BR2_bfin)
 
 	config BR2_GDB_VERSION_7_0_1
 		bool "gdb 7.0.1"
+		depends on !BR2_bfin
 		select BR2_PTHREAD_DEBUG if !BR2_PTHREADS_NONE
 
 	config BR2_GDB_VERSION_7_1
 		bool "gdb 7.1"
+		depends on !BR2_bfin
 		select BR2_PTHREAD_DEBUG if !BR2_PTHREADS_NONE
 
 endchoice
-- 
1.7.4.rc2

[Buildroot] [PATCH 1/4] libpcap: update static handling

[Peter Korsgaard]

>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:

 Mike> The new version of libpcap changed how its install targets work.  The
 Mike> main "install" target now always depends on "install-shared", so we
 Mike> need to force the DYEXT variable to "none" in order to bypass shared.

Does that then still install the shared lib for normal
(!PREFER_STATIC_LIB) builds, or should this only be passed for the
static case?

 Mike> +++ b/package/libpcap/libpcap.mk
 Mike> @@ -8,12 +8,8 @@ LIBPCAP_VERSION:=1.1.1
 Mike>  LIBPCAP_SITE:=http://www.tcpdump.org/release
 Mike>  LIBPCAP_SOURCE:=libpcap-$(LIBPCAP_VERSION).tar.gz
 Mike>  LIBPCAP_INSTALL_STAGING:=YES
 Mike> -# doesn't have an install-strip
 Mike> -LIBPCAP_INSTALL_TARGET_OPT= DESTDIR="$(TARGET_DIR)" \
 Mike> -	$(if $(BR2_PREFER_STATIC_LIB),install,install-shared)
 Mike> -LIBPCAP_INSTALL_STAGING_OPT= DESTDIR="$(STAGING_DIR)" install \
 Mike> -	$(if $(BR2_PREFER_STATIC_LIB),,install-shared)
 Mike>  LIBPCAP_DEPENDENCIES:=zlib
 Mike> +LIBPCAP_MAKE_OPT:=DYEXT=none

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/4] libpcap: update static handling

[Mike Frysinger]

On Sunday, January 23, 2011 05:17:43 Peter Korsgaard wrote:
> >>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:
>  Mike> The new version of libpcap changed how its install targets work. 
> The Mike> main "install" target now always depends on "install-shared", so
> we Mike> need to force the DYEXT variable to "none" in order to bypass
> shared.
> 
> Does that then still install the shared lib for normal
> (!PREFER_STATIC_LIB) builds, or should this only be passed for the
> static case?

hmm, well Thomas' suggestion before doesnt work ... the current autotools 
Makefile only adds $(PKG)_MAKE_OPT to the build step instead of all the steps.  
so ignore this patch until that can be fixed.

the other 3 patches in this set dont require this one
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110123/70542dc5/attachment.asc>

[Buildroot] [PATCH 1/4] libpcap: update static handling

[Thomas Petazzoni]

Hello,

Completely unrelated to Mike's change, but still spotted while looking
at the patch context:

On Wed, 19 Jan 2011 22:10:29 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

>  LIBPCAP_CONF_ENV:=ac_cv_linux_vers=$(firstword $(subst .,$(space),$(firstword $(call qstrip,$(BR2_DEFAULT_KERNEL_HEADERS))))) \

Both libpcap and tcpdump use this and I never noticed, but this is
completely broken with external toolchains and the Crosstool-NG backend,
since BR2_DEFAULT_KERNEL_HEADERS is only set with internal toolchains.

I haven't thought of what the right fix would be, but it's definitely
not that one.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1/4] libpcap: update static handling

[Thomas Petazzoni]

On Sun, 23 Jan 2011 16:07:30 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> hmm, well Thomas' suggestion before doesnt work ... the current autotools 
> Makefile only adds $(PKG)_MAKE_OPT to the build step instead of all the steps.  
> so ignore this patch until that can be fixed.

For the moment:

 $(PKG)_MAKE_OPT is passed at build time for target and host packages
 (maybe we should rename it $(PKG)_BUILD_MAKE_OPT, or pass it during all
 steps)

 $(PKG)_INSTALL_STAGING_OPT is passed at staging installation time for
 target packages

 $(PKG)_INSTALL_TARGET_OPT is passed at target installation time for
 target packages

So in your case you probably need to do something like:

LIBPCAP_INSTALL_STAGING_OPT = DYEXT=none DESTDIR="$(STAGING_DIR)" install
LIBPCAP_INSTALL_TARGET_OPT  = DYEXT=none DESTDIR="$(TARGET_DIR)" install

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110124/4e46cae6/attachment.asc>

[Buildroot] [PATCH 1/4] libpcap: update static handling

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> Hello,
 Thomas> Completely unrelated to Mike's change, but still spotted while looking
 Thomas> at the patch context:

 Thomas> On Wed, 19 Jan 2011 22:10:29 -0500
 Thomas> Mike Frysinger <vapier@gentoo.org> wrote:

 >> LIBPCAP_CONF_ENV:=ac_cv_linux_vers=$(firstword $(subst .,$(space),$(firstword $(call qstrip,$(BR2_DEFAULT_KERNEL_HEADERS))))) \

 Thomas> Both libpcap and tcpdump use this and I never noticed, but this
 Thomas> is completely broken with external toolchains and the
 Thomas> Crosstool-NG backend, since BR2_DEFAULT_KERNEL_HEADERS is only
 Thomas> set with internal toolchains.

 Thomas> I haven't thought of what the right fix would be, but it's definitely
 Thomas> not that one.

True. The question is why they need this info? Perhaps we can just lie
and simply say 2.6.x?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/4] libpcap: update static handling

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 Thomas> So in your case you probably need to do something like:

 Thomas> LIBPCAP_INSTALL_STAGING_OPT = DYEXT=none DESTDIR="$(STAGING_DIR)" install
 Thomas> LIBPCAP_INSTALL_TARGET_OPT  = DYEXT=none DESTDIR="$(TARGET_DIR)" install

And presumably only for the BR2_PREFER_STATIC_LIB case.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/4] libpcap: update static handling

[Mike Frysinger]

On Monday, January 24, 2011 11:25:25 Peter Korsgaard wrote:
> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> 
writes:
>  Thomas> Hello,
>  Thomas> Completely unrelated to Mike's change, but still spotted while
> looking Thomas> at the patch context:
> 
>  Thomas> On Wed, 19 Jan 2011 22:10:29 -0500
> 
>  Thomas> Mike Frysinger <vapier@gentoo.org> wrote:
>  >> LIBPCAP_CONF_ENV:=ac_cv_linux_vers=$(firstword $(subst
>  >> .,$(space),$(firstword $(call qstrip,$(BR2_DEFAULT_KERNEL_HEADERS)))))
>  >> \
> 
>  Thomas> Both libpcap and tcpdump use this and I never noticed, but this
>  Thomas> is completely broken with external toolchains and the
>  Thomas> Crosstool-NG backend, since BR2_DEFAULT_KERNEL_HEADERS is only
>  Thomas> set with internal toolchains.
> 
>  Thomas> I haven't thought of what the right fix would be, but it's
> definitely Thomas> not that one.
> 
> True. The question is why they need this info? Perhaps we can just lie
> and simply say 2.6.x?

ive noticed this in all my builds, but ive just ignored it.  it isnt a matter 
of picking "linux 2.6" over "linux 2.4".  you simply need to pick linux-2.x 
over linux-1.x or linux-0.x.  we've long used this in Gentoo/uclinux-dist:
	export ac_cv_linux_vers=2
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110124/1881ed86/attachment.asc>

[Buildroot] [PATCH 1/4] libpcap: update static handling

[Mike Frysinger]

On Monday, January 24, 2011 11:16:42 Thomas Petazzoni wrote:
> On Sun, 23 Jan 2011 16:07:30 -0500 Mike Frysinger wrote:
> > hmm, well Thomas' suggestion before doesnt work ... the current autotools
> > Makefile only adds $(PKG)_MAKE_OPT to the build step instead of all the
> > steps. so ignore this patch until that can be fixed.
> 
> For the moment:
> 
>  $(PKG)_MAKE_OPT is passed at build time for target and host packages
>  (maybe we should rename it $(PKG)_BUILD_MAKE_OPT, or pass it during all
>  steps)
> 
>  $(PKG)_INSTALL_STAGING_OPT is passed at staging installation time for
>  target packages
> 
>  $(PKG)_INSTALL_TARGET_OPT is passed at target installation time for
>  target packages
> 
> So in your case you probably need to do something like:
> 
> LIBPCAP_INSTALL_STAGING_OPT = DYEXT=none DESTDIR="$(STAGING_DIR)" install
> LIBPCAP_INSTALL_TARGET_OPT  = DYEXT=none DESTDIR="$(TARGET_DIR)" install

yes, that would make it work, but that just makes me want to cry.  it makes a 
lot more sense imo to have $(PKG)_MAKE_OPT be passed for all steps (and 
grepping the tree doesnt show any cases where this would be a problem).  if 
people still want a hook specific to the build step, then it'd make sense to 
add $(PKG)_BUILD_OPT or something similiar.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110124/29accfff/attachment.asc>

[Buildroot] [PATCH 1/4] libpcap: update static handling

[Peter Korsgaard]

>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:

 >> LIBPCAP_INSTALL_STAGING_OPT = DYEXT=none DESTDIR="$(STAGING_DIR)" install
 >> LIBPCAP_INSTALL_TARGET_OPT  = DYEXT=none DESTDIR="$(TARGET_DIR)" install

 Mike> yes, that would make it work, but that just makes me want to cry.
 Mike> it makes a lot more sense imo to have $(PKG)_MAKE_OPT be passed
 Mike> for all steps (and grepping the tree doesnt show any cases where
 Mike> this would be a problem).  if people still want a hook specific
 Mike> to the build step, then it'd make sense to add $(PKG)_BUILD_OPT
 Mike> or something similiar.

Yeah, similar to the recent patch to pass $PKG_MAKE_ENV for host
packages Thomas sent earlier today.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/4] libpcap: update static handling

[Thomas Petazzoni]

On Mon, 24 Jan 2011 16:48:15 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> yes, that would make it work, but that just makes me want to cry.  it makes a 
> lot more sense imo to have $(PKG)_MAKE_OPT be passed for all steps (and 
> grepping the tree doesnt show any cases where this would be a problem).  if 
> people still want a hook specific to the build step, then it'd make sense to 
> add $(PKG)_BUILD_OPT or something similiar.

Yes, this makes sense.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110125/60578555/attachment.asc>

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

The following changes since commit 9f31e2ffa005095206824e08f69da75503e998ab:

  busybox: 1.18.2 fixes for ping, tar and udhcp (2011-02-06 21:48:53 +0100)

are available in the git repository at:
  git://sources.blackfin.uclinux.org/git/users/vapier/buildroot.git vapier

Mike Frysinger (3):
      debugging: do not require no stripping
      initial support for Blackfin processors
      gdb: add support for Blackfin gdbserver

 Config.in                                      |    4 +-
 Makefile                                       |    1 +
 boot/u-boot/Config.in                          |    4 +
 boot/u-boot/u-boot.mk                          |    2 +
 linux/Config.in                                |    2 +-
 linux/linux.mk                                 |    5 +
 target/Config.in.arch                          |   19 ++-
 toolchain/gdb/6.6/gdb-6.6-bfin-gdbserver.patch |  238 ++++++++++++++++++++++++
 toolchain/gdb/Config.in                        |    7 +-
 toolchain/toolchain-common.in                  |    2 +-
 10 files changed, 276 insertions(+), 8 deletions(-)
 create mode 100644 toolchain/gdb/6.6/gdb-6.6-bfin-gdbserver.patch

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

The following changes since commit 54942318f93b12f8166f110905ec7df6e3279a74:

  pciutils: SHARED make opt goes for install too (2011-01-10 14:52:02 +0100)

are available in the git repository at:
  git://sources.blackfin.uclinux.org/git/users/vapier/buildroot.git vapier

Mike Frysinger (7):
      busybox: unify duplicated build steps
      busybox: let buildroot handle stripping
      toolchain: add a USE_MMU build option
      portmap: add nommu support
      portmap: respect target CFLAGS
      portmap: fix clean target to actually clean
      tcpdump: add patch for nommu systems

 package/busybox/busybox.mk                         |   30 ++---
 ...0-0001-README-fix-typo-in-tcp-wrapper-doc.patch |   26 ++++
 ...0002-NO_PIE-make-PIE-support-controllable.patch |   53 ++++++++
 ...K-control-usage-of-fork-for-nommu-systems.patch |  110 +++++++++++++++++
 ...ERROR-control-overriding-of-perror-symbol.patch |   46 +++++++
 package/portmap/portmap.mk                         |   12 ++-
 package/tcpdump/tcpdump-4.1.1-vfork.patch          |  128 ++++++++++++++++++++
 toolchain/helpers.mk                               |    2 +
 toolchain/toolchain-common.in                      |    7 +
 9 files changed, 396 insertions(+), 18 deletions(-)
 create mode 100644 package/portmap/portmap-6.0-0001-README-fix-typo-in-tcp-wrapper-doc.patch
 create mode 100644 package/portmap/portmap-6.0-0002-NO_PIE-make-PIE-support-controllable.patch
 create mode 100644 package/portmap/portmap-6.0-0003-NO_FORK-control-usage-of-fork-for-nommu-systems.patch
 create mode 100644 package/portmap/portmap-6.0-0004-NO_PERROR-control-overriding-of-perror-symbol.patch
 create mode 100644 package/tcpdump/tcpdump-4.1.1-vfork.patch

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

On Tuesday, December 07, 2010 16:48:02 Peter Korsgaard wrote:
> >>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:
>  >> And as this will be most packages
> 
>  Mike> what are you basing this on ?  this isnt my experience at all.
> 
> Nothing but gut feeling. I would expect lots of packages use fork() or
> similar.

fork() is common, but the vast majority of the time it's to do an exec which 
makes them trivial to convert to vfork().  realistically, build problems with 
uClibc vs glibc tend to be more common.

> Out of interest, what packages are you using on nommu?

i've played doom on my hardware, made video/voip calls via linphone, browsed 
the web with qt/webkit, and served web pages from sqlite/php (to name a few).  
we treat it as a generic Linux platform like any other arch rather than 
pigeonhole it as a "firewall" or something.  i dont really keep track as it'd 
kind of be like asking what packages have i used on an mmu.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101207/df1edd4b/attachment.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Peter Korsgaard]

>>>>> "Mike" == Mike Frysinger <vapier@gentoo.org> writes:

 >> And as this will be most packages

 Mike> what are you basing this on ?  this isnt my experience at all.

Nothing but gut feeling. I would expect lots of packages use fork() or
similar.

Out of interest, what packages are you using on nommu?

-- 
Bye, Peter Korsgaard

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

On Tuesday, December 07, 2010 07:28:14 Peter Korsgaard wrote:
>  Thomas> Those two sets of packages are not identical, that's why I
>  Thomas> proposed two different options. A package that doesn't support
>  Thomas> static build should do:
>  Thomas> 	depends on !BR2_PREFER_STATIC_LIB
>  Thomas> and all packages that do not work on !MMU should do
>  Thomas> 	depends on BR2_USE_MMU
> 
> And as this will be most packages

what are you basing this on ?  this isnt my experience at all.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101207/ec477bb9/attachment.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Thomas Petazzoni]

On Tue, 07 Dec 2010 13:28:14 +0100
Peter Korsgaard <jacmet@uclibc.org> wrote:

> And as this will be most packages, we should probably do something
> like BR2_PACKAGE_BUSYBOX_SHOW_OTHERS - E.G. add this dependency in
> package/Config.in instead of moving it down to each individual
> package.

I don't think we should do that. With three options to handle
(BUSYBOX_SHOW_OTHERS, USE_MMU and PREFER_STATIC_LIB), the
package/Config.in is going to become a nightmare to read, and the fact
that the current if's in package/Config.in can be common to several
packages will be very reduced because of the three conditions.

On the opposite, I would have suggested to move these to the
per-package Config.in. Yes, it's a bit more code, but it's not a big
deal, and will make it easier to maintain.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Pull request buildroot.git (vapier branch)

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 Thomas> Those two sets of packages are not identical, that's why I
 Thomas> proposed two different options. A package that doesn't support
 Thomas> static build should do:

 Thomas> 	depends on !BR2_PREFER_STATIC_LIB

 Thomas> and all packages that do not work on !MMU should do

 Thomas> 	depends on BR2_USE_MMU

And as this will be most packages, we should probably do something like
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS - E.G. add this dependency in
package/Config.in instead of moving it down to each individual package.

-- 
Bye, Peter Korsgaard

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

On Monday, December 06, 2010 15:44:05 Thomas Petazzoni wrote:
> On Mon, 6 Dec 2010 15:20:47 -0500 Mike Frysinger wrote:
> > > > > >       irda-utils: new package for IrDA devices
> > > > > 
> > > > > I know Peter wants a short description + author in each patch. Your
> > > > > patches are fairly obvious, but that's the rule :)
> > > > 
> > > > i dont know what you mean by author.  git already tracks authorship.
> > > 
> > > Peter still wants the patch we have in Buildroot to carry a description
> > > and an author. The author of the patch may not be the person who
> > > imported it into Buildroot.
> > 
> > when using `git am` or `git pull`, it does retain authorship.  i dont see
> > how the changeset would make it into the tree unless people were
> > manually doing `patch && git commit`.
> 
> I'm not talking about the patches you are sending to Buildroot, but the
> patches that are added to packages (i.e patches inside the patches).

oh, i missed that.  i wrote these patches and sent them upstream.  i'll add 
that metadata.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101206/0d78bc53/attachment.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Thomas Petazzoni]

Hello,

On Mon, 6 Dec 2010 15:20:47 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> considering i'm one of the authors, i'd rather fix pax-utils upstream.  i see 
> no reason for it to be using glob64 code considering we build with _GNU_SOURCE 
> which implies LFS which transparently rewrites glob to glob64 with glibc.

Ok. Here is what I have with my !LARGEFILE toolchain:

/home/test/toolchains/br-arm-basic/usr/bin/arm-linux-gcc --sysroot=/home/test/outputs/pax/staging -Os -mabi=aapcs-linux -msoft-float -D_GNU_SOURCE -o scanelf.o -c scanelf.c
scanelf.c: In function 'load_ld_cache_config':
scanelf.c:1597: error: 'glob64_t' undeclared (first use in this function)
scanelf.c:1597: error: (Each undeclared identifier is reported only once
scanelf.c:1597: error: for each function it appears in.)
scanelf.c:1597: error: expected ';' before 'gl'
scanelf.c:1598: warning: ISO C90 forbids mixed declarations and code
scanelf.c:1608: warning: implicit declaration of function 'glob64'
scanelf.c:1608: warning: nested extern declaration of 'glob64'
scanelf.c:1608: error: 'gl' undeclared (first use in this function)
scanelf.c:1615: warning: implicit declaration of function 'globfree64'
scanelf.c:1615: warning: nested extern declaration of 'globfree64'
make[1]: *** [scanelf.o] Error 1

> > > redhat takes the general position that network daemons be compiled as
> > > PIEs. since the portmap maintainer is a redhat employee, he put it
> > > into the portmap build system instead of keeping it in the redhat
> > > spec.  glibc does the same thing.
> > 
> > Ok, thanks. Do you what's the reasoning behind compiling all network
> > daemons as PIE ? Is it because of some address space randomization
> > feature ?
> 
> i'm fairly certain that is why.  if it werent built as a PIE, then using ASLR 
> would cause unsharable mappings, and that can quickly suck up resources.

Ok, thanks.

> > > > Have you pushed the patches upstream ?
> > > 
> > > of course, but the maintainer hasnt updated things in a while.
> > > probably because people are moving to rpcbind.
> > 
> > Should we as well ?
> 
> the rpcbind stack isnt as friendly (yet) to uClibc.  so it might be an OK 
> future plan, but today it wont work out of the box.  and i dont have personal 
> interest to get it resolved today.

Ok. I am personally not that familiar with portmap/rpcbind.

> > > > >       irda-utils: new package for IrDA devices
> > > > 
> > > > I know Peter wants a short description + author in each patch. Your
> > > > patches are fairly obvious, but that's the rule :)
> > > 
> > > i dont know what you mean by author.  git already tracks authorship.
> > 
> > Peter still wants the patch we have in Buildroot to carry a description
> > and an author. The author of the patch may not be the person who
> > imported it into Buildroot.
> 
> when using `git am` or `git pull`, it does retain authorship.  i dont see how 
> the changeset would make it into the tree unless people were manually doing 
> `patch && git commit`.

I'm not talking about the patches you are sending to Buildroot, but the
patches that are added to packages (i.e patches inside the patches).

For Buildroot patches, obviously Git tracks everything. But not for
the individual package/*/*.patch, which can come from various sources.

> > Ok. I think we generally want Buildroot to make a working build when
> > used out-of-the-box. I.e, without using any defconfig, if the user does
> > "make menuconfig", selects "blackfin" and then exits, the build should
> > be working. I think Peter quite likes this rule. But for the blackfin
> > case, we can probably discuss how to solve this later.
> 
> well, it wont be specific to Blackfin, and would probably require digging down 
> into mmu/nommu specific options in things like busybox.

Yes, it is definitely not Blackfin specific, and is a problem all !MMU
arches would have. But again, we could solve it at a later time, I
don't see that as a problem to get the Blackfin arch support merged.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101206/24d28f36/attachment.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

On Monday, December 06, 2010 14:39:10 Thomas Petazzoni wrote:
> On Mon, 6 Dec 2010 02:50:01 -0500 Mike Frysinger wrote:
> > > Moreover, pax-utils requires LARGEFILE support, so you have to do
> > 
> > > the usual stuff in the Config.in file:
> > why do you say this ?
> 
> Because when you build it with a toolchain that doesn't support
> LARGEFILE you have undefined references to glob64_t. It can probably be
> fixed in pax-utils itself, but when we don't want to fix it, we just
> mark the package as depending on LARGEFILE.

considering i'm one of the authors, i'd rather fix pax-utils upstream.  i see 
no reason for it to be using glob64 code considering we build with _GNU_SOURCE 
which implies LFS which transparently rewrites glob to glob64 with glibc.

> > > >       portmap: add nommu support
> > > 
> > > Just curious: why was portmap compiled PIE ?
> > 
> > redhat takes the general position that network daemons be compiled as
> > PIEs. since the portmap maintainer is a redhat employee, he put it
> > into the portmap build system instead of keeping it in the redhat
> > spec.  glibc does the same thing.
> 
> Ok, thanks. Do you what's the reasoning behind compiling all network
> daemons as PIE ? Is it because of some address space randomization
> feature ?

i'm fairly certain that is why.  if it werent built as a PIE, then using ASLR 
would cause unsharable mappings, and that can quickly suck up resources.

> > > Have you pushed the patches upstream ?
> > 
> > of course, but the maintainer hasnt updated things in a while.
> > probably because people are moving to rpcbind.
> 
> Should we as well ?

the rpcbind stack isnt as friendly (yet) to uClibc.  so it might be an OK 
future plan, but today it wont work out of the box.  and i dont have personal 
interest to get it resolved today.

> > > >       irda-utils: new package for IrDA devices
> > > 
> > > I know Peter wants a short description + author in each patch. Your
> > > patches are fairly obvious, but that's the rule :)
> > 
> > i dont know what you mean by author.  git already tracks authorship.
> 
> Peter still wants the patch we have in Buildroot to carry a description
> and an author. The author of the patch may not be the person who
> imported it into Buildroot.

when using `git am` or `git pull`, it does retain authorship.  i dont see how 
the changeset would make it into the tree unless people were manually doing 
`patch && git commit`.

> > > I tested the Blackfin support (well only the build part of it,
> > > since I don't have hardware to test), and I had a few issues with
> > > the default Busybox configuration:
> > 
> > which are all fixed by another patch i have which adds defconfigs for
> > Blackfin boards.  fixing the default defconfig makes no sense to me
> > so i'm not going to spend time on it.
> 
> Ok. I think we generally want Buildroot to make a working build when
> used out-of-the-box. I.e, without using any defconfig, if the user does
> "make menuconfig", selects "blackfin" and then exits, the build should
> be working. I think Peter quite likes this rule. But for the blackfin
> case, we can probably discuss how to solve this later.

well, it wont be specific to Blackfin, and would probably require digging down 
into mmu/nommu specific options in things like busybox.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101206/b479194e/attachment-0001.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

On Monday, December 06, 2010 14:27:54 Thomas Petazzoni wrote:
> I didn't mean those two things to be bound together. But it's well
> known that :
> 
>  * Some packages do not support static build
> 
>  * Some packages do not support no-MMU
> 
> Those two sets of packages are not identical, that's why I proposed two
> different options. A package that doesn't support static build should
> do:
> 
> 	depends on !BR2_PREFER_STATIC_LIB
> 
> and all packages that do not work on !MMU should do
> 
> 	depends on BR2_USE_MMU
> 
> My intention is that users can't mistakenly select packages that do not
> build statically and/or do not work on !MMU systems.

i follow now.  this makes sense to me.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101206/d379ac60/attachment.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Thomas Petazzoni]

Hello,

On Mon, 6 Dec 2010 02:50:01 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> i dont know what you mean by "earlier versions".  these all should be
> the exact same version as i already posted in the past.  if people
> had feedback on the patches, i'd of expected them to be given at the
> time of patch posting.

I know those were the same, but it really make things easier if patches
come together with the pull request, to ease the review process, even
if they have been posted previously.

> > >       pax-utils: new package
> > 
> > I know you're going to say that it's more lines, it's stupid and so
> > on,
> 
> you're right

I know :-)

> > Moreover, pax-utils requires LARGEFILE support, so you have to do
> > the usual stuff in the Config.in file:
> 
> why do you say this ?

Because when you build it with a toolchain that doesn't support
LARGEFILE you have undefined references to glob64_t. It can probably be
fixed in pax-utils itself, but when we don't want to fix it, we just
mark the package as depending on LARGEFILE.

> > >       busybox: unify duplicated build steps
> > 
> > I'd very much prefer something like:
> > 
> > BUSYBOX_MAKE_OPTS = ...
> 
> i'll take a look

Thanks!

> > >       busybox: let buildroot handle stripping
> > 
> > I'm obviously ok on the principle, but we'll have to keep updating
> > the patch directory and patch name everytime we bump busybox (which
> > happens quite often). Considering the simple change, wouldn't a
> > $(SED) call directly in busybox.mk be more future-proof ? Or
> > better, get this patch merged into Busybox. Anyway, this can be
> > decided later, so:
> 
> it's already been merged upstream

Great.

> > >       linux: support unpacked source trees
> > 
> > This is a useful feature, but we want to introduce it globally for
> > all packages, not only for the Linux kernel. This needs some
> > thoughts on what it should look like, how it should be presented to
> > users, how it should work.
> > 
> > Could you remove this patch from the patch set, but keep the idea
> > around ?
> 
> maybe i'm pessimistic, but i doubt that general support will be done
> in a reasonable time frame.  thus wouldnt it make sense to merge this
> and once someone does put together common code, switch the Linux one
> over to it ?

You're probably right, it'll take some time for us to do this
generally. My position is that in the past too much specific stuff has
been added in Buildroot, offering sometimes duplicate functionality,
and that we should try to avoid that in the future. I just offered my
position on this, but I'm not the Buildroot maintainer, so Peter's
position might be different.

However, as this is a bit controversial, in order to ease the
integration of your patch set, you may want to remove this patch from
this branch, get all the other patches merged, and then try again with
this particular patch only separatly.

> > >       toolchain: add a USE_MMU build option
> > 
> > It doesn't work, the uClibc define is __ARCH_USE_MMU__ and not
> > __UCLIBC_USE_MMU_. This commit will have to be changed when my
> > toolchain-improvements patch set goes in, but maybe your patch
> > series will go first (I don't care). Whichever happens, either you
> > or me will have to fix something :-)
> 
> copy & paste i guess from the other options

Sure, just minor comment after review/testing.

> > >       portmap: add nommu support
> > 
> > Just curious: why was portmap compiled PIE ?
> 
> redhat takes the general position that network daemons be compiled as
> PIEs. since the portmap maintainer is a redhat employee, he put it
> into the portmap build system instead of keeping it in the redhat
> spec.  glibc does the same thing.

Ok, thanks. Do you what's the reasoning behind compiling all network
daemons as PIE ? Is it because of some address space randomization
feature ?

> > Have you pushed the patches upstream ?
> 
> of course, but the maintainer hasnt updated things in a while.
> probably because people are moving to rpcbind.

Should we as well ?

> > >       portmap: respect target CFLAGS
> > 
> > Why not after $(MAKE), like CC= ?
> 
> because it will override settings in the portmap make.  setting vars
> via the env and via the command line do not have the same semantics
> in make.

Yes, makes sense;

> > >       irda-utils: new package for IrDA devices
> > 
> > I know Peter wants a short description + author in each patch. Your
> > patches are fairly obvious, but that's the rule :)
> 
> i dont know what you mean by author.  git already tracks authorship.

Peter still wants the patch we have in Buildroot to carry a description
and an author. The author of the patch may not be the person who
imported it into Buildroot.

> > >       libpcap: update static handling
> > 
> > Could you use LIBPCAP_MAKE_OPT instead ?
> 
> i wasnt aware of that, but i guess it should work

No problem. This is one of the few things that is actually documented
in the Buildroot documentation :-)

> > >       toolchain-external: allow vendor-controlled defaults
> > 
> > I think this could be done with the "toolchain profile" mechanism I
> > proposed in the toolchain-improvements patch set I posted this
> > morning. Could you remove this patch for this patch series, so that
> > we can handle this later ? Thanks!
> 
> i'll take a look

Great thanks. I think it should work reasonably well with Blackfin
toolchains, adding the optional capability of having Buildroot
download/install the toolchain for the user if (s)he wants to. The only
thing I see problematic is that Blackfin toolchains are typically
shipped in two separate tarballs, so a little bit of hacking in
ext-tool.mk might be needed, but nothing that looks impossible.

> > >       target-finalize: punt config scripts too
> > 
> > No. What if a package really wants to install a binary called
> > foobar-config that must be kept on the target ? I know it's
> > unlikely, but I'd prefer not to have this policy at the global
> > level. Just do what other packages do: add a post install hook that
> > removes the pcap-config file.
> 
> can you name a package that does this ?  i havent seen one.

No, I can't name a package that does this. I'd just prefer to be
cautious.

> > I tested the Blackfin support (well only the build part of it,
> > since I don't have hardware to test), and I had a few issues with
> > the default Busybox configuration:
> 
> which are all fixed by another patch i have which adds defconfigs for
> Blackfin boards.  fixing the default defconfig makes no sense to me
> so i'm not going to spend time on it.

Ok. I think we generally want Buildroot to make a working build when
used out-of-the-box. I.e, without using any defconfig, if the user does
"make menuconfig", selects "blackfin" and then exits, the build should
be working. I think Peter quite likes this rule. But for the blackfin
case, we can probably discuss how to solve this later.

> > Another (unrelated) question: when using the Blackfin toolchains, I
> > found out that the linker needs zlib installed on the host, but it
> > isn't the case with the other toolchains I have. What feature of ld
> > requires zlib ?
> 
> it isnt ld, it's elf2flt-ld.  and elf2flt supports compression via
> the ZFLAT format.  although in newer binutils, they have added
> support for compressed debug sections which does require zlib in misc
> utils such as ld ... -mike

Ah, ok, good to know.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101206/f3ca4286/attachment.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Thomas Petazzoni]

On Mon, 6 Dec 2010 01:56:52 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> On Sunday, December 05, 2010 07:19:52 Thomas Petazzoni wrote:
> > Yet another question regarding non-MMU support and support for
> > static builds in Buildroot. Obviously, not all packages support
> > non-MMU architectures and/or static build, so it'd be good to not
> > allow the users to select those packages. So the packages known to
> > work for non-MMU and/or static build should be clearly identified.
> 
> you can do shared libs under nommu systems.  binding the two makes no
> sense.

I know you can do shared libs with no-MMU systems, I've already used
FDPIC on Blackfin, thanks.

I didn't mean those two things to be bound together. But it's well
known that :

 * Some packages do not support static build

 * Some packages do not support no-MMU

Those two sets of packages are not identical, that's why I proposed two
different options. A package that doesn't support static build should
do:

	depends on !BR2_PREFER_STATIC_LIB

and all packages that do not work on !MMU should do

	depends on BR2_USE_MMU

My intention is that users can't mistakenly select packages that do not
build statically and/or do not work on !MMU systems.

Is this more clear ?

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101206/fd256e41/attachment.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

On Sunday, December 05, 2010 05:57:45 Thomas Petazzoni wrote:
> Here is a review of your patches, comments below. Next time, it'd be
> great if you could post the patches together with the pull request. I
> know you have posted some earlier versions of them in the past, but
> it's good to see them with every pull request, IMO, as it makes the
> review process easier.

i dont know what you mean by "earlier versions".  these all should be the 
exact same version as i already posted in the past.  if people had feedback on 
the patches, i'd of expected them to be given at the time of patch posting.

> >       u-boot: version bump to 2010.09
> 
> I already carry this change in my for-2011.02/boards-cleanup branch, as
> I said previously. I don't care which one gets merged, either you or me
> will fix his patch series depending on which one goes in first. Is this
> ok for you ?

doesnt matter to me

> >       pax-utils: new package
> 
> I know you're going to say that it's more lines, it's stupid and so on,

you're right

> Moreover, pax-utils requires LARGEFILE support, so you have to do the
> usual stuff in the Config.in file:

why do you say this ?

> >       busybox: unify duplicated build steps
> 
> I'd very much prefer something like:
> 
> BUSYBOX_MAKE_OPTS = ...

i'll take a look

> >       busybox: let buildroot handle stripping
> 
> I'm obviously ok on the principle, but we'll have to keep updating the
> patch directory and patch name everytime we bump busybox (which happens
> quite often). Considering the simple change, wouldn't a $(SED) call
> directly in busybox.mk be more future-proof ? Or better, get this patch
> merged into Busybox. Anyway, this can be decided later, so:

it's already been merged upstream

> >       linux: support unpacked source trees
> 
> This is a useful feature, but we want to introduce it globally for all
> packages, not only for the Linux kernel. This needs some thoughts on
> what it should look like, how it should be presented to users, how it
> should work.
> 
> Could you remove this patch from the patch set, but keep the idea
> around ?

maybe i'm pessimistic, but i doubt that general support will be done in a 
reasonable time frame.  thus wouldnt it make sense to merge this and once 
someone does put together common code, switch the Linux one over to it ?

> >       toolchain: add a USE_MMU build option
> 
> It doesn't work, the uClibc define is __ARCH_USE_MMU__ and not
> __UCLIBC_USE_MMU_. This commit will have to be changed when my
> toolchain-improvements patch set goes in, but maybe your patch series
> will go first (I don't care). Whichever happens, either you or me will
> have to fix something :-)

copy & paste i guess from the other options

> >       portmap: add nommu support
> 
> Just curious: why was portmap compiled PIE ?

redhat takes the general position that network daemons be compiled as PIEs.  
since the portmap maintainer is a redhat employee, he put it into the portmap 
build system instead of keeping it in the redhat spec.  glibc does the same 
thing.

> Have you pushed the patches upstream ?

of course, but the maintainer hasnt updated things in a while.  probably 
because people are moving to rpcbind.

> >       portmap: respect target CFLAGS
> 
> Why not after $(MAKE), like CC= ?

because it will override settings in the portmap make.  setting vars via the 
env and via the command line do not have the same semantics in make.

> >       irda-utils: new package for IrDA devices
> 
> I know Peter wants a short description + author in each patch. Your
> patches are fairly obvious, but that's the rule :)

i dont know what you mean by author.  git already tracks authorship.

> >       libpcap: update static handling
> 
> Could you use LIBPCAP_MAKE_OPT instead ?

i wasnt aware of that, but i guess it should work

> >       toolchain-external: allow vendor-controlled defaults
> 
> I think this could be done with the "toolchain profile" mechanism I
> proposed in the toolchain-improvements patch set I posted this morning.
> Could you remove this patch for this patch series, so that we can
> handle this later ? Thanks!

i'll take a look

> >       target-finalize: punt config scripts too
> 
> No. What if a package really wants to install a binary called
> foobar-config that must be kept on the target ? I know it's unlikely,
> but I'd prefer not to have this policy at the global level. Just do
> what other packages do: add a post install hook that removes the
> pcap-config file.

can you name a package that does this ?  i havent seen one.

> I tested the Blackfin support (well only the build part of it, since I
> don't have hardware to test), and I had a few issues with the default
> Busybox configuration:

which are all fixed by another patch i have which adds defconfigs for Blackfin 
boards.  fixing the default defconfig makes no sense to me so i'm not going to 
spend time on it.

> Another (unrelated) question: when using the Blackfin toolchains, I
> found out that the linker needs zlib installed on the host, but it
> isn't the case with the other toolchains I have. What feature of ld
> requires zlib ?

it isnt ld, it's elf2flt-ld.  and elf2flt supports compression via the ZFLAT 
format.  although in newer binutils, they have added support for compressed 
debug sections which does require zlib in misc utils such as ld ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101206/e6b33314/attachment.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

On Sunday, December 05, 2010 07:19:52 Thomas Petazzoni wrote:
> Yet another question regarding non-MMU support and support for static
> builds in Buildroot. Obviously, not all packages support non-MMU
> architectures and/or static build, so it'd be good to not allow the
> users to select those packages. So the packages known to work for
> non-MMU and/or static build should be clearly identified.

you can do shared libs under nommu systems.  binding the two makes no sense.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101206/11eb6c56/attachment-0001.pgp>

[Buildroot] Pull request buildroot.git (vapier branch)

[Thomas Petazzoni]

Mike,

On Sun, 5 Dec 2010 11:57:45 +0100
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> Another (unrelated) question: when using the Blackfin toolchains, I
> found out that the linker needs zlib installed on the host, but it
> isn't the case with the other toolchains I have. What feature of ld
> requires zlib ?

Yet another question regarding non-MMU support and support for static
builds in Buildroot. Obviously, not all packages support non-MMU
architectures and/or static build, so it'd be good to not allow the
users to select those packages. So the packages known to work for
non-MMU and/or static build should be clearly identified.

So, what about adding:

	depends on BR2_USE_MMU
	depends on !BR2_PREFER_STATIC_LIB

on all packages, except those that have been validated to work in those
two conditions ?

Of course, it means adding those two depends on lines to a lot of
packages, but I don't see a way of doing the opposite with the kconfig
language.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Pull request buildroot.git (vapier branch)

[Thomas Petazzoni]

Hello Mike,

Here is a review of your patches, comments below. Next time, it'd be
great if you could post the patches together with the pull request. I
know you have posted some earlier versions of them in the past, but
it's good to see them with every pull request, IMO, as it makes the
review process easier.

On Sat,  4 Dec 2010 17:52:01 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

>       m4: version bump to 1.4.15

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       xz: version bump to 5.0.0

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       u-boot: version bump to 2010.09

I already carry this change in my for-2011.02/boards-cleanup branch, as
I said previously. I don't care which one gets merged, either you or me
will fix his patch series depending on which one goes in first. Is this
ok for you ?

>       rsh-redone: new package for rsh/rlogin clients

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       whetstone: new benchmark package

I really don't like the override of the .stamp_extracted step, but
since the software packaging is strange and we don't have support for
such packaging in the infrastructure for the moment:

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       dhrystone: new benchmark package

Same thing here for the override of the .stamp_extracted step, but for
the same reason:

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       lsuio: new UIO helper package

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       pax-utils: new package

Here, I'm sorry but I don't like the cleverness of your
_PAX_UTILS_INSTALL_TARGET_CMDS and _PAX_UTILS_UNINSTALL_TARGET_CMDS.
Could you please make this :

+define HOST_PAX_UTILS_INSTALL_CMDS
+       $(MAKE) -C $(@D) install DESTDIR=$(HOST_DIR)
+endef
+define PAX_UTILS_INSTALL_TARGET_CMDS
+       $(MAKE) -C $(@D) install DESTDIR=$(TARGET_DIR)
+endef

And ditto for the uninstall thing ? (The list of files to remove can be
shared using a variable, though).

I know you're going to say that it's more lines, it's stupid and so on,
but I really thing it's more straightforward to read written this way.

Moreover, pax-utils requires LARGEFILE support, so you have to do the
usual stuff in the Config.in file:

diff --git a/package/pax-utils/Config.in b/package/pax-utils/Config.in
index 76eab6f..d676ca7 100644
--- a/package/pax-utils/Config.in
+++ b/package/pax-utils/Config.in
@@ -1,6 +1,10 @@
 config BR2_PACKAGE_PAX_UTILS
        bool "pax-utils"
+       depends on BR2_LARGEFILE
        help
          ELF related utils to make scripting of ELFs easier
 
          http://hardened.gentoo.org/pax-utils.xml
+
+comment "pax-utils requires a toolchain with LARGEFILE support"
+       depends on !BR2_LARGEFILE

>       busybox: unify duplicated build steps

I'd very much prefer something like:

BUSYBOX_MAKE_OPTS =                       \
	CC="$(TARGET_CC)"                 \
	ARCH=$(KERNEL_ARCH)               \
	PREFIX="$(TARGET_DIR)"            \
	EXTRA_LDFLAGS="$(TARGET_LDFLAGS)" \
	CROSS_COMPILE="$(TARGET_CROSS)"   \
	CONFIG_PREFIX="$(TARGET_DIR)"

And then:

define BUSYBOX_BUILD_CMDS
	$(BUSYBOX_MAKE_ENV) $(MAKE) $(BUSYBOX_MAKE_OPTS) -C $(@D)
endef

define BUSYBOX_INSTALL_BINARY
	$(BUSYBOX_MAKE_ENV) $(MAKE) $(BUSYBOX_MAKE_OPTS) -C $(@D) install
endef

I know it's a little bit more code, but it's how we do it in other
packages, so I'd prefer to be consistent.

>       busybox: let buildroot handle stripping

I'm obviously ok on the principle, but we'll have to keep updating the
patch directory and patch name everytime we bump busybox (which happens
quite often). Considering the simple change, wouldn't a $(SED) call
directly in busybox.mk be more future-proof ? Or better, get this patch
merged into Busybox. Anyway, this can be decided later, so:

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       linux: support unpacked source trees

This is a useful feature, but we want to introduce it globally for all
packages, not only for the Linux kernel. This needs some thoughts on
what it should look like, how it should be presented to users, how it
should work.

Could you remove this patch from the patch set, but keep the idea
around ?

>       linux: drop LDFLAGS override

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       linux: add shorter shortcuts

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       linux: set a few more initramfs opts for newer kernels

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       toolchain: add a USE_MMU build option

It doesn't work, the uClibc define is __ARCH_USE_MMU__ and not
__UCLIBC_USE_MMU_. This commit will have to be changed when my
toolchain-improvements patch set goes in, but maybe your patch series
will go first (I don't care). Whichever happens, either you or me will
have to fix something :-)

Once the __ARCH_USE_MMU__ thing is fixed, you get my:

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       portmap: add nommu support

Just curious: why was portmap compiled PIE ? Have you pushed the
patches upstream ?

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       portmap: respect target CFLAGS

Why not after $(MAKE), like CC= ?

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       portmap: fix clean target to actually clean

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       irda-utils: new package for IrDA devices

I know Peter wants a short description + author in each patch. Your
patches are fairly obvious, but that's the rule :)

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       libpcap: update static handling

Could you use LIBPCAP_MAKE_OPT instead ?

>       tcpdump: add patch for nommu systems

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       debugging: do not require no stripping

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       initial support for Blackfin processors

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       gdb: add support for Blackfin gdbserver

You already had my Acked-by on that one.

>       toolchain-external: allow vendor-controlled defaults

I think this could be done with the "toolchain profile" mechanism I
proposed in the toolchain-improvements patch set I posted this morning.
Could you remove this patch for this patch series, so that we can
handle this later ? Thanks!

>       add support for common ABI options (for FLAT)

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       TARGET_CFLAGS: convert to kbuild-y style

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

>       target-finalize: punt config scripts too

No. What if a package really wants to install a binary called
foobar-config that must be kept on the target ? I know it's unlikely,
but I'd prefer not to have this policy at the global level. Just do
what other packages do: add a post install hook that removes the
pcap-config file.

I tested the Blackfin support (well only the build part of it, since I
don't have hardware to test), and I had a few issues with the default
Busybox configuration:

 * shadow password not supported by the C library shipped in the
   Blackfin toolchain. So either shadow password support should be
   disabled in Busybox, or internal Busybox shadow functions should be
   used.

 * ash is selected, but doesn't not work on !MMU. hush should be
   selected instead.

 * swaponoff does not build.

Maybe package/busybox/busybox.mk should tune the busybox config file to
adjust these options, so that the default Busybox build works for the
user ? Or should we ship a completely different busybox configuration
file for !MMU systems ?

Another (unrelated) question: when using the Blackfin toolchains, I
found out that the linker needs zlib installed on the host, but it
isn't the case with the other toolchains I have. What feature of ld
requires zlib ?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

The following changes since commit 7e9c3a387820154fd1355f23c2669072c0c3a5f7:

  docs/news.html: add 2010.11 announce link (2010-11-30 19:50:04 +0100)

are available in the git repository at:
  git://sources.blackfin.uclinux.org/git/users/vapier/buildroot.git vapier

Mike Frysinger (28):
      m4: version bump to 1.4.15
      xz: version bump to 5.0.0
      u-boot: version bump to 2010.09
      rsh-redone: new package for rsh/rlogin clients
      whetstone: new benchmark package
      dhrystone: new benchmark package
      lsuio: new UIO helper package
      pax-utils: new package
      busybox: unify duplicated build steps
      busybox: let buildroot handle stripping
      linux: support unpacked source trees
      linux: drop LDFLAGS override
      linux: add shorter shortcuts
      linux: set a few more initramfs opts for newer kernels
      toolchain: add a USE_MMU build option
      portmap: add nommu support
      portmap: respect target CFLAGS
      portmap: fix clean target to actually clean
      irda-utils: new package for IrDA devices
      libpcap: update static handling
      tcpdump: add patch for nommu systems
      debugging: do not require no stripping
      initial support for Blackfin processors
      gdb: add support for Blackfin gdbserver
      toolchain-external: allow vendor-controlled defaults
      add support for common ABI options (for FLAT)
      TARGET_CFLAGS: convert to kbuild-y style
      target-finalize: punt config scripts too

 Config.in                                          |    4 +-
 Makefile                                           |    3 +-
 boot/u-boot/Config.in                              |   10 +-
 boot/u-boot/u-boot.mk                              |    2 +
 docs/README                                        |    2 +-
 docs/buildroot.html                                |    2 +-
 linux/Config.in                                    |   13 +-
 linux/linux.mk                                     |   70 ++++--
 package/Config.in                                  |    6 +
 package/Makefile.in                                |   67 ++----
 .../busybox-1.17.3/busybox-1.17.3-skip_strip.patch |   26 +++
 package/busybox/busybox.mk                         |   21 +--
 package/dhrystone/Config.in                        |    6 +
 package/dhrystone/Makefile                         |   13 +
 package/dhrystone/dhrystone-2-HZ.patch             |   13 +
 package/dhrystone/dhrystone-2-cmdline-nruns.patch  |   51 +++++
 package/dhrystone/dhrystone-2-exit.patch           |   12 +
 package/dhrystone/dhrystone-2-prototypes.patch     |   21 ++
 package/dhrystone/dhrystone.mk                     |   37 +++
 package/irda-utils/Config.in                       |   19 ++
 package/irda-utils/irda-utils-0.9.18-daemon.patch  |   26 +++
 package/irda-utils/irda-utils-0.9.18-nommu.patch   |   14 ++
 package/irda-utils/irda-utils-0.9.18-subdir.patch  |   16 ++
 package/irda-utils/irda-utils.mk                   |   47 ++++
 package/libpcap/libpcap.mk                         |    7 +-
 package/lsuio/Config.in                            |    6 +
 package/lsuio/lsuio.mk                             |   11 +
 package/m4/m4-1.4.15-uclibc-sched_param-def.patch  |   19 ++
 package/m4/m4.mk                                   |    2 +-
 package/pax-utils/Config.in                        |    6 +
 package/pax-utils/pax-utils.mk                     |   42 ++++
 ...0-0001-README-fix-typo-in-tcp-wrapper-doc.patch |   26 +++
 ...0002-NO_PIE-make-PIE-support-controllable.patch |   53 +++++
 ...K-control-usage-of-fork-for-nommu-systems.patch |  110 +++++++++
 ...ERROR-control-overriding-of-perror-symbol.patch |   46 ++++
 package/portmap/portmap.mk                         |   12 +-
 package/rsh-redone/Config.in                       |   31 +++
 package/rsh-redone/rsh-redone.mk                   |   36 +++
 package/tcpdump/tcpdump-4.1.1-vfork.patch          |  128 +++++++++++
 package/whetstone/Config.in                        |    6 +
 package/whetstone/whetstone.mk                     |   37 +++
 package/xz/xz.mk                                   |    2 +-
 target/Config.in.arch                              |   32 +++-
 target/generic/Config.in                           |   19 ++-
 toolchain/gdb/6.6/gdb-6.6-bfin-gdbserver.patch     |  238 ++++++++++++++++++++
 toolchain/gdb/Config.in                            |    7 +-
 toolchain/helpers.mk                               |   14 +-
 toolchain/toolchain-common.in                      |    7 +
 toolchain/toolchain-external/Config.in.2           |   11 +
 toolchain/toolchain-external/ext-tool.mk           |    6 +
 50 files changed, 1304 insertions(+), 111 deletions(-)
 create mode 100644 package/busybox/busybox-1.17.3/busybox-1.17.3-skip_strip.patch
 create mode 100644 package/dhrystone/Config.in
 create mode 100644 package/dhrystone/Makefile
 create mode 100644 package/dhrystone/dhrystone-2-HZ.patch
 create mode 100644 package/dhrystone/dhrystone-2-cmdline-nruns.patch
 create mode 100644 package/dhrystone/dhrystone-2-exit.patch
 create mode 100644 package/dhrystone/dhrystone-2-prototypes.patch
 create mode 100644 package/dhrystone/dhrystone.mk
 create mode 100644 package/irda-utils/Config.in
 create mode 100644 package/irda-utils/irda-utils-0.9.18-daemon.patch
 create mode 100644 package/irda-utils/irda-utils-0.9.18-nommu.patch
 create mode 100644 package/irda-utils/irda-utils-0.9.18-subdir.patch
 create mode 100644 package/irda-utils/irda-utils.mk
 create mode 100644 package/lsuio/Config.in
 create mode 100644 package/lsuio/lsuio.mk
 create mode 100644 package/m4/m4-1.4.15-uclibc-sched_param-def.patch
 create mode 100644 package/pax-utils/Config.in
 create mode 100644 package/pax-utils/pax-utils.mk
 create mode 100644 package/portmap/portmap-6.0-0001-README-fix-typo-in-tcp-wrapper-doc.patch
 create mode 100644 package/portmap/portmap-6.0-0002-NO_PIE-make-PIE-support-controllable.patch
 create mode 100644 package/portmap/portmap-6.0-0003-NO_FORK-control-usage-of-fork-for-nommu-systems.patch
 create mode 100644 package/portmap/portmap-6.0-0004-NO_PERROR-control-overriding-of-perror-symbol.patch
 create mode 100644 package/rsh-redone/Config.in
 create mode 100644 package/rsh-redone/rsh-redone.mk
 create mode 100644 package/tcpdump/tcpdump-4.1.1-vfork.patch
 create mode 100644 package/whetstone/Config.in
 create mode 100644 package/whetstone/whetstone.mk
 create mode 100644 toolchain/gdb/6.6/gdb-6.6-bfin-gdbserver.patch

[Buildroot] Pull request buildroot.git (vapier branch)

[Mike Frysinger]

The following changes since commit d8de970bae3744fe830e96a1ae0c4aff6ce47ba1:

  uClibc: sys/ptrace.h fix for 0.9.31 / powerpc so ltrace builds (2010-11-22 10:53:09 +0100)

are available in the git repository at:
  git://sources.blackfin.uclinux.org/git/users/vapier/buildroot.git vapier

Mike Frysinger (5):
      m4: version bump to 1.4.15
      xz: version bump to 5.0.0
      u-boot: version bump to 2010.09
      auto remove empty /usr/share dir
      rsh-redone: new package for rsh/rlogin clients

 Makefile                                          |    1 +
 boot/u-boot/Config.in                             |    6 +++-
 package/Config.in                                 |    1 +
 package/m4/m4-1.4.15-uclibc-sched_param-def.patch |   19 +++++++++++
 package/m4/m4.mk                                  |    2 +-
 package/rsh-redone/Config.in                      |   31 ++++++++++++++++++
 package/rsh-redone/rsh-redone.mk                  |   36 +++++++++++++++++++++
 package/xz/xz.mk                                  |    2 +-
 8 files changed, 95 insertions(+), 3 deletions(-)
 create mode 100644 package/m4/m4-1.4.15-uclibc-sched_param-def.patch
 create mode 100644 package/rsh-redone/Config.in
 create mode 100644 package/rsh-redone/rsh-redone.mk