* [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
* [Buildroot] [PATCH 1/3] libgtk2: bump to version 2.20.1 and mark Gtk/DirectFB as broken
From: Thomas Petazzoni @ 2010-10-03 11:13 UTC (permalink / raw)
To: buildroot
In-Reply-To: <871v8bz9x4.fsf@macbook.be.48ers.dk>
On Thu, 30 Sep 2010 14:35:19 +0200
Peter Korsgaard <jacmet@uclibc.org> wrote:
> Thomas> Argh, I checked http://www.gtk.org/download-linux.html
> Thomas> yesterday, and it still advertise Gtk 2.20 and Glib 2.24.
>
> Thomas> I will bump those versions, yes, and mark the DirectFB
> Thomas> support as working again.
>
> Ok, I'll put your pull request on hold for now then. Please resend
> once ready.
Unfortunately, things are not that simple.
In order to reduce the number of dependencies needed to build
host-libgtk2 (in which a few tools are needed to build the target
libgtk2), we apply a patch to libgtk2 configure.in file. Applying a
patch to the configure.in obviously means that host-libgtk2 needs to be
auto-reconfigured.
However, libgtk2 2.22 now requires libtool 2.2, and we only have
libtool 1.5. So unless we upgrade libtool to 2.2, it is not possible to
autoreconfigure libgtk2 and therefore not possible to apply a patch to
its configure.in file.
We *really* need to take a decision on the libtool stuff. I've sent a
summary of the two proposals and would like to see some more reactions
to it in order to move forward on this topic.
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH 2/2] libeXosip2: convert to autotargets and bump to 3.3.0
From: Martin Banky @ 2010-10-02 22:06 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1286057184-3486-1-git-send-email-Martin.Banky@gmail.com>
Signed-off-by: Martin Banky <Martin.Banky@gmail.com>
---
package/libeXosip2/libeXosip2.mk | 109 +++++++------------------------------
1 files changed, 21 insertions(+), 88 deletions(-)
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.3.1
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] libosip2: change site location and bump to 3.3.0
From: Martin Banky @ 2010-10-02 22:06 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1286057184-3486-1-git-send-email-Martin.Banky@gmail.com>
Change the site location to debian mirror to get the latest debian patches.
Signed-off-by: Martin Banky <Martin.Banky@gmail.com>
---
package/libosip2/libosip2.mk | 26 ++++++++++++++++++--------
1 files changed, 18 insertions(+), 8 deletions(-)
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.3.1
^ permalink raw reply related
* [Buildroot] [PATCH 0/2] libeXosip2: convert to autotargets and bump to 3.3.0
From: Martin Banky @ 2010-10-02 22:06 UTC (permalink / raw)
To: buildroot
Both patches are needed for this to work properly.
Martin
[PATCH 1/2] libosip2: change site location and bump to 3.3.0
[PATCH 2/2] libeXosip2: convert to autotargets and bump to 3.3.0
^ permalink raw reply
* [Buildroot] [PATCH 2/2] imagemagick: convert to autotargets and bump to 6.6.4
From: Martin Banky @ 2010-10-02 20:51 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1286052682-22218-1-git-send-email-Martin.Banky@gmail.com>
program-transform-name='s,,,' is needed, otherwise configure defines it as
$(platform)-$(cpu)-. During install, all executables are prepended with this
variable.
Signed-off-by: Martin Banky <Martin.Banky@gmail.com>
---
....3.4-add-errno-h-if-argz-h-does-not-exist.patch | 11 --
....6.4-add-errno-h-if-argz-h-does-not-exist.patch | 11 ++
package/imagemagick/imagemagick.mk | 148 ++------------------
3 files changed, 25 insertions(+), 145 deletions(-)
delete mode 100644 package/imagemagick/imagemagick-6.3.4-add-errno-h-if-argz-h-does-not-exist.patch
create mode 100644 package/imagemagick/imagemagick-6.6.4-add-errno-h-if-argz-h-does-not-exist.patch
diff --git a/package/imagemagick/imagemagick-6.3.4-add-errno-h-if-argz-h-does-not-exist.patch b/package/imagemagick/imagemagick-6.3.4-add-errno-h-if-argz-h-does-not-exist.patch
deleted file mode 100644
index a11fdd2..0000000
--- a/package/imagemagick/imagemagick-6.3.4-add-errno-h-if-argz-h-does-not-exist.patch
+++ /dev/null
@@ -1,11 +0,0 @@
---- ImageMagick-6.3.4.old/configure 2007-05-12 05:49:25.000000000 +0200
-+++ ImageMagick-6.3.4.new/configure 2007-05-21 16:53:32.000000000 +0200
-@@ -9484,6 +9484,8 @@ cat >>conftest.$ac_ext <<_ACEOF
- /* end confdefs.h. */
- #if HAVE_ARGZ_H
- # include <argz.h>
-+#else
-+# include <errno.h>
- #endif
-
- typedef error_t ac__type_new_;
diff --git a/package/imagemagick/imagemagick-6.6.4-add-errno-h-if-argz-h-does-not-exist.patch b/package/imagemagick/imagemagick-6.6.4-add-errno-h-if-argz-h-does-not-exist.patch
new file mode 100644
index 0000000..66a6747
--- /dev/null
+++ b/package/imagemagick/imagemagick-6.6.4-add-errno-h-if-argz-h-does-not-exist.patch
@@ -0,0 +1,11 @@
+--- a/configure 2010-09-26 17:05:45.000000000 -0700
++++ b/configure 2010-09-30 23:47:09.000000000 -0700
+@@ -20354,6 +20354,8 @@ done
+
+ ac_fn_c_check_type "$LINENO" "error_t" "ac_cv_type_error_t" "#if defined(HAVE_ARGZ_H)
+ # include <argz.h>
++#else
++# include <errno.h>
+ #endif
+ "
+ if test "x$ac_cv_type_error_t" = xyes; then :
diff --git a/package/imagemagick/imagemagick.mk b/package/imagemagick/imagemagick.mk
index 9eb9d69..996abc7 100644
--- a/package/imagemagick/imagemagick.mk
+++ b/package/imagemagick/imagemagick.mk
@@ -3,50 +3,21 @@
# imagemagick
#
#############################################################
-IMAGEMAGICK_MAJOR:=6.4.8
-IMAGEMAGICK_VERSION:=$(IMAGEMAGICK_MAJOR)-4
-IMAGEMAGICK_SOURCE:=ImageMagick-$(IMAGEMAGICK_VERSION).tar.bz2
-IMAGEMAGICK_SITE:=ftp://ftp.imagemagick.org/pub/ImageMagick
-IMAGEMAGICK_DIR:=$(BUILD_DIR)/ImageMagick-$(IMAGEMAGICK_VERSION)
-IMAGEMAGICK_CAT:=$(BZCAT)
-IMAGEMAGICK_LIB:=$(TARGET_DIR)/usr/lib/libMagickCore.so
+IMAGEMAGICK_MAJOR = 6.6.4
+IMAGEMAGICK_VERSION = $(IMAGEMAGICK_MAJOR)-8
+IMAGEMAGICK_SOURCE = ImageMagick-$(IMAGEMAGICK_VERSION).tar.bz2
+IMAGEMAGICK_SITE = ftp://ftp.imagemagick.org/pub/ImageMagick
+IMAGEMAGICK_INSTALL_STAGING = YES
-IMAGEMAGICK_TARGET_BINARIES:=$(TARGET_DIR)/usr/bin/animate
-IMAGEMAGICK_TARGET_BINARIES+=$(TARGET_DIR)/usr/bin/compare
-IMAGEMAGICK_TARGET_BINARIES+=$(TARGET_DIR)/usr/bin/composite
-IMAGEMAGICK_TARGET_BINARIES+=$(TARGET_DIR)/usr/bin/conjure
-IMAGEMAGICK_TARGET_BINARIES+=$(TARGET_DIR)/usr/bin/display
-IMAGEMAGICK_TARGET_BINARIES+=$(TARGET_DIR)/usr/bin/import
-IMAGEMAGICK_TARGET_BINARIES+=$(TARGET_DIR)/usr/bin/mogrify
-IMAGEMAGICK_TARGET_BINARIES+=$(TARGET_DIR)/usr/bin/montage
-IMAGEMAGICK_TARGET_BINARIES+=$(TARGET_DIR)/usr/bin/convert
-
-IMAGEMAGICK_COPY:=cp -df --preserve=mode,ownership
-$(DL_DIR)/$(IMAGEMAGICK_SOURCE):
- $(call DOWNLOAD,$(IMAGEMAGICK_SITE),$(IMAGEMAGICK_SOURCE))
-
-$(IMAGEMAGICK_DIR)/.unpacked: $(DL_DIR)/$(IMAGEMAGICK_SOURCE)
- $(IMAGEMAGICK_CAT) $(DL_DIR)/$(IMAGEMAGICK_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) -
- toolchain/patch-kernel.sh $(IMAGEMAGICK_DIR) package/imagemagick/ imagemagick-$(IMAGEMAGICK_VERSION)\*.patch\*
- $(CONFIG_UPDATE) $(IMAGEMAGICK_DIR)/config
- touch $@
+IMAGEMAGICK_DEPENDENCIES = jpeg tiff
ifeq ($(BR2_LARGEFILE),y)
-IMAGEMAGICK_CONF_OPTS = ac_cv_sys_file_offset_bits=64
+IMAGEMAGICK_CONF_ENV = ac_cv_sys_file_offset_bits=64
else
-IMAGEMAGICK_CONF_OPTS = ac_cv_sys_file_offset_bits=32
+IMAGEMAGICK_CONF_ENV = ac_cv_sys_file_offset_bits=32
endif
-$(IMAGEMAGICK_DIR)/.configured: $(IMAGEMAGICK_DIR)/.unpacked
- (cd $(IMAGEMAGICK_DIR); rm -f config.cache; \
- $(TARGET_CONFIGURE_OPTS) \
- $(TARGET_CONFIGURE_ARGS) \
- ./configure $(QUIET) \
- --target=$(GNU_TARGET_NAME) \
- --host=$(GNU_TARGET_NAME) \
- --build=$(GNU_HOST_NAME) \
- --prefix=/usr \
- --sysconfdir=/etc \
+IMAGEMAGICK_CONF_OPT = --program-transform-name='s,,,' \
--without-perl \
--without-wmf \
--without-xml \
@@ -60,101 +31,10 @@ $(IMAGEMAGICK_DIR)/.configured: $(IMAGEMAGICK_DIR)/.unpacked
--without-gslib \
--without-fpx \
--without-freetype \
- --without-x \
- $(IMAGEMAGICK_CONF_OPTS) \
- )
- touch $@
-
-$(IMAGEMAGICK_DIR)/.compiled: $(IMAGEMAGICK_DIR)/.configured
- $(MAKE) -C $(IMAGEMAGICK_DIR)
- touch $@
-
-$(STAGING_DIR)/usr/lib/libMagickCore.a: $(IMAGEMAGICK_DIR)/.compiled
- $(MAKE) DESTDIR=$(STAGING_DIR) -C $(IMAGEMAGICK_DIR) install
- touch -c $@
-
-$(IMAGEMAGICK_LIB): $(STAGING_DIR)/usr/lib/libMagickCore.a
- $(IMAGEMAGICK_COPY) $(STAGING_DIR)/usr/lib/libMagickWand.so* $(TARGET_DIR)/usr/lib/
- -$(STRIPCMD) $(STRIP_STRIP_UNNEEDED) $(TARGET_DIR)/usr/lib/libMagickWand.so*
- mkdir -p $(TARGET_DIR)/usr/lib/ImageMagick-$(IMAGEMAGICK_MAJOR)
- $(IMAGEMAGICK_COPY) -r $(STAGING_DIR)/usr/lib/ImageMagick-$(IMAGEMAGICK_MAJOR) $(TARGET_DIR)/usr/lib
- $(IMAGEMAGICK_COPY) $(STAGING_DIR)/usr/lib/libMagickCore.so* $(TARGET_DIR)/usr/lib/
- -$(STRIPCMD) $(STRIP_STRIP_UNNEEDED) $(IMAGEMAGICK_LIB)*
- touch -c $@
-
-$(IMAGEMAGICK_DIR)/.libinstall: $(IMAGEMAGICK_LIB)
- $(IMAGEMAGICK_DIR)/libtool --finish $(TARGET_DIR)/usr/lib/ImageMagick-$(IMAGEMAGICK_MAJOR)/modules-Q16/coders
- $(IMAGEMAGICK_DIR)/libtool --finish $(TARGET_DIR)/usr/lib/ImageMagick-$(IMAGEMAGICK_MAJOR)/modules-Q16/filters
- touch $@
-
-$(TARGET_DIR)/usr/bin/animate: $(IMAGEMAGICK_LIB)
- $(IMAGEMAGICK_COPY) $(STAGING_DIR)/usr/bin/$(GNU_TARGET_NAME)-animate $(TARGET_DIR)/usr/bin/animate
- -$(STRIPCMD) $(STRIP_STRIP_UNNEEDED) $(TARGET_DIR)/usr/bin/animate
- touch $@
-
-$(TARGET_DIR)/usr/bin/compare: $(IMAGEMAGICK_LIB)
- $(IMAGEMAGICK_COPY) $(STAGING_DIR)/usr/bin/$(GNU_TARGET_NAME)-compare $(TARGET_DIR)/usr/bin/compare
- -$(STRIPCMD) $(STRIP_STRIP_UNNEEDED) $(TARGET_DIR)/usr/bin/compare
- touch $@
-
-$(TARGET_DIR)/usr/bin/composite: $(IMAGEMAGICK_LIB)
- $(IMAGEMAGICK_COPY) $(STAGING_DIR)/usr/bin/$(GNU_TARGET_NAME)-composite $(TARGET_DIR)/usr/bin/composite
- -$(STRIPCMD) $(STRIP_STRIP_UNNEEDED) $(TARGET_DIR)/usr/bin/composite
- touch $@
-
-$(TARGET_DIR)/usr/bin/conjure: $(IMAGEMAGICK_LIB)
- $(IMAGEMAGICK_COPY) $(STAGING_DIR)/usr/bin/$(GNU_TARGET_NAME)-conjure $(TARGET_DIR)/usr/bin/conjure
- -$(STRIPCMD) $(STRIP_STRIP_UNNEEDED) $(TARGET_DIR)/usr/bin/conjure
- touch $@
-
-$(TARGET_DIR)/usr/bin/display: $(IMAGEMAGICK_LIB)
- $(IMAGEMAGICK_COPY) $(STAGING_DIR)/usr/bin/$(GNU_TARGET_NAME)-display $(TARGET_DIR)/usr/bin/display
- -$(STRIPCMD) $(STRIP_STRIP_UNNEEDED) $(TARGET_DIR)/usr/bin/display
- touch $@
-
-$(TARGET_DIR)/usr/bin/import: $(IMAGEMAGICK_LIB)
- $(IMAGEMAGICK_COPY) $(STAGING_DIR)/usr/bin/$(GNU_TARGET_NAME)-import $(TARGET_DIR)/usr/bin/import
- -$(STRIPCMD) $(STRIP_STRIP_UNNEEDED) $(TARGET_DIR)/usr/bin/import
- touch $@
+ --without-x
-$(TARGET_DIR)/usr/bin/mogrify: $(IMAGEMAGICK_LIB)
- $(IMAGEMAGICK_COPY) $(STAGING_DIR)/usr/bin/$(GNU_TARGET_NAME)-mogrify $(TARGET_DIR)/usr/bin/mogrify
- -$(STRIPCMD) $(STRIP_STRIP_UNNEEDED) $(TARGET_DIR)/usr/bin/mogrify
- touch $@
+define ICU_INSTALL_STAGING_CMDS
+ $(MAKE) DESTDIR=$(STAGING_DIR) -C $(@D) install
+endef
-$(TARGET_DIR)/usr/bin/montage: $(IMAGEMAGICK_LIB)
- $(IMAGEMAGICK_COPY) $(STAGING_DIR)/usr/bin/$(GNU_TARGET_NAME)-montage $(TARGET_DIR)/usr/bin/montage
- -$(STRIPCMD) $(STRIP_STRIP_UNNEEDED) $(TARGET_DIR)/usr/bin/montage
- touch $@
-
-$(TARGET_DIR)/usr/bin/convert: $(IMAGEMAGICK_LIB)
- $(IMAGEMAGICK_COPY) $(STAGING_DIR)/usr/bin/$(GNU_TARGET_NAME)-convert $(TARGET_DIR)/usr/bin/convert
- -$(STRIPCMD) $(STRIP_STRIP_UNNEEDED) $(TARGET_DIR)/usr/bin/convert
- touch $@
-
-imagemagick: jpeg tiff $(IMAGEMAGICK_LIB) \
- $(IMAGEMAGICK_DIR)/.libinstall \
- $(IMAGEMAGICK_TARGET_BINARIES)
-
-imagemagick-source: $(DL_DIR)/$(IMAGEMAGICK_SOURCE)
-
-imagemagick-unpacked:$(IMAGEMAGICK_DIR)/.unpacked
-
-imagemagick-clean:
- for target_binary in $(IMAGEMAGICK_TARGET_BINARIES); do \
- rm -f $$target_binary; \
- done
- rm -rf $(TARGET_DIR)/usr/lib/libMagick*
- rm -rf $(TARGET_DIR)/usr/lib/ImageMagick-$(IMAGEMAGICK_MAJOR)
- -$(MAKE) -C $(IMAGEMAGICK_DIR) clean
-
-imagemagick-dirclean:
- rm -rf $(IMAGEMAGICK_DIR)
-#############################################################
-#
-# Toplevel Makefile options
-#
-#############################################################
-ifeq ($(BR2_PACKAGE_IMAGEMAGICK),y)
-TARGETS+=imagemagick
-endif
+$(eval $(call AUTOTARGETS,package,imagemagick))
--
1.7.3.1
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] jpeg: bump to 8b
From: Martin Banky @ 2010-10-02 20:51 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1286052682-22218-1-git-send-email-Martin.Banky@gmail.com>
Signed-off-by: Martin Banky <Martin.Banky@gmail.com>
---
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.3.1
^ permalink raw reply related
* [Buildroot] [PATCH 0/2] imagemagick: convert to autotargets and bump to 6.6.4
From: Martin Banky @ 2010-10-02 20:51 UTC (permalink / raw)
To: buildroot
Both patches are needed for this to work properly.
Martin
[PATCH 1/2] jpeg: bump to 8b
[PATCH 2/2] imagemagick: convert to autotargets and bump to 6.6.4
^ permalink raw reply
* [Buildroot] libpng install question
From: H Hartley Sweeten @ 2010-10-01 16:33 UTC (permalink / raw)
To: buildroot
In-Reply-To: <AANLkTi=2p=Zesb=ruU5MVfQdJGy7nSG=OL1FPXMFEtd3@mail.gmail.com>
On Friday, October 01, 2010 1:14 AM, Lionel Landwerlin wrote:
>
> libpng12-config and libpng-config are part of the libpng package, so
> it is normal they are being installed on the target. However they
> shouldn't be installed unless you've selected to installed development
> files in the buildroot config.
> This might be a small regression introduced by this commit :
> http://git.buildroot.org/buildroot/commit/?id=55ade5c7964e15f9b1eba061ab840cc4c25e4e37
> Are you using a recent version of the buildroot's git repository ?
I don't think that commit is the problem. It just changes the install step
from "make install-strip" to "make install". But, I could be wrong...
Yesterday, after I noticed the files on my rootfs, I did a pull of the latest
buildroot git repository so I should be current.
I also just checked my .config and BR2_HAVE_DEVFILES is not selected.
It looks like something in the configure step for libpng is causing the
-config files to be built and installed on the target. Also, is the old
library (libpng12) needed? It appears that it can optionally be excluded
also.
Regards,
Hartley
^ permalink raw reply
* [Buildroot] [PATCH 2/2] toolchain: add new toolchain backend: crosstool-NG
From: Peter Korsgaard @ 2010-10-01 14:44 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1284926049-9882-3-git-send-email-yann.morin.1998@anciens.enib.fr>
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@anciens.enib.fr> writes:
Yann> Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Committed, thanks a lot!
I fixed a few minor things (Config.in should be indented with tabs, we
normally don't use a seperate prompt ".." line, and shuffled the make
targets around slightly so they follow the logic flow
(download/extract/patch/configure/build/.. rather than the other way
around).
I've noticed that you're not propagating some of the toolchain options
(like wchar) to ct-ng, but we can add that later.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [git commit master 1/1] toolchain/gdb: fix WCHAR typo
From: Peter Korsgaard @ 2010-10-01 14:41 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=11334624c1e30d3858e15724b57178fbb93136a0
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
toolchain/gdb/Config.in | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/toolchain/gdb/Config.in b/toolchain/gdb/Config.in
index edd8715..b45de9a 100644
--- a/toolchain/gdb/Config.in
+++ b/toolchain/gdb/Config.in
@@ -8,7 +8,7 @@ config BR2_PACKAGE_GDB
Build the full gdb debugger to run on the target.
comment "Gdb debugger for the target needs WCHAR support in toolchain"
- depends on !BR2_USE_WHCAR
+ depends on !BR2_USE_WCHAR
config BR2_PACKAGE_GDB_SERVER
bool "Build gdb server for the Target"
--
1.7.1
^ permalink raw reply related
* [Buildroot] [git commit master 1/1] toolchain: add new toolchain backend: crosstool-NG
From: Yann E. MORIN @ 2010-10-01 14:41 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=10c1eec2c3351e8a7040431d3178b5a3104db5a2
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
[Peter: indent Config.in, shuffle make targets around]
Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Patch is too large, so refusing to show it
^ permalink raw reply
* [Buildroot] [SECURITY][PATCHv2] Bump quagga to 0.99.17
From: Gustavo Zacarias @ 2010-10-01 13:41 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20100930234735.4ffdc3ea@surf>
On 09/30/10 18:47, Thomas Petazzoni wrote:
> I confirm that since Gustavo converted the package to autotargets, the
> previously existing build failures with external toolchain have
> disappeared. I just tested with a recent (a few days) Git, and net-snmp
> built just fine with an external ARM CodeSourcery toolchain.
>
> Now, I have no idea if it actually works, since I don't know how to
> test it. But that's another story :-)
>
> Regards,
>
> Thomas
That's easy actually :)
Stick into say /tmp/snmpd.conf:
com2sec local localhost thepassword
group MyROGroup v1 local
group MyROGroup v2c local
group MyROGroup usm local
view all included .1 80
access MyROGroup "" any noauth exact all none none
access MyRWGroup "" any noauth exact all all none
syslocation Unknown
syscontact Unknown
Run "snmpd -c /tmp/snmpd.conf".
And then run "snmpwalk -v 1 -c thepassword localhost".
You'll get loads of data if snmpd is working ok.
You can define additional ACLs (com2sec+group) to enable remote access.
^ permalink raw reply
* [Buildroot] [Bug 1357] Add bluez to buildroot system
From: bugzilla at busybox.net @ 2010-10-01 10:03 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-1357-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=1357
Matthijs Benschop <m.benschop@hig.nl> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #1333|0 |1
is obsolete| |
--- Comment #3 from Matthijs Benschop <m.benschop@hig.nl> ---
Created attachment 2545
--> https://bugs.busybox.net/attachment.cgi?id=2545
Add bluez to buildroot
This is better patch, not having the i386 hardware dependency.
Tested on arm926.
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* [Buildroot] [SECURITY][PATCHv2] Bump quagga to 0.99.17
From: Peter Korsgaard @ 2010-10-01 8:31 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20100930234735.4ffdc3ea@surf>
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Thomas> On Thu, 30 Sep 2010 21:47:42 +0200
Thomas> Peter Korsgaard <jacmet@uclibc.org> wrote:
>> Could someone using the external toolchain (Thomas?) give netsnmp a
>> quick test?
Thomas> I confirm that since Gustavo converted the package to autotargets, the
Thomas> previously existing build failures with external toolchain have
Thomas> disappeared. I just tested with a recent (a few days) Git, and net-snmp
Thomas> built just fine with an external ARM CodeSourcery toolchain.
Thomas> Now, I have no idea if it actually works, since I don't know how to
Thomas> test it. But that's another story :-)
Thanks - Did you also build something using netsnmp
(E.G. BR2_PACKAGE_QUAGGA_SNMP)? The problem was afaik dependent packages
not finding netsnmp.
--
Bye, Peter Korsgaard
^ 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