* [Buildroot] can't resolve symbol 'atexit'
From: Thomas Petazzoni @ 2010-10-04 17:02 UTC (permalink / raw)
To: buildroot
In-Reply-To: <AANLkTinDdVF2W2sgU24qBHfDVztgJ-kEy=FQyeuE7fyH@mail.gmail.com>
Hello Anthony,
On Mon, 4 Oct 2010 14:26:53 +0100
anthony henderson <development@fair-games.com> wrote:
> I've got busy box working well with my software, however I've tried
> to run an exe provided by the board vendor and get the following
> error "can't resolve symbol 'atexit'" is there a way to fix this?
> It's a bit hard to find details on google, I think it's to do with
> different versions of uClibc? However when I've opened buildroot and
> looked in toolchain -> uClibc I can't see any options to do with
> atexit. Can anyone point me in the right direction, thanks.
You cannot expect a random binary taken from your vendor to work with a
random version/configuration of uClibc. Basically, you need to get the
source code for this application and recompile it with the toolchain
used to build your embedded system.
The uClibc library does not provide a stable ABI, both accross versions
and configurations.
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] getkversion.c:17: error: ‘UTS_RELEASE’ undeclared (first use in this function)
From: Sergio Monteiro Basto @ 2010-10-04 16:11 UTC (permalink / raw)
To: buildroot
Hi,
After read this:
http://www.mail-archive.com/blfs-support at linuxfromscratch.org/msg06766.html
found this patch solve the problem :
--- nfs-utils-1.0.9/tools/Makefile.am.orig 2006-07-07 20:04:32.000000000 -0400
+++ nfs-utils-1.0.9/tools/Makefile.am 2006-09-11 14:39:11.000000000 -0400
@@ -1,5 +1,5 @@
## Process this file with automake to produce Makefile.in
-SUBDIRS = getiversion getkversion locktest rpcdebug rpcgen nlmtest
+SUBDIRS = locktest rpcdebug rpcgen nlmtest
MAINTAINERCLEANFILES = Makefile.in
For this compile error:
Making install in getkversion
make[3]: Entering directory `/home/sergio/hardware/moviecube/buildroot/output/build/nfs-utils-1.0.10/tools/getkversion'
(...)
getkversion.c: In function ?main?:
getkversion.c:17: error: ?UTS_RELEASE? undeclared (first use in this function)
getkversion.c:17: error: (Each undeclared identifier is reported only once
getkversion.c:17: error: for each function it appears in.)
make[3]: *** [getkversion-getkversion.o] Error 1
make[3]: Leaving directory `/home/sergio/hardware/moviecube/buildroot/output/build/nfs-utils-1.0.10/tools/getkversion'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/home/sergio/hardware/moviecube/buildroot/output/build/nfs-utils-1.0.10/tools'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/sergio/hardware/moviecube/buildroot/output/build/nfs-utils-1.0.10'
Best regards
--
S?rgio M. B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3293 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101004/2b34eacc/attachment.bin>
^ permalink raw reply
* [Buildroot] can't resolve symbol 'atexit'
From: anthony henderson @ 2010-10-04 13:26 UTC (permalink / raw)
To: buildroot
Hi all
I've got busy box working well with my software, however I've tried to run
an exe provided by the board vendor and get the following error "can't
resolve symbol 'atexit'" is there a way to fix this? It's a bit hard to
find details on google, I think it's to do with different versions of
uClibc? However when I've opened buildroot and looked in toolchain ->
uClibc I can't see any options to do with atexit. Can anyone point me in
the right direction, thanks.
--
Regards Tony
NOTE: This message is intended solely for the use of the individual or
organization to whom it is addressed. It may contain privileged or
confidential information. If you have received this message in error, please
notify the originator immediately. If you are not the intended recipient,
you should not use, copy, alter, or disclose the contents of this message.
All information or opinions expressed in this message and/or any attachments
are those of the author and are not necessarily those of Fair Games UK LTD
or its affiliates. Fair Games UK LTD accepts no responsibility for loss or
damage arising from its use, including damage from virus.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101004/cce77f81/attachment.html>
^ permalink raw reply
* [Buildroot] [PATCH 1/2] jpeg: bump to 8b
From: Peter Korsgaard @ 2010-10-04 10:07 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1286052682-22218-2-git-send-email-Martin.Banky@gmail.com>
>>>>> "Martin" == Martin Banky <martin.banky@gmail.com> writes:
Martin> Signed-off-by: Martin Banky <Martin.Banky@gmail.com>
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [git commit master 1/1] jpeg: remove lgpl header
From: Peter Korsgaard @ 2010-10-04 9:51 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=b808b60b89abf767063172a6c48fab3cc22008f7
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Buildroot as a whole is under GPL, so lets not expand each .mk file with
legal matter. The git history nicely shows the origin of each file, and
after the conversion to autotargets there basically isn't anything
left of the original file anymore.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/jpeg/jpeg.mk | 17 -----------------
1 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/package/jpeg/jpeg.mk b/package/jpeg/jpeg.mk
index 1f408a0..6dd4334 100644
--- a/package/jpeg/jpeg.mk
+++ b/package/jpeg/jpeg.mk
@@ -3,23 +3,6 @@
# jpeg (libraries needed by some apps)
#
#############################################################
-# Copyright (C) 2001-2003 by Erik Andersen <andersen@codepoet.org>
-# Copyright (C) 2002 by Tim Riker <Tim@Rikers.org>
-#
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU Library 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
-# Library General Public License for more details.
-#
-# You should have received a copy of the GNU Library General Public
-# License along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
-# USA
JPEG_VERSION = 8b
JPEG_SITE = http://www.ijg.org/files/
JPEG_SOURCE = jpegsrc.v$(JPEG_VERSION).tar.gz
--
1.7.1
^ permalink raw reply related
* [Buildroot] [git commit master 1/1] jpeg: bump to 8b
From: Martin Banky @ 2010-10-04 9:51 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=ffa57e4e74ad396eec544491d37548050bb950c0
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Martin Banky <Martin.Banky@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/jpeg/jpeg-build.patch | 99 ---------------------------------------
package/jpeg/jpeg-libtool.patch | 66 --------------------------
package/jpeg/jpeg.mk | 7 +--
3 files changed, 3 insertions(+), 169 deletions(-)
delete mode 100644 package/jpeg/jpeg-build.patch
delete mode 100644 package/jpeg/jpeg-libtool.patch
diff --git a/package/jpeg/jpeg-build.patch b/package/jpeg/jpeg-build.patch
deleted file mode 100644
index 9f3c5c2..0000000
--- a/package/jpeg/jpeg-build.patch
+++ /dev/null
@@ -1,99 +0,0 @@
-- Respect options from configure (bindir/libdir/etc...)
-- Grab AR from the env instead of hardcoding to 'ar'
-- Fix install to respect $(DESTDIR)
-- Also install jpegint.h #64254
-
---- jpeg/makefile.cfg
-+++ jpeg/makefile.cfg
-@@ -11,13 +11,13 @@
- # Where to install the programs and man pages.
- prefix = @prefix@
- exec_prefix = @exec_prefix@
--bindir = $(exec_prefix)/bin
--libdir = $(exec_prefix)/lib
--includedir = $(prefix)/include
-+bindir = @bindir@
-+libdir = @libdir@
-+includedir = @includedir@
- binprefix =
- manprefix =
- manext = 1
--mandir = $(prefix)/man/man$(manext)
-+mandir = @mandir@/man$(manext)
-
- # The name of your C compiler:
- CC= @CC@
-@@ -60,7 +60,8 @@
- # directory creation command
- MKDIR= mkdir
- # library (.a) file creation command
--AR= ar rc
-+AR = @AR@
-+ARFLAGS = rc
- # second step in .a creation (use "touch" if not needed)
- AR2= @RANLIB@
- # installation program
-@@ -163,7 +164,7 @@
- # without libtool:
- libjpeg.a: @A2K_DEPS@ $(LIBOBJECTS)
- $(RM) libjpeg.a
-- $(AR) libjpeg.a $(LIBOBJECTS)
-+ $(AR) $(ARFLAGS) libjpeg.a $(LIBOBJECTS)
- $(AR2) libjpeg.a
-
- # with libtool:
-@@ -191,25 +191,29 @@
- # Installation rules:
-
- install: cjpeg djpeg jpegtran rdjpgcom wrjpgcom @FORCE_INSTALL_LIB@
-- $(INSTALL_PROGRAM) cjpeg $(bindir)/$(binprefix)cjpeg
-- $(INSTALL_PROGRAM) djpeg $(bindir)/$(binprefix)djpeg
-- $(INSTALL_PROGRAM) jpegtran $(bindir)/$(binprefix)jpegtran
-- $(INSTALL_PROGRAM) rdjpgcom $(bindir)/$(binprefix)rdjpgcom
-- $(INSTALL_PROGRAM) wrjpgcom $(bindir)/$(binprefix)wrjpgcom
-- $(INSTALL_DATA) $(srcdir)/cjpeg.1 $(mandir)/$(manprefix)cjpeg.$(manext)
-- $(INSTALL_DATA) $(srcdir)/djpeg.1 $(mandir)/$(manprefix)djpeg.$(manext)
-- $(INSTALL_DATA) $(srcdir)/jpegtran.1 $(mandir)/$(manprefix)jpegtran.$(manext)
-- $(INSTALL_DATA) $(srcdir)/rdjpgcom.1 $(mandir)/$(manprefix)rdjpgcom.$(manext)
-- $(INSTALL_DATA) $(srcdir)/wrjpgcom.1 $(mandir)/$(manprefix)wrjpgcom.$(manext)
-+ mkdir -p $(DESTDIR)$(bindir) $(DESTDIR)$(mandir)
-+ $(INSTALL_PROGRAM) cjpeg $(DESTDIR)$(bindir)/$(binprefix)cjpeg
-+ $(INSTALL_PROGRAM) djpeg $(DESTDIR)$(bindir)/$(binprefix)djpeg
-+ $(INSTALL_PROGRAM) jpegtran $(DESTDIR)$(bindir)/$(binprefix)jpegtran
-+ $(INSTALL_PROGRAM) rdjpgcom $(DESTDIR)$(bindir)/$(binprefix)rdjpgcom
-+ $(INSTALL_PROGRAM) wrjpgcom $(DESTDIR)$(bindir)/$(binprefix)wrjpgcom
-+ $(INSTALL_DATA) $(srcdir)/cjpeg.1 $(DESTDIR)$(mandir)/$(manprefix)cjpeg.$(manext)
-+ $(INSTALL_DATA) $(srcdir)/djpeg.1 $(DESTDIR)$(mandir)/$(manprefix)djpeg.$(manext)
-+ $(INSTALL_DATA) $(srcdir)/jpegtran.1 $(DESTDIR)$(mandir)/$(manprefix)jpegtran.$(manext)
-+ $(INSTALL_DATA) $(srcdir)/rdjpgcom.1 $(DESTDIR)$(mandir)/$(manprefix)rdjpgcom.$(manext)
-+ $(INSTALL_DATA) $(srcdir)/wrjpgcom.1 $(DESTDIR)$(mandir)/$(manprefix)wrjpgcom.$(manext)
-
- install-lib: libjpeg.$(A) install-headers
-- $(INSTALL_LIB) libjpeg.$(A) $(libdir)/$(binprefix)libjpeg.$(A)
-+ mkdir -p $(DESTDIR)$(libdir)
-+ $(INSTALL_LIB) libjpeg.$(A) $(DESTDIR)$(libdir)/$(binprefix)libjpeg.$(A)
-
- install-headers: jconfig.h
-- $(INSTALL_DATA) jconfig.h $(includedir)/jconfig.h
-- $(INSTALL_DATA) $(srcdir)/jpeglib.h $(includedir)/jpeglib.h
-- $(INSTALL_DATA) $(srcdir)/jmorecfg.h $(includedir)/jmorecfg.h
-- $(INSTALL_DATA) $(srcdir)/jerror.h $(includedir)/jerror.h
-+ mkdir -p $(DESTDIR)$(includedir)
-+ $(INSTALL_DATA) jconfig.h $(DESTDIR)$(includedir)/jconfig.h
-+ $(INSTALL_DATA) $(srcdir)/jpegint.h $(DESTDIR)$(includedir)/jpegint.h
-+ $(INSTALL_DATA) $(srcdir)/jpeglib.h $(DESTDIR)$(includedir)/jpeglib.h
-+ $(INSTALL_DATA) $(srcdir)/jmorecfg.h $(DESTDIR)$(includedir)/jmorecfg.h
-+ $(INSTALL_DATA) $(srcdir)/jerror.h $(DESTDIR)$(includedir)/jerror.h
-
- clean:
- $(RM) *.o *.lo libjpeg.a libjpeg.la
---- jpeg/configure
-+++ jpeg/configure
-@@ -1777,6 +1777,7 @@
- s%@CPP@%$CPP%g
- s%@INSTALL_PROGRAM@%$INSTALL_PROGRAM%g
- s%@INSTALL_DATA@%$INSTALL_DATA%g
-+s%@AR@%${AR-ar}%g
- s%@RANLIB@%$RANLIB%g
- s%@LIBTOOL@%$LIBTOOL%g
- s%@O@%$O%g
diff --git a/package/jpeg/jpeg-libtool.patch b/package/jpeg/jpeg-libtool.patch
deleted file mode 100644
index 3c4b573..0000000
--- a/package/jpeg/jpeg-libtool.patch
+++ /dev/null
@@ -1,66 +0,0 @@
---- jpeg/configure
-+++ jpeg/configure
-@@ -1559,7 +1559,7 @@
- if test "x$LTSTATIC" = xno; then
- disable_static="--disable-static"
- fi
-- $srcdir/ltconfig $disable_shared $disable_static $srcdir/ltmain.sh
-+ $srcdir/ltconfig $disable_shared $disable_static $srcdir/ltmain.sh $CHOST
- fi
-
- # Select memory manager depending on user input.
---- jpeg/ltconfig
-+++ jpeg/ltconfig
-@@ -299,6 +299,7 @@
- # Transform linux* to *-*-linux-gnu*, to support old configure scripts.
- case "$host_os" in
- linux-gnu*) ;;
-+linux-uclibc*) ;;
- linux*) host=`echo $host | sed 's/^\(.*-.*-linux\)\(.*\)$/\1-gnu\2/'`
- esac
-
-@@ -553,7 +553,9 @@
- # On HP-UX, both CC and GCC only warn that PIC is supported... then they
- # create non-PIC objects. So, if there were any warnings, we assume that
- # PIC is not supported.
-+ # Make sure we only test warnings on HP-UX (pic_flag == +Z) or we can
-+ # easily break Linux builds http://bugs.gentoo.org/70947
-- if test -s conftest.err; then
-+ if test -s conftest.err -a "$pic_flag" = "+Z"; then
- echo "$ac_t"no 1>&6
- can_build_shared=no
- pic_flag=
-@@ -1210,7 +1210,6 @@
- else
- # Only the GNU ld.so supports shared libraries on MkLinux.
- case "$host_cpu" in
-- powerpc*) dynamic_linker=no ;;
- *) dynamic_linker='Linux ld.so' ;;
- esac
- fi
-@@ -1259,6 +1260,25 @@
- fi
- ;;
-
-+linux-uclibc*)
-+ version_type=linux
-+ need_lib_prefix=no
-+ need_version=no
-+ library_names_spec='${libname}${release}.so.$versuffix ${libname}${release}.so.$major $libname.so'
-+ soname_spec='${libname}${release}.so.$major'
-+ finish_cmds='PATH="\$PATH:/sbin" ldconfig -n $libdir'
-+ shlibpath_var=LD_LIBRARY_PATH
-+ shlibpath_overrides_runpath=no
-+ deplibs_check_method=pass_all
-+ # This implies no fast_install, which is unacceptable.
-+ # Some rework will be needed to allow for fast_install
-+ # before this can be enabled.
-+ # Note: copied from linux-gnu, and may not be appropriate.
-+ hardcode_into_libs=yes
-+ # Assume using the uClibc dynamic linker.
-+ dynamic_linker="uClibc ld.so"
-+ ;;
-+
- netbsd* | openbsd*)
- version_type=sunos
- library_names_spec='${libname}${release}.so.$versuffix'
diff --git a/package/jpeg/jpeg.mk b/package/jpeg/jpeg.mk
index 4f08534..1f408a0 100644
--- a/package/jpeg/jpeg.mk
+++ b/package/jpeg/jpeg.mk
@@ -20,13 +20,12 @@
# License along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA
-JPEG_VERSION:=6b
-JPEG_SITE:=ftp://ftp.uu.net/graphics/jpeg/
-JPEG_SOURCE=jpegsrc.v$(JPEG_VERSION).tar.gz
+JPEG_VERSION = 8b
+JPEG_SITE = http://www.ijg.org/files/
+JPEG_SOURCE = jpegsrc.v$(JPEG_VERSION).tar.gz
JPEG_INSTALL_STAGING = YES
JPEG_INSTALL_TARGET = YES
JPEG_LIBTOOL_PATCH = NO
-JPEG_CONF_OPT = --without-x --enable-shared --enable-static
define JPEG_REMOVE_USELESS_TOOLS
rm -f $(addprefix $(TARGET_DIR)/usr/bin/,cjpeg djpeg jpegtrans rdjpgcom wrjpgcom)
--
1.7.1
^ permalink raw reply related
* [Buildroot] [git commit master 1/1] libeXosip2: convert to autotargets and bump to 3.3.0
From: Martin Banky @ 2010-10-04 9:44 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=05e4b940c94e883afde697c07a37d8a47c81b33e
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Martin Banky <Martin.Banky@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
CHANGES | 23 ++++----
package/libeXosip2/libeXosip2.mk | 109 +++++++------------------------------
2 files changed, 33 insertions(+), 99 deletions(-)
diff --git a/CHANGES b/CHANGES
index e14801b..96b6397 100644
--- a/CHANGES
+++ b/CHANGES
@@ -31,17 +31,18 @@
gtk2-themes, gtkperf, gvfs, haserl, hdparm, hostapd, hwdata,
ifplugd, iperf, iproute2, iptables, iw, jpeg, kexec, kismet,
less, libcgi, libcurl, libdaemon, libdnet, liberation,
- libevent, libglade, libgtk2, libiconv, libidn, libmms, libnl,
- liboil, libosip2, libpcap, libpng, libtool, libungif, libxml2,
- libxslt, lighttpd, lite, lm-sensors, lockfile-progs, logrotate,
- m4, mdadm, mesa3d, metacity, mtd-utils, mysql_client, nano,
- nbd, ncftp, neon, netperf, netsnmp, ng-spice-rework, ntfsprogs,
- ntp, openntpd, openssh, openvpn, oprofile, pango, patch, pcre,
- php, pkg-config, prboom, radvd, rdesktop, ruby, qt, quagga,
- samba, sawman, sdl_mixer, sdl_sound, setserial,
- shared-mime-info, speex, sqlite, squashfs, strace, sylpheed,
- taglib, tcpdump, thttpd, tiff, tn5250, udev, udpcast,
- usbmount, usbutils, vsftpd, vtun, which, wpa_supplicant,
+ libevent, libeXosip2, libglade, libgtk2, libiconv, libidn,
+ libmms, libnl, liboil, libosip2, libpcap, libpng, libtool,
+ libungif, libxml2, libxslt, lighttpd, lite, lm-sensors,
+ lockfile-progs, logrotate, m4, mdadm, mesa3d, metacity,
+ mtd-utils, mysql_client, nano, nbd, ncftp, neon, netperf,
+ netsnmp, ng-spice-rework, ntfsprogs, ntp, openntpd, openssh,
+ openvpn, oprofile, pango, patch, pcre, php, pkg-config,
+ prboom, radvd, rdesktop, ruby, qt, quagga, samba, sawman,
+ sdl_mixer, sdl_sound, setserial, shared-mime-info, speex,
+ sqlite, squashfs, strace, sylpheed, taglib, tcpdump, thttpd,
+ tiff, tn5250, udev, udpcast, usbmount, usbutils, vsftpd, vtun,
+ which, wpa_supplicant,
xdriver_xf86-input-{acecad,aiptek,evdev,joystick,keyboard},
xdriver-xf86-input-{mouse,synaptics,vmmouse,void},
xdriver-xf86-video-{apm,ark,ast,ati,chips,cirrus,dummy,fbdev},
diff --git a/package/libeXosip2/libeXosip2.mk b/package/libeXosip2/libeXosip2.mk
index 30eac9f..415745b 100644
--- a/package/libeXosip2/libeXosip2.mk
+++ b/package/libeXosip2/libeXosip2.mk
@@ -3,93 +3,26 @@
# libeXosip2
#
#############################################################
+LIBEXOSIP2_VERSION = 3.3.0
+LIBEXOSIP2_SOURCE = libexosip2_$(LIBEXOSIP2_VERSION).orig.tar.gz
+LIBEXOSIP2_PATCH = libexosip2_$(LIBEXOSIP2_VERSION)-1.diff.gz
+LIBEXOSIP2_SITE = $(BR2_DEBIAN_MIRROR)/debian/pool/main/libe/libexosip2
+LIBEXOSIP2_INSTALL_STAGING = YES
+
+LIBEXOSIP2_DEPENDENCIES = host-pkg-config libosip2
+
+ifneq ($(LIBEXOSIP2_PATCH),)
+define LIBEXOSIP2_DEBIAN_PATCHES
+ if [ -d $(@D)/debian/patches ]; then \
+ (cd $(@D)/debian/patches && for i in *; \
+ do $(SED) 's,^\+\+\+ .*cvs-$(LIBEXOSIP2_VERSION)/,+++ cvs-$(LIBEXOSIP2_VERSION)/,' $$i; \
+ done; \
+ ); \
+ toolchain/patch-kernel.sh $(@D) $(@D)/debian/patches \*; \
+ fi
+endef
+endif
-LIBEXOSIP2_VERSION=3.1.0
-LIBEXOSIP2_SOURCE=libeXosip2-$(LIBEXOSIP2_VERSION).tar.gz
-LIBEXOSIP2_SITE=http://www.antisip.com/download/exosip2
-LIBEXOSIP2_DIR=$(BUILD_DIR)/libeXosip2-$(LIBEXOSIP2_VERSION)
-LIBEXOSIP2_CAT:=$(ZCAT)
-
-$(DL_DIR)/$(LIBEXOSIP2_SOURCE):
- $(call DOWNLOAD,$(LIBEXOSIP2_SITE),$(LIBEXOSIP2_SOURCE))
-
-$(LIBEXOSIP2_DIR)/.unpacked: $(DL_DIR)/$(LIBEXOSIP2_SOURCE)
- $(LIBEXOSIP2_CAT) $(DL_DIR)/$(LIBEXOSIP2_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) -
- $(CONFIG_UPDATE) $(LIBEXOSIP2_DIR)
- touch $(LIBEXOSIP2_DIR)/.unpacked
-
-$(LIBEXOSIP2_DIR)/.configured: $(LIBEXOSIP2_DIR)/.unpacked
- (cd $(LIBEXOSIP2_DIR); rm -rf config.cache; \
- $(TARGET_CONFIGURE_OPTS) \
- $(TARGET_CONFIGURE_ARGS) \
- ./configure $(QUIET) \
- --target=$(GNU_TARGET_NAME) \
- --host=$(GNU_TARGET_NAME) \
- --build=$(GNU_HOST_NAME) \
- --prefix=/usr \
- --enable-shared \
- --enable-static \
- $(DISABLE_NLS) \
- )
- touch $@
-
-$(LIBEXOSIP2_DIR)/.compiled: $(LIBEXOSIP2_DIR)/.configured
- $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(LIBEXOSIP2_DIR)
- touch $@
-
-#LDFLAGS=$(TARGET_LDFLAGS)
-
-$(STAGING_DIR)/usr/lib/libeXosip2.so: $(LIBEXOSIP2_DIR)/.compiled
- cp -dpf $(LIBEXOSIP2_DIR)/src/.libs/libeXosip2.so* $(STAGING_DIR)/usr/lib
- touch $@
-
-$(STAGING_DIR)/usr/lib/libeXosip2.a: $(LIBEXOSIP2_DIR)/.compiled
- cp -dpf $(LIBEXOSIP2_DIR)/src/.libs/libeXosip2.a $(STAGING_DIR)/usr/lib
- cp -dpf $(LIBEXOSIP2_DIR)/include/*.h $(STAGING_DIR)/usr/include
- touch $@
-
-$(STAGING_DIR)/usr/lib/libeXosip2.la: $(LIBEXOSIP2_DIR)/.compiled
- cp -dpf $(LIBEXOSIP2_DIR)/src/libeXosip2.la $(STAGING_DIR)/usr/lib
- $(SED) "s,^libdir=.*,libdir=\'$(STAGING_DIR)/usr/lib\',g" $(STAGING_DIR)/usr/lib/libeXosip2.la
- touch $@
-
-$(STAGING_DIR)/usr/bin/sip_reg: $(LIBEXOSIP2_DIR)/.compiled
- cp -dpf $(LIBEXOSIP2_DIR)/tools/.libs/sip_reg $(STAGING_DIR)/usr/bin
- touch $@
-
-
-$(TARGET_DIR)/usr/lib/libeXosip2.so: $(STAGING_DIR)/usr/lib/libeXosip2.so
- mkdir -p $(TARGET_DIR)/usr/lib
- cp -dpf $(STAGING_DIR)/usr/lib/libeXosip2.so* $(TARGET_DIR)/usr/lib/
- $(STRIPCMD) $(STRIP_STRIP_UNNEEDED) $(TARGET_DIR)/usr/lib/libeXosip2.so*
- touch $@
-
-$(TARGET_DIR)/usr/bin/sip_reg: $(STAGING_DIR)/usr/bin/sip_reg
- mkdir -p $(TARGET_DIR)/usr/bin
- cp -dpf $(STAGING_DIR)/usr/bin/sip_reg $(TARGET_DIR)/usr/bin
- touch $@
-
-
-
-libeXosip2: host-pkg-config libosip2 $(TARGET_DIR)/usr/lib/libeXosip2.so
-
-libeXosip2-source: $(DL_DIR)/$(LIBEXOSIP2_SOURCE)
-
-libeXosip2-clean:
- -$(MAKE) -C $(LIBEXOSIP2_DIR) clean
- -rm -f $(STAGING_DIR)/usr/lib/libeXosip2.*
- -rm -f $(TARGET_DIR)/usr/lib/libeXosip2.*
-
-
-libeXosip2-dirclean:
- rm -rf $(LIBEXOSIP2_DIR)
+LIBEXOSIP2_POST_PATCH_HOOKS += LIBEXOSIP2_DEBIAN_PATCHES
-.PHONY: libeXosip2-headers libeXosip2-target-headers
-#############################################################
-#
-# Toplevel Makefile options
-#
-#############################################################
-ifeq ($(BR2_PACKAGE_LIBEXOSIP2),y)
-TARGETS+=libeXosip2
-endif
+$(eval $(call AUTOTARGETS,package,libeXosip2))
--
1.7.1
^ permalink raw reply related
* [Buildroot] [git commit master 1/1] scripts: get rid of outdated buildall script
From: Peter Korsgaard @ 2010-10-04 9:44 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=d6e59652a5045fe2b23e45fe31cf08fe57f11357
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Patch is too large, so refusing to show it
^ permalink raw reply
* [Buildroot] [git commit master 1/1] package: get rid of ".. has no inherent support for AVR32" comments
From: Peter Korsgaard @ 2010-10-04 9:44 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=e7b6b32c5db122bced1466e5affea4ca53b6cbb9
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
These are probaly out of date by now, and lack of special handling for
avr32 doesn't mean that a package won't work on avr32, so remove them.
Done by sed -i '/comment.*no inherent support for AVR32/{N;N;p}'
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/argus/Config.in | 3 ---
package/bind/Config.in | 3 ---
package/dmraid/Config.in | 3 ---
package/kismet/Config.in | 3 ---
package/libeXosip2/Config.in | 3 ---
package/ntfs-3g/Config.in | 3 ---
package/openntpd/Config.in | 3 ---
package/pciutils/Config.in | 3 ---
package/ruby/Config.in | 3 ---
package/smartmontools/Config.in | 3 ---
package/vtun/Config.in | 3 ---
11 files changed, 0 insertions(+), 33 deletions(-)
diff --git a/package/argus/Config.in b/package/argus/Config.in
index 0c00126..6728ae7 100644
--- a/package/argus/Config.in
+++ b/package/argus/Config.in
@@ -1,6 +1,3 @@
-comment "argus has no inherent support for AVR32"
- depends on BR2_avr32 && BR2_PACKAGE_ARGUS
-
config BR2_PACKAGE_ARGUS
bool "argus"
select BR2_PACKAGE_LIBPCAP
diff --git a/package/bind/Config.in b/package/bind/Config.in
index 72cf3a0..827ee26 100644
--- a/package/bind/Config.in
+++ b/package/bind/Config.in
@@ -1,6 +1,3 @@
-comment "bind has no inherent support for AVR32"
- depends on BR2_avr32 && BR2_PACKAGE_BIND
-
config BR2_PACKAGE_BIND
bool "bind"
depends on BR2_LARGEFILE
diff --git a/package/dmraid/Config.in b/package/dmraid/Config.in
index 7d6ecfb..7b37244 100644
--- a/package/dmraid/Config.in
+++ b/package/dmraid/Config.in
@@ -1,6 +1,3 @@
-comment "dmraid has no inherent support for AVR32"
- depends on BR2_avr32 && BR2_PACKAGE_DMRAID
-
config BR2_PACKAGE_DMRAID
bool "dmraid"
depends on BR2_LARGEFILE
diff --git a/package/kismet/Config.in b/package/kismet/Config.in
index 5674fbc..6954665 100644
--- a/package/kismet/Config.in
+++ b/package/kismet/Config.in
@@ -1,6 +1,3 @@
-comment "Kismet has no inherent support for AVR32"
- depends on BR2_avr32 && BR2_PACKAGE_KISMET
-
comment "Kismet requires a toolchain with C++ support enabled"
depends on !BR2_INSTALL_LIBSTDCPP
diff --git a/package/libeXosip2/Config.in b/package/libeXosip2/Config.in
index 5ae3e97..8adca5a 100644
--- a/package/libeXosip2/Config.in
+++ b/package/libeXosip2/Config.in
@@ -1,6 +1,3 @@
-comment "libeXosip2 has no inherent support for AVR32"
- depends on BR2_avr32 && BR2_PACKAGE_LIBEXOSIP2
-
config BR2_PACKAGE_LIBEXOSIP2
bool "libeXosip2"
select BR2_PACKAGE_LIBOSIP2
diff --git a/package/ntfs-3g/Config.in b/package/ntfs-3g/Config.in
index 6d737e6..865f9b4 100644
--- a/package/ntfs-3g/Config.in
+++ b/package/ntfs-3g/Config.in
@@ -1,6 +1,3 @@
-comment "ntfs-3g has no inherent support for AVR32"
- depends on BR2_avr32 && BR2_PACKAGE_NTFS_3G
-
config BR2_PACKAGE_NTFS_3G
bool "ntfs-3g"
depends on BR2_LARGEFILE
diff --git a/package/openntpd/Config.in b/package/openntpd/Config.in
index 5292259..6b8beb8 100644
--- a/package/openntpd/Config.in
+++ b/package/openntpd/Config.in
@@ -1,6 +1,3 @@
-comment "OpenNTPD has no inherent support for AVR32"
- depends on BR2_avr32 && BR2_PACKAGE_OPENNTPD
-
config BR2_PACKAGE_OPENNTPD
bool "OpenNTPD"
help
diff --git a/package/pciutils/Config.in b/package/pciutils/Config.in
index 07fc49b..7b318da 100644
--- a/package/pciutils/Config.in
+++ b/package/pciutils/Config.in
@@ -1,6 +1,3 @@
-comment "pciutils has no inherent support for AVR32"
- depends on BR2_avr32 && BR2_PACKAGE_PCIUTILS
-
config BR2_PACKAGE_PCIUTILS
bool "pciutils"
help
diff --git a/package/ruby/Config.in b/package/ruby/Config.in
index 518302a..c18d8ad 100644
--- a/package/ruby/Config.in
+++ b/package/ruby/Config.in
@@ -1,6 +1,3 @@
-comment "ruby has no inherent support for AVR32"
- depends on BR2_avr32 && BR2_PACKAGE_RUBY
-
config BR2_PACKAGE_RUBY
bool "ruby"
depends on BR2_USE_WCHAR
diff --git a/package/smartmontools/Config.in b/package/smartmontools/Config.in
index f87020f..a1541d7 100644
--- a/package/smartmontools/Config.in
+++ b/package/smartmontools/Config.in
@@ -1,6 +1,3 @@
-comment "smartmontools has no inherent support for AVR32"
- depends on BR2_avr32 && BR2_PACKAGE_SMARTMONTOOLS
-
config BR2_PACKAGE_SMARTMONTOOLS
bool "smartmontools"
help
diff --git a/package/vtun/Config.in b/package/vtun/Config.in
index ad9d9e5..b40de25 100644
--- a/package/vtun/Config.in
+++ b/package/vtun/Config.in
@@ -1,6 +1,3 @@
-comment "vtun has no inherent support for AVR32"
- depends on BR2_avr32 && BR2_PACKAGE_VTUN
-
config BR2_PACKAGE_VTUN
bool "vtun - BEWARE: read package/vtun/README.txt before use"
select BR2_PACKAGE_LZO
--
1.7.1
^ permalink raw reply related
* [Buildroot] [git commit master 1/1] libosip2: change site location and bump to 3.3.0
From: Martin Banky @ 2010-10-04 9:44 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=3d1de0ed96f6f8f87e45bc5326005f0cde41f900
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Change the site location to debian mirror to get the latest debian patches.
Signed-off-by: Martin Banky <Martin.Banky@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
CHANGES | 8 ++++----
package/libosip2/libosip2.mk | 26 ++++++++++++++++++--------
2 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/CHANGES b/CHANGES
index 69ec5d0..e14801b 100644
--- a/CHANGES
+++ b/CHANGES
@@ -32,10 +32,10 @@
ifplugd, iperf, iproute2, iptables, iw, jpeg, kexec, kismet,
less, libcgi, libcurl, libdaemon, libdnet, liberation,
libevent, libglade, libgtk2, libiconv, libidn, libmms, libnl,
- liboil, libpcap, libpng, libtool, libungif, libxml2, libxslt,
- lighttpd, lite, lm-sensors, lockfile-progs, logrotate, m4,
- mdadm, mesa3d, metacity, mtd-utils, mysql_client, nano, nbd,
- ncftp, neon, netperf, netsnmp, ng-spice-rework, ntfsprogs,
+ liboil, libosip2, libpcap, libpng, libtool, libungif, libxml2,
+ libxslt, lighttpd, lite, lm-sensors, lockfile-progs, logrotate,
+ m4, mdadm, mesa3d, metacity, mtd-utils, mysql_client, nano,
+ nbd, ncftp, neon, netperf, netsnmp, ng-spice-rework, ntfsprogs,
ntp, openntpd, openssh, openvpn, oprofile, pango, patch, pcre,
php, pkg-config, prboom, radvd, rdesktop, ruby, qt, quagga,
samba, sawman, sdl_mixer, sdl_sound, setserial,
diff --git a/package/libosip2/libosip2.mk b/package/libosip2/libosip2.mk
index 441b84c..aa15332 100644
--- a/package/libosip2/libosip2.mk
+++ b/package/libosip2/libosip2.mk
@@ -3,14 +3,24 @@
# libosip2
#
#############################################################
-LIBOSIP2_VERSION=3.1.0
-LIBOSIP2_SOURCE=libosip2-$(LIBOSIP2_VERSION).tar.gz
-LIBOSIP2_SITE=http://www.antisip.com/download/exosip2
-LIBOSIP2_INSTALL_STAGING=YES
+LIBOSIP2_VERSION = 3.3.0
+LIBOSIP2_SOURCE = libosip2_$(LIBOSIP2_VERSION).orig.tar.gz
+LIBOSIP2_PATCH = libosip2_$(LIBOSIP2_VERSION)-1.diff.gz
+LIBOSIP2_SITE = $(BR2_DEBIAN_MIRROR)/debian/pool/main/libo/libosip2
+LIBOSIP2_INSTALL_STAGING = YES
-LIBOSIP2_CONF_OPT = \
- --with-gnu-ld \
- --enable-shared \
- --enable-static
+ifneq ($(LIBOSIP2_PATCH),)
+define LIBOSIP2_DEBIAN_PATCHES
+ if [ -d $(@D)/debian/patches ]; then \
+ (cd $(@D)/debian/patches && for i in *; \
+ do $(SED) 's,^\+\+\+ .*cvs-$(LIBOSIP2_VERSION)/,+++ cvs-$(LIBOSIP2_VERSION)/,' $$i; \
+ done; \
+ ); \
+ toolchain/patch-kernel.sh $(@D) $(@D)/debian/patches \*; \
+ fi
+endef
+endif
+
+LIBOSIP2_POST_PATCH_HOOKS += LIBOSIP2_DEBIAN_PATCHES
$(eval $(call AUTOTARGETS,package,libosip2))
--
1.7.1
^ permalink raw reply related
* [Buildroot] [PATCH 0/2] libeXosip2: convert to autotargets and bump to 3.3.0
From: Peter Korsgaard @ 2010-10-04 9:32 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1286057184-3486-1-git-send-email-Martin.Banky@gmail.com>
>>>>> "Martin" == Martin Banky <martin.banky@gmail.com> writes:
Martin> Both patches are needed for this to work properly.
Committed both, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [PATCH] xterm: should select libXaw and bump to latest version
From: Peter Korsgaard @ 2010-10-04 9:19 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20100928115214.10039.12962.stgit@localhost6.localdomain6>
>>>>> "Paulius" == Paulius Zaleckas <paulius.zaleckas@gmail.com> writes:
Paulius> Signed-off-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [git commit master 1/1] xterm: should select libXaw and bump to latest version
From: Peter Korsgaard @ 2010-10-04 9:19 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=1f4000e562040046aef1ec79e33abdeedbe33005
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
CHANGES | 2 +-
package/xterm/Config.in | 1 +
package/xterm/xterm.mk | 4 ++--
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/CHANGES b/CHANGES
index a1168d7..69ec5d0 100644
--- a/CHANGES
+++ b/CHANGES
@@ -51,7 +51,7 @@
xdriver-xf86-video-{sis,sisusb,suncg3,suncg6,suncg14,sunffb},
xdriver-xf86-video-{sunleo,suntcx,tdfx,tga,trident,v4l,vesa},
xdriver-xf86-video-{vmware,voodeo,wsfb,xgi,xgixp},
- xkeyboard-config, xlib_libX11, xstroke, xvkbd, zlib
+ xkeyboard-config, xlib_libX11, xstroke, xterm, xvkbd, zlib
Deprecated packages: hotplug, lzma
diff --git a/package/xterm/Config.in b/package/xterm/Config.in
index da3e9fe..9473fad 100644
--- a/package/xterm/Config.in
+++ b/package/xterm/Config.in
@@ -1,5 +1,6 @@
config BR2_PACKAGE_XTERM
bool "xterm"
+ select BR2_PACKAGE_XLIB_LIBXAW
depends on BR2_PACKAGE_XORG7
help
xterm terminal emulator
diff --git a/package/xterm/xterm.mk b/package/xterm/xterm.mk
index b07eda4..8952e24 100644
--- a/package/xterm/xterm.mk
+++ b/package/xterm/xterm.mk
@@ -4,10 +4,10 @@
#
#############################################################
-XTERM_VERSION:=259
+XTERM_VERSION:=262
XTERM_SOURCE:=xterm-$(XTERM_VERSION).tgz
XTERM_SITE:=ftp://invisible-island.net/xterm
-XTERM_DEPENDENCIES = xserver_xorg-server
+XTERM_DEPENDENCIES = xserver_xorg-server xlib_libXaw
XTERM_INSTALL_TARGET_OPT = DESTDIR=$(TARGET_DIR) install
$(eval $(call AUTOTARGETS,package,xterm))
--
1.7.1
^ permalink raw reply related
* [Buildroot] Libtool work: a tentative summary
From: Lionel Landwerlin @ 2010-10-04 8:09 UTC (permalink / raw)
To: buildroot
In-Reply-To: <AANLkTimOovYkLJg1GVSQzNCyW1h3ZkJ7zbJTH9-JDRLY@mail.gmail.com>
The libtool script patch prevents libtool to give a direct path an
host system shared lib path.
The -L$(STAGING_DIR)... is added to the top of link arguments to
prevent the linker to use the -L/usr/lib outputted by libtool.
Finally the sed pass avoids libtool to open the .la files from host system.
So I'm afraid all those items are required even with libtool 2.4
(without sysroot support).
From what I remember, we added the -L$(STAGING_DIR)/lib
-L$(STAGING_DIR)/usr/lib for a libtool problem (commit
efb1d8d3f40281645c178c150d992601c8042c1a).
I'm going to check with your libtool 2.4 sysroot setup.
Regards,
--
Lionel Landwerlin
On Mon, Oct 4, 2010 at 3:19 AM, Martin Banky <Martin.Banky@gmail.com> wrote:
> Lionel,
> ???? On the first three items, won't we always have to keep these until all
> of the packages either support autoreconfiguring or start using libtool 2.4?
> Like I said before, I ran into three packages that wouldn't autoreconfigure,
> so they would still need the traditional approach. Also, I haven't had a
> chance to really investigate this, but isn't
> TARGET_LDFLAGS+=-L$(STAGING_DIR)/lib -L$(STAGING_DIR)/usr/lib also needed by
> gentargets to link to the correct libraries?
> ???? As for my setup, the only difference is, I compiled libtool with
> --with-sysroot (no directory given), and I don't configure the package with
> it. libtool gets the sysroot directory from gcc's sysroot, if none is
> specified. Everything else is the same. What kind of problems did you
> encounter? Was it just the problem with autoreconfiguring packages?
>
> Martin
>
> On Sun, Oct 3, 2010 at 4:47 PM, Lionel Landwerlin <llandwerlin@gmail.com>
> wrote:
>>
>> As long as we keep the following things, we can bump to 2.2 or 2.4 :
>> ? ? ? ?* sed pass on .la files
>> ? ? ? ?* Add -L$(STAGING_DIR)/lib -L$(STAGING_DIR)/usr/lib to LDFLAGS
>> ? ? ? ?* patches for encountered libtool versions
>>
>> I always took the hypothesis that we wanted to get rid of the first 2,
>> and wanted to keep the third only for special cases.
>>
>> I encountered problem with libtool 2.4 for several packages under the
>> following conditions :
>> ? ? ? ?* run autoreconf on the package
>> ? ? ? ?* do not apply the libtool patch
>> ? ? ? ?* configure the package with --with-sysroot=$(STAGING_DIR) option
>>
>> Martin, did you have the same setup ?
>>
>> I guess we're back to the current situation if we don't pass the
>> --with-sysroot option and we apply a libtool patch for the correct
>> libtool version.
>>
>> Regards,
>>
>> --
>> Lionel Landwerlin
>>
>> Le dimanche 03 octobre 2010 ? 15:36 -0700, Martin Banky a ?crit :
>> > If you want to integrate my patches, I would like to submit a new set
>> > of patches with some changes in preparation for libtool 2.4, mainly
>> > with Makefile.autotools.in. I have it setup now to distinguish between
>> > 1.5.x, 2.2.x, and 2.4. Also, in working on converting the packages to
>> > either gentargets or autotargets, I've been noticing a lot of packages
>> > have their own libtool patch. I would like to go through, and clean
>> > them up. I have a question, why can't we upgrade to libtool 2.4? I've
>> > been running it now since I first posted the heads up patch, and have
>> > used it with the sysroot option turned on without any obvious issues.
>> > If the sysroot option is an issue, we could turn it off for now and
>> > use the libtool patches until we integrate the sysroot option
>> > properly, right? The imagemagick patch set that I posted, was first
>> > done with libtool 2.4 and autoreconfigure turned on. I wanted to make
>> > sure that it would work properly in this configuration, in preparation
>> > of the coming changes. It was then actually posted with
>> > autoreconfigure turned off and using the libtool patch. As a side
>> > note, I just realized that imagemagick is using libtool 2.2.x, which
>> > means that it's incorporation is blocked until either I add it's own
>> > libtool patch or we commit my libtool patch set. Sorry about that. If
>> > anyone would like me to add the libtool patch to imagemagick, and
>> > repost, let me know.
>> >
>> > Martin
>> >
>> > On Sun, Oct 3, 2010 at 7:22 AM, Thomas Petazzoni
>> > <thomas.petazzoni@free-electrons.com> wrote:
>> > ? ? ? ? Hello,
>> >
>> > ? ? ? ? On Sun, 03 Oct 2010 15:22:26 +0200
>> > ? ? ? ? Lionel Landwerlin <llandwerlin@gmail.com> wrote:
>> >
>> > ? ? ? ? > Here is what I would like to us to do for the next
>> > ? ? ? ? releases :
>> > ? ? ? ? >
>> > ? ? ? ? > 1) Bump libtool package to 2.2, more and more packages
>> > ? ? ? ? require libtool
>> > ? ? ? ? > 2.2, and we're stuck to not autoreconfigure them without
>> > ? ? ? ? 2.2. This is
>> > ? ? ? ? > already creating problems to Thomas when trying to bump host
>> > ? ? ? ? > libglib/libgtk packages.
>> >
>> >
>> > ? ? ? ? ?1a) Integrate Martin Banky's proposal so that packages using
>> > ? ? ? ? libtool
>> > ? ? ? ? ? ? ?2.2 can work without the need to autoreconfigure them.
>> >
>> > ? ? ? ? > 2) Eventually integrate some patches to libtool 2.2 to be
>> > ? ? ? ? able to
>> > ? ? ? ? > cross compile autoreconfigured packages.
>> > ? ? ? ? >
>> > ? ? ? ? > 3) When the libtool 2.4 sysroot issue is sorted out, bump to
>> > ? ? ? ? libtool
>> > ? ? ? ? > 2.4 and get rid of the patches integrated in 2).
>> > ? ? ? ? >
>> > ? ? ? ? > I think 1) is mandatory for 2010.11.
>> >
>> >
>> > ? ? ? ? And 1a).
>> >
>> > ? ? ? ? So, I would suggest :
>> >
>> > ? ? ? ? ?*) Peter merges Martin Banky's set of patches on libtool
>> >
>> >
>> > ?http://lists.busybox.net/pipermail/buildroot/2010-September/037505.html
>> >
>> >
>> > ? ? ? ? ?*) Lionel, could you propose a patch that just bumps libtool
>> > ? ? ? ? to 2.2 ?
>> >
>> > ? ? ? ? Lionel, Martin, Peter, what do you think ?
>> >
>> > ? ? ? ? Thanks,
>> >
>> > ? ? ? ? Thomas
>> > ? ? ? ? --
>> > ? ? ? ? Thomas Petazzoni, Free Electrons
>> > ? ? ? ? Kernel, drivers, real-time and embedded Linux
>> > ? ? ? ? development, consulting, training and support.
>> > ? ? ? ? http://free-electrons.com
>> > ? ? ? ? _______________________________________________
>> >
>> >
>> > ? ? ? ? buildroot mailing list
>> > ? ? ? ? buildroot at busybox.net
>> > ? ? ? ? http://lists.busybox.net/mailman/listinfo/buildroot
>> >
>> >
>> > _______________________________________________
>> > buildroot mailing list
>> > buildroot at busybox.net
>> > http://lists.busybox.net/mailman/listinfo/buildroot
>>
>>
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
^ permalink raw reply
* [Buildroot] [PATCH] Bump lighttpd to 1.4.28
From: Peter Korsgaard @ 2010-10-04 7:08 UTC (permalink / raw)
To: buildroot
In-Reply-To: <4CA48C85.7070502@zacarias.com.ar>
>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:
Gustavo> Bump lighttpd to version 1.4.28.
Gustavo> Fixes to SSL, IPv6, proxy and CGI handling.
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [git commit master 1/1] toolchain/gcc: bump 4.4.x version
From: Peter Korsgaard @ 2010-10-04 7:08 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=1f0302f967dd2816c6df63ff75921e487f7c45e6
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
.../gcc/{4.4.4 => 4.4.5}/100-uclibc-conf.patch | 0
.../{4.4.4 => 4.4.5}/301-missing-execinfo_h.patch | 0
.../gcc/{4.4.4 => 4.4.5}/302-c99-snprintf.patch | 0
.../305-libmudflap-susv3-legacy.patch | 0
.../810-arm-softfloat-libgcc.patch | 0
.../powerpc-link-with-math-lib.patch.conditional | 0
toolchain/gcc/Config.in | 2 +-
7 files changed, 1 insertions(+), 1 deletions(-)
rename toolchain/gcc/{4.4.4 => 4.4.5}/100-uclibc-conf.patch (100%)
rename toolchain/gcc/{4.4.4 => 4.4.5}/301-missing-execinfo_h.patch (100%)
rename toolchain/gcc/{4.4.4 => 4.4.5}/302-c99-snprintf.patch (100%)
rename toolchain/gcc/{4.4.4 => 4.4.5}/305-libmudflap-susv3-legacy.patch (100%)
rename toolchain/gcc/{4.4.4 => 4.4.5}/810-arm-softfloat-libgcc.patch (100%)
rename toolchain/gcc/{4.4.4 => 4.4.5}/powerpc-link-with-math-lib.patch.conditional (100%)
diff --git a/toolchain/gcc/4.4.4/100-uclibc-conf.patch b/toolchain/gcc/4.4.5/100-uclibc-conf.patch
similarity index 100%
rename from toolchain/gcc/4.4.4/100-uclibc-conf.patch
rename to toolchain/gcc/4.4.5/100-uclibc-conf.patch
diff --git a/toolchain/gcc/4.4.4/301-missing-execinfo_h.patch b/toolchain/gcc/4.4.5/301-missing-execinfo_h.patch
similarity index 100%
rename from toolchain/gcc/4.4.4/301-missing-execinfo_h.patch
rename to toolchain/gcc/4.4.5/301-missing-execinfo_h.patch
diff --git a/toolchain/gcc/4.4.4/302-c99-snprintf.patch b/toolchain/gcc/4.4.5/302-c99-snprintf.patch
similarity index 100%
rename from toolchain/gcc/4.4.4/302-c99-snprintf.patch
rename to toolchain/gcc/4.4.5/302-c99-snprintf.patch
diff --git a/toolchain/gcc/4.4.4/305-libmudflap-susv3-legacy.patch b/toolchain/gcc/4.4.5/305-libmudflap-susv3-legacy.patch
similarity index 100%
rename from toolchain/gcc/4.4.4/305-libmudflap-susv3-legacy.patch
rename to toolchain/gcc/4.4.5/305-libmudflap-susv3-legacy.patch
diff --git a/toolchain/gcc/4.4.4/810-arm-softfloat-libgcc.patch b/toolchain/gcc/4.4.5/810-arm-softfloat-libgcc.patch
similarity index 100%
rename from toolchain/gcc/4.4.4/810-arm-softfloat-libgcc.patch
rename to toolchain/gcc/4.4.5/810-arm-softfloat-libgcc.patch
diff --git a/toolchain/gcc/4.4.4/powerpc-link-with-math-lib.patch.conditional b/toolchain/gcc/4.4.5/powerpc-link-with-math-lib.patch.conditional
similarity index 100%
rename from toolchain/gcc/4.4.4/powerpc-link-with-math-lib.patch.conditional
rename to toolchain/gcc/4.4.5/powerpc-link-with-math-lib.patch.conditional
diff --git a/toolchain/gcc/Config.in b/toolchain/gcc/Config.in
index 760bb98..8d761c3 100644
--- a/toolchain/gcc/Config.in
+++ b/toolchain/gcc/Config.in
@@ -47,7 +47,7 @@ config BR2_GCC_VERSION
default "4.2.2-avr32-2.1.5" if BR2_GCC_VERSION_4_2_2_AVR32_2_1_5
default "4.2.4" if BR2_GCC_VERSION_4_2_4
default "4.3.5" if BR2_GCC_VERSION_4_3_X
- default "4.4.4" if BR2_GCC_VERSION_4_4_X
+ default "4.4.5" if BR2_GCC_VERSION_4_4_X
default $BR2_GCC_SNAP_DATE if BR2_GCC_VERSION_SNAP
config BR2_EXTRA_GCC_CONFIG_OPTIONS
--
1.7.1
^ permalink raw reply related
* [Buildroot] [git commit master 1/1] iw: bump version
From: Peter Korsgaard @ 2010-10-04 7:08 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=e50b4dcbf9a5cf9f391ab0ad72880b5e85ae6dec
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
CHANGES | 8 ++++----
package/iw/iw.mk | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/CHANGES b/CHANGES
index 23a264c..a1168d7 100644
--- a/CHANGES
+++ b/CHANGES
@@ -29,10 +29,10 @@
docker, dosfstools, dropbear, e2fsprogs, expat, ezxml, fbset,
fconfig, ffmpeg, freetype, gadgetfs-test, gamin, gawk, gperf,
gtk2-themes, gtkperf, gvfs, haserl, hdparm, hostapd, hwdata,
- ifplugd, iperf, iproute2, iptables, jpeg, kexec, kismet, less,
- libcgi, libcurl, libdaemon, libdnet, liberation, libevent,
- libglade, libgtk2, libiconv, libidn, libmms, libnl, liboil,
- libpcap, libpng, libtool, libungif, libxml2, libxslt,
+ ifplugd, iperf, iproute2, iptables, iw, jpeg, kexec, kismet,
+ less, libcgi, libcurl, libdaemon, libdnet, liberation,
+ libevent, libglade, libgtk2, libiconv, libidn, libmms, libnl,
+ liboil, libpcap, libpng, libtool, libungif, libxml2, libxslt,
lighttpd, lite, lm-sensors, lockfile-progs, logrotate, m4,
mdadm, mesa3d, metacity, mtd-utils, mysql_client, nano, nbd,
ncftp, neon, netperf, netsnmp, ng-spice-rework, ntfsprogs,
diff --git a/package/iw/iw.mk b/package/iw/iw.mk
index 0f8851a..2c93516 100644
--- a/package/iw/iw.mk
+++ b/package/iw/iw.mk
@@ -4,7 +4,7 @@
#
#############################################################
-IW_VERSION = 0.9.20
+IW_VERSION = 0.9.21
IW_SOURCE = iw-$(IW_VERSION).tar.bz2
IW_SITE = http://wireless.kernel.org/download/iw
IW_DEPENDENCIES = host-pkg-config libnl
--
1.7.1
^ permalink raw reply related
* [Buildroot] [git commit master 1/1] lighttpd: bump version
From: Peter Korsgaard @ 2010-10-04 7:08 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=489e2b803e9ef362cbc4fef675459a6a781bb16a
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
package/lighttpd/lighttpd.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/package/lighttpd/lighttpd.mk b/package/lighttpd/lighttpd.mk
index e6f913c..7d8708a 100644
--- a/package/lighttpd/lighttpd.mk
+++ b/package/lighttpd/lighttpd.mk
@@ -4,7 +4,7 @@
#
#############################################################
-LIGHTTPD_VERSION = 1.4.26
+LIGHTTPD_VERSION = 1.4.28
LIGHTTPD_SITE = http://download.lighttpd.net/lighttpd/releases-1.4.x
LIGHTTPD_LIBTOOL_PATCH = NO
--
1.7.1
^ permalink raw reply related
* [Buildroot] [git commit master 1/1] kernel-headers: bump 2.6.32.x stable version
From: Peter Korsgaard @ 2010-10-04 7:08 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=edb15260e9b15d9944804dfa5ef70b94abefc44f
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
| 2 +-
| 0
2 files changed, 1 insertions(+), 1 deletions(-)
rename toolchain/kernel-headers/{linux-2.6.32.23-scsi-use-__uX-types-for-headers-exported-to-user-space.patch => linux-2.6.32.24-scsi-use-__uX-types-for-headers-exported-to-user-space.patch} (100%)
--git a/toolchain/kernel-headers/Config.in b/toolchain/kernel-headers/Config.in
index bfe6afb..fa79578 100644
--- a/toolchain/kernel-headers/Config.in
+++ b/toolchain/kernel-headers/Config.in
@@ -60,7 +60,7 @@ config BR2_DEFAULT_KERNEL_HEADERS
default "2.6.29.6" if BR2_KERNEL_HEADERS_2_6_29
default "2.6.30.10" if BR2_KERNEL_HEADERS_2_6_30
default "2.6.31.14" if BR2_KERNEL_HEADERS_2_6_31
- default "2.6.32.23" if BR2_KERNEL_HEADERS_2_6_32
+ default "2.6.32.24" if BR2_KERNEL_HEADERS_2_6_32
default "2.6.33.7" if BR2_KERNEL_HEADERS_2_6_33
default "2.6.34.7" if BR2_KERNEL_HEADERS_2_6_34
default "2.6.35.6" if BR2_KERNEL_HEADERS_2_6_35
diff --git a/toolchain/kernel-headers/linux-2.6.32.23-scsi-use-__uX-types-for-headers-exported-to-user-space.patch b/toolchain/kernel-headers/linux-2.6.32.24-scsi-use-__uX-types-for-headers-exported-to-user-space.patch
similarity index 100%
rename from toolchain/kernel-headers/linux-2.6.32.23-scsi-use-__uX-types-for-headers-exported-to-user-space.patch
rename to toolchain/kernel-headers/linux-2.6.32.24-scsi-use-__uX-types-for-headers-exported-to-user-space.patch
--
1.7.1
^ permalink raw reply related
* [Buildroot] [PATCH] Bump iw to 0.9.21
From: Peter Korsgaard @ 2010-10-04 7:07 UTC (permalink / raw)
To: buildroot
In-Reply-To: <4CA48C1D.8050607@zacarias.com.ar>
>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:
Gustavo> Bump iw package to version 0.9.21.
Gustavo> Introduces new bitrate setting command.
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] Libtool work: a tentative summary
From: Martin Banky @ 2010-10-04 1:19 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1286149654.27944.363.camel@coalu.atr>
Lionel,
On the first three items, won't we always have to keep these until all
of the packages either support autoreconfiguring or start using libtool 2.4?
Like I said before, I ran into three packages that wouldn't autoreconfigure,
so they would still need the traditional approach. Also, I haven't had a
chance to really investigate this, but isn't
TARGET_LDFLAGS+=-L$(STAGING_DIR)/lib -L$(STAGING_DIR)/usr/lib also needed by
gentargets to link to the correct libraries?
As for my setup, the only difference is, I compiled libtool with
--with-sysroot (no directory given), and I don't configure the package with
it. libtool gets the sysroot directory from gcc's sysroot, if none is
specified. Everything else is the same. What kind of problems did you
encounter? Was it just the problem with autoreconfiguring packages?
Martin
On Sun, Oct 3, 2010 at 4:47 PM, Lionel Landwerlin <llandwerlin@gmail.com>wrote:
> As long as we keep the following things, we can bump to 2.2 or 2.4 :
> * sed pass on .la files
> * Add -L$(STAGING_DIR)/lib -L$(STAGING_DIR)/usr/lib to LDFLAGS
> * patches for encountered libtool versions
>
> I always took the hypothesis that we wanted to get rid of the first 2,
> and wanted to keep the third only for special cases.
>
> I encountered problem with libtool 2.4 for several packages under the
> following conditions :
> * run autoreconf on the package
> * do not apply the libtool patch
> * configure the package with --with-sysroot=$(STAGING_DIR) option
>
> Martin, did you have the same setup ?
>
> I guess we're back to the current situation if we don't pass the
> --with-sysroot option and we apply a libtool patch for the correct
> libtool version.
>
> Regards,
>
> --
> Lionel Landwerlin
>
> Le dimanche 03 octobre 2010 ? 15:36 -0700, Martin Banky a ?crit :
> > If you want to integrate my patches, I would like to submit a new set
> > of patches with some changes in preparation for libtool 2.4, mainly
> > with Makefile.autotools.in. I have it setup now to distinguish between
> > 1.5.x, 2.2.x, and 2.4. Also, in working on converting the packages to
> > either gentargets or autotargets, I've been noticing a lot of packages
> > have their own libtool patch. I would like to go through, and clean
> > them up. I have a question, why can't we upgrade to libtool 2.4? I've
> > been running it now since I first posted the heads up patch, and have
> > used it with the sysroot option turned on without any obvious issues.
> > If the sysroot option is an issue, we could turn it off for now and
> > use the libtool patches until we integrate the sysroot option
> > properly, right? The imagemagick patch set that I posted, was first
> > done with libtool 2.4 and autoreconfigure turned on. I wanted to make
> > sure that it would work properly in this configuration, in preparation
> > of the coming changes. It was then actually posted with
> > autoreconfigure turned off and using the libtool patch. As a side
> > note, I just realized that imagemagick is using libtool 2.2.x, which
> > means that it's incorporation is blocked until either I add it's own
> > libtool patch or we commit my libtool patch set. Sorry about that. If
> > anyone would like me to add the libtool patch to imagemagick, and
> > repost, let me know.
> >
> > Martin
> >
> > On Sun, Oct 3, 2010 at 7:22 AM, Thomas Petazzoni
> > <thomas.petazzoni@free-electrons.com> wrote:
> > Hello,
> >
> > On Sun, 03 Oct 2010 15:22:26 +0200
> > Lionel Landwerlin <llandwerlin@gmail.com> wrote:
> >
> > > Here is what I would like to us to do for the next
> > releases :
> > >
> > > 1) Bump libtool package to 2.2, more and more packages
> > require libtool
> > > 2.2, and we're stuck to not autoreconfigure them without
> > 2.2. This is
> > > already creating problems to Thomas when trying to bump host
> > > libglib/libgtk packages.
> >
> >
> > 1a) Integrate Martin Banky's proposal so that packages using
> > libtool
> > 2.2 can work without the need to autoreconfigure them.
> >
> > > 2) Eventually integrate some patches to libtool 2.2 to be
> > able to
> > > cross compile autoreconfigured packages.
> > >
> > > 3) When the libtool 2.4 sysroot issue is sorted out, bump to
> > libtool
> > > 2.4 and get rid of the patches integrated in 2).
> > >
> > > I think 1) is mandatory for 2010.11.
> >
> >
> > And 1a).
> >
> > So, I would suggest :
> >
> > *) Peter merges Martin Banky's set of patches on libtool
> >
> >
> http://lists.busybox.net/pipermail/buildroot/2010-September/037505.html
> >
> >
> > *) Lionel, could you propose a patch that just bumps libtool
> > to 2.2 ?
> >
> > Lionel, Martin, Peter, what do you think ?
> >
> > Thanks,
> >
> > Thomas
> > --
> > Thomas Petazzoni, Free Electrons
> > Kernel, drivers, real-time and embedded Linux
> > development, consulting, training and support.
> > http://free-electrons.com
> > _______________________________________________
> >
> >
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
> >
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101003/a3480adb/attachment.html>
^ permalink raw reply
* [Buildroot] Libtool work: a tentative summary
From: Lionel Landwerlin @ 2010-10-03 23:47 UTC (permalink / raw)
To: buildroot
In-Reply-To: <AANLkTi=KGLw6j0fYTp=ANV8zFGSrMH1xPv=pHM_BEtym@mail.gmail.com>
As long as we keep the following things, we can bump to 2.2 or 2.4 :
* sed pass on .la files
* Add -L$(STAGING_DIR)/lib -L$(STAGING_DIR)/usr/lib to LDFLAGS
* patches for encountered libtool versions
I always took the hypothesis that we wanted to get rid of the first 2,
and wanted to keep the third only for special cases.
I encountered problem with libtool 2.4 for several packages under the
following conditions :
* run autoreconf on the package
* do not apply the libtool patch
* configure the package with --with-sysroot=$(STAGING_DIR) option
Martin, did you have the same setup ?
I guess we're back to the current situation if we don't pass the
--with-sysroot option and we apply a libtool patch for the correct
libtool version.
Regards,
--
Lionel Landwerlin
Le dimanche 03 octobre 2010 ? 15:36 -0700, Martin Banky a ?crit :
> If you want to integrate my patches, I would like to submit a new set
> of patches with some changes in preparation for libtool 2.4, mainly
> with Makefile.autotools.in. I have it setup now to distinguish between
> 1.5.x, 2.2.x, and 2.4. Also, in working on converting the packages to
> either gentargets or autotargets, I've been noticing a lot of packages
> have their own libtool patch. I would like to go through, and clean
> them up. I have a question, why can't we upgrade to libtool 2.4? I've
> been running it now since I first posted the heads up patch, and have
> used it with the sysroot option turned on without any obvious issues.
> If the sysroot option is an issue, we could turn it off for now and
> use the libtool patches until we integrate the sysroot option
> properly, right? The imagemagick patch set that I posted, was first
> done with libtool 2.4 and autoreconfigure turned on. I wanted to make
> sure that it would work properly in this configuration, in preparation
> of the coming changes. It was then actually posted with
> autoreconfigure turned off and using the libtool patch. As a side
> note, I just realized that imagemagick is using libtool 2.2.x, which
> means that it's incorporation is blocked until either I add it's own
> libtool patch or we commit my libtool patch set. Sorry about that. If
> anyone would like me to add the libtool patch to imagemagick, and
> repost, let me know.
>
> Martin
>
> On Sun, Oct 3, 2010 at 7:22 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Sun, 03 Oct 2010 15:22:26 +0200
> Lionel Landwerlin <llandwerlin@gmail.com> wrote:
>
> > Here is what I would like to us to do for the next
> releases :
> >
> > 1) Bump libtool package to 2.2, more and more packages
> require libtool
> > 2.2, and we're stuck to not autoreconfigure them without
> 2.2. This is
> > already creating problems to Thomas when trying to bump host
> > libglib/libgtk packages.
>
>
> 1a) Integrate Martin Banky's proposal so that packages using
> libtool
> 2.2 can work without the need to autoreconfigure them.
>
> > 2) Eventually integrate some patches to libtool 2.2 to be
> able to
> > cross compile autoreconfigured packages.
> >
> > 3) When the libtool 2.4 sysroot issue is sorted out, bump to
> libtool
> > 2.4 and get rid of the patches integrated in 2).
> >
> > I think 1) is mandatory for 2010.11.
>
>
> And 1a).
>
> So, I would suggest :
>
> *) Peter merges Martin Banky's set of patches on libtool
>
> http://lists.busybox.net/pipermail/buildroot/2010-September/037505.html
>
>
> *) Lionel, could you propose a patch that just bumps libtool
> to 2.2 ?
>
> Lionel, Martin, Peter, what do you think ?
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
>
>
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply
* [Buildroot] Libtool work: a tentative summary
From: Martin Banky @ 2010-10-03 22:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20101003162219.62ad7888@surf>
If you want to integrate my patches, I would like to submit a new set of
patches with some changes in preparation for libtool 2.4, mainly with
Makefile.autotools.in. I have it setup now to distinguish between 1.5.x,
2.2.x, and 2.4. Also, in working on converting the packages to either
gentargets or autotargets, I've been noticing a lot of packages have their
own libtool patch. I would like to go through, and clean them up. I have a
question, why can't we upgrade to libtool 2.4? I've been running it now
since I first posted the heads up patch, and have used it with the sysroot
option turned on without any obvious issues. If the sysroot option is an
issue, we could turn it off for now and use the libtool patches until we
integrate the sysroot option properly, right? The imagemagick patch set that
I posted, was first done with libtool 2.4 and autoreconfigure turned on. I
wanted to make sure that it would work properly in this configuration, in
preparation of the coming changes. It was then actually posted with
autoreconfigure turned off and using the libtool patch. As a side note, I
just realized that imagemagick is using libtool 2.2.x, which means that it's
incorporation is blocked until either I add it's own libtool patch or we
commit my libtool patch set. Sorry about that. If anyone would like me to
add the libtool patch to imagemagick, and repost, let me know.
Martin
On Sun, Oct 3, 2010 at 7:22 AM, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Sun, 03 Oct 2010 15:22:26 +0200
> Lionel Landwerlin <llandwerlin@gmail.com> wrote:
>
> > Here is what I would like to us to do for the next releases :
> >
> > 1) Bump libtool package to 2.2, more and more packages require libtool
> > 2.2, and we're stuck to not autoreconfigure them without 2.2. This is
> > already creating problems to Thomas when trying to bump host
> > libglib/libgtk packages.
>
> 1a) Integrate Martin Banky's proposal so that packages using libtool
> 2.2 can work without the need to autoreconfigure them.
>
> > 2) Eventually integrate some patches to libtool 2.2 to be able to
> > cross compile autoreconfigured packages.
> >
> > 3) When the libtool 2.4 sysroot issue is sorted out, bump to libtool
> > 2.4 and get rid of the patches integrated in 2).
> >
> > I think 1) is mandatory for 2010.11.
>
> And 1a).
>
> So, I would suggest :
>
> *) Peter merges Martin Banky's set of patches on libtool
>
> http://lists.busybox.net/pipermail/buildroot/2010-September/037505.html
>
> *) Lionel, could you propose a patch that just bumps libtool to 2.2 ?
>
> Lionel, Martin, Peter, what do you think ?
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20101003/d697e920/attachment.html>
^ permalink raw reply
* [Buildroot] Libtool work: a tentative summary
From: Thomas Petazzoni @ 2010-10-03 14:22 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1286112146.27944.349.camel@coalu.atr>
Hello,
On Sun, 03 Oct 2010 15:22:26 +0200
Lionel Landwerlin <llandwerlin@gmail.com> wrote:
> Here is what I would like to us to do for the next releases :
>
> 1) Bump libtool package to 2.2, more and more packages require libtool
> 2.2, and we're stuck to not autoreconfigure them without 2.2. This is
> already creating problems to Thomas when trying to bump host
> libglib/libgtk packages.
1a) Integrate Martin Banky's proposal so that packages using libtool
2.2 can work without the need to autoreconfigure them.
> 2) Eventually integrate some patches to libtool 2.2 to be able to
> cross compile autoreconfigured packages.
>
> 3) When the libtool 2.4 sysroot issue is sorted out, bump to libtool
> 2.4 and get rid of the patches integrated in 2).
>
> I think 1) is mandatory for 2010.11.
And 1a).
So, I would suggest :
*) Peter merges Martin Banky's set of patches on libtool
http://lists.busybox.net/pipermail/buildroot/2010-September/037505.html
*) Lionel, could you propose a patch that just bumps libtool to 2.2 ?
Lionel, Martin, Peter, what do you think ?
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] Libtool work: a tentative summary
From: Lionel Landwerlin @ 2010-10-03 13:22 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20100928223652.6dc72083@surf>
Hello,
Here is what I would like to us to do for the next releases :
1) Bump libtool package to 2.2, more and more packages require libtool
2.2, and we're stuck to not autoreconfigure them without 2.2. This is
already creating problems to Thomas when trying to bump host
libglib/libgtk packages.
2) Eventually integrate some patches to libtool 2.2 to be able to cross
compile autoreconfigured packages.
3) When the libtool 2.4 sysroot issue is sorted out, bump to libtool 2.4
and get rid of the patches integrated in 2).
I think 1) is mandatory for 2010.11.
Regards,
--
Lionel Landwerlin
Le mardi 28 septembre 2010 ? 22:36 +0200, Thomas Petazzoni a ?crit :
> Hello,
>
> There has recently been quite some work done around libtool handling in
> Buildroot, in the form of two proposals done by Martin Banky and Lionel
> Landwerlin. Those two proposals are quite different and we need to make
> a choice between them. This e-mail tries to summarize the libtool
> problem, how it is currently handled in Buildroot, the technical
> proposals made by Martin and Lionel with their respective advantages
> and drawbacks. Martin and Lionel are obviously invited to comment on
> those (and the rest of this e-mail as well).
>
> Libtool problems
> ================
>
> Libtool problems in cross-compilation mode are well-known. The
> famous http://www.metastatic.org/text/libtool.html lists most of the
> problems, and some hacks to solve them.
>
> Basically, Libtool does not understand the fact that we may be building
> a root filesystem in a different place than "/", and keeps looking
> in /usr/lib for libraries.
>
> It is worth noting that libtool 2.4 has finally introduced a --sysroot
> argument which should finally solve those problems. However, until
> libtool 2.4 is picked up by most packages, we will have to live with
> the libtool problems for quite some time. See
> http://lists.gnu.org/archive/html/libtool/2010-09/msg00082.html.
>
> Current Buildroot solution
> ==========================
>
> The current Buildroot solution consists in two mechanisms :
>
> *) Apply the package/buildroot-libtool.patch to packages when
> <pkg>_LIBTOOL_PATCH is YES. This is the default value for
> autotools-based packages.
>
> This patch directly modifies the ltmain.sh script, which will be
> used to generate the libtool script in the package as configure
> time.
>
> This patch only works with libtool 1.5.x, but a number of packages
> are now using libtool 2.2.x, so more and more packages are doing
> <pkg>_LIBTOOL_PATCH=NO to disable the patch. This works for most
> packages but not for others (example: I'm bumping GTK to 2.20 and
> it needs a patch for the ltmain.sh script which has been generated
> by libtool 2.2.x)
>
> *) Modify the .la files installed by Buildroot in order to add
> $(STAGING_DIR) at the beginning of the "libdir" paths.
>
> Martin Banky proposal
> =====================
>
> Martin Banky has sent a proposal to improve libtool handling in
> Buildroot on September 16th. See
> http://lists.busybox.net/pipermail/buildroot/2010-September/037505.html
> and the following 4 e-mails from Martin.
>
> Basically, Martin's proposal is to continue with the current solution
> to the libtool problem, but to clean it up a bit and to extend it to
> libtool 2.2.
>
> This patch set has 3 main components :
>
> *) Simplify the existing package/buildroot-libtool.patch by removing
> useless chunks
>
> *) Rename package/buildroot-libtool.patch to
> package/buildroot-libtool-v1.5.patch, add a new
> package/buildroot-libtool-v2.2.patch. Those two patches
> respectively modify the ltmain.sh generated by libtool 1.5 and 2.2.
> Then the Autotools infrastructure is modified to apply one patch or
> the other depending on which libtool version the package is using.
>
> *) The remaining modifications remove libtool-related patches in
> various packages that have become useless thanks to the previous
> patches.
>
> Advantages of this approach :
>
> *) We're keeping the current solution and only cleanup/extend it to
> work with recent libtool versions. This is good from a
> "conservative" point of view.
>
> *) As today, we don't need to autoreconf all autotools-based packages
> just to fix the libtool issue.
>
> Drawbacks of this approach :
>
> *) We may have similar issues with future versions of libtool, even if
> the addition of --sysroot to libtool 2.4 probably means that libtool
> 1.5 and 2.2 will remain the only two versions of libtool causing
> problems in widespread use.
>
> *) It keeps the current solution, which is a bit ugly: modify scripts
> that are generated, and hack the .la files.
>
> *) It modifies the .la by adding informations relative to
> $(STAGING_DIR), which may cause problems if we want to generate
> packages (.ipkg) or if we would like to allow users to relocate the
> Buildroot staging directory.
>
> Lionel Landwerlin proposal
> ==========================
>
> Lionel Landwerlin has sent a proposal to improve libtool handling in
> Buildroot on September, 18th. See
> http://lists.busybox.net/pipermail/buildroot/2010-September/037663.html
> for the mailing list post.
>
> Basically, Lionel's proposal is to patch libtool itself to make it
> sysroot-capable and then autoreconfigure all autotools-based packages
> to make them use the fixed libtool version.
>
> Lionel's proposal is relatively complicated because in order for the
> patch on libtool to take effect, libtool itself needs to be
> autoreconfigured, which in turn requires libtool. So Lionel has
> introduced a host-libtool-host package, which is an unmodified libtool,
> installed in a new $(HOST_HOST_DIR) directory. He later uses that
> host-libtool-host to autoreconfigure the host-libtool (which has been
> previously patched to understand sysroot related things).
> host-libtool-host will be kept for the autoreconfiguration of host
> packages, while host-libtool is used for the autoreconfiguration of
> target packages. (If your head hasn't exploded yet, keep reading,
> otherwise, take a break and come back in 10 minutes). This is what the
> first patch in Lionel patch set does. The other patches are only minor
> related changes.
>
> Advantages of this approach :
>
> *) We no longer arbitrarly patch ltmain.sh in every package, with the
> need to carry libtool-version-specific patches.
>
> *) We no longer need to modify the .la files.
>
> *) The approach seems cleaner.
>
> *) It is closer to what we could have with libtool 2.4, except that
> libtool 2.4 wouldn't need to be patch as it already supports
> --sysroot by default. Therefore, a large part of the complexity of
> this patch set could be removed (since we wouldn't have to
> autoreconfigure libtool itself). However, we'd still need to
> autoreconfigure all autotools-based packages (see below). I know
> Lionel has started experimenting with libtool 2.4, as can be seen
> on
> http://lists.gnu.org/archive/html/bug-libtool/2010-09/msg00064.html
>
> Drawbacks of this approach :
>
> *) We need to autoreconfigure *ALL* autotools-based packages. This may
> be an issue for two reasons: 1/ speed, 2/ packages for which
> autoreconfiguration does not work properly (yes those packages
> should be fixed, but anyway, this may add some work to us).
> Obviously, as packages will start using libtool 2.4 by default,
> this shouldn't be a problem, but we all know that it's going to
> take years before everybody moves to that newer libtool version.
>
> *) The HOST_HOST_DIR thing and the host-libtool-host as it is
> implemented today is pretty ugly. I'd rather have a either single
> libtool installed in $(HOST_DIR), which work for both the
> autoreconfiguration of host and target packages, or have two
> libtools installed in $(HOST_DIR), on for host packages (just named
> 'libtool') and another for target packages (named 'cross-libtool'
> or something similar).
>
> Conclusion
> ==========
>
> Therefore, the choice seems to be between :
>
> * A conservative solution, only extending what we have today, with
> limited changes and impact, but keeping the existing hacks in place.
>
> * A radically different solution, with wider changes, more in line
> with libtool future, but requiring an autoreconfiguration of all
> packages that will not have libtool 2.4 by default.
>
> In my opinion, we should settle on a solution before mid-october, in
> order to merge it before the end of october and give us enough time for
> testing before the release at the end of november. Considering how much
> time Martin and Lionel have dedicated to this issue, I think that their
> respective work deserve some attention.
>
> Thoughts ? Comments ?
>
> Thomas
^ 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