Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] buildroot 2012.11 and crosstooln-ng
From: FLX @ 2012-12-14 23:24 UTC (permalink / raw)
  To: buildroot

Hello,

I have noticed a bug in 2012.11.
If you use crosstool-ng toolchain (i used eglibc) then libc is not copied
to target.
2012.08 is ok.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121215/81ef855e/attachment.html>

^ permalink raw reply

* [Buildroot] [git commit] opus-tools: bump version
From: Peter Korsgaard @ 2012-12-14 23:07 UTC (permalink / raw)
  To: buildroot

commit: http://git.buildroot.net/buildroot/commit/?id=ee094dd16f78e27d1c53094b3267fd0d3e6d54d9
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
 .../opus-tools-fix-compilation-on-non-win.patch    |   53 --------------------
 package/opus-tools/opus-tools-largefile.patch      |   37 ++++++++++++++
 package/opus-tools/opus-tools.mk                   |    2 +-
 3 files changed, 38 insertions(+), 54 deletions(-)

diff --git a/package/opus-tools/opus-tools-fix-compilation-on-non-win.patch b/package/opus-tools/opus-tools-fix-compilation-on-non-win.patch
deleted file mode 100644
index c8cb6a2..0000000
--- a/package/opus-tools/opus-tools-fix-compilation-on-non-win.patch
+++ /dev/null
@@ -1,53 +0,0 @@
-From 7734f55bc535c6d3d0fbb27c55e38f52ba6b7764 Mon Sep 17 00:00:00 2001
-From: Andreas Schlick <schlick@lavabit.com>
-Date: Thu, 13 Sep 2012 19:44:50 +0200
-Subject: [PATCH] Fix compilation on non-Windows x86-32 w/ -msse.
-
-cpusupport.h used __cpuid() from the Windows specific header file intrin.h
-which is not available under gcc. But we can use __get_cpuid() from cpuid.h
-instead.
-
-Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
-
----
- src/cpusupport.h |   18 +++++++++++++++++-
- 1 files changed, 17 insertions(+), 1 deletions(-)
-
-diff --git a/src/cpusupport.h b/src/cpusupport.h
-index 1986d31..5e42337 100644
---- a/src/cpusupport.h
-+++ b/src/cpusupport.h
-@@ -32,7 +32,9 @@
- # if !defined(__SSE__) || defined(_M_X64) || defined(__amd64__)
- #  define query_cpu_support() 0
- #else
--# include <intrin.h>
-+
-+#if defined WIN32 || defined _WIN32
-+#include <intrin.h>
- static inline int query_cpu_support(void)
- {
-    int buffer[4];
-@@ -43,5 +45,19 @@ static inline int query_cpu_support(void)
- #  endif
-        ;
- }
-+#else
-+#include <cpuid.h>
-+static inline int query_cpu_support(void)
-+{
-+   unsigned int eax, ebx, ecx, edx=0;
-+   __get_cpuid(1, &eax, &ebx, &ecx, &edx);
-+   return ((edx & 1<<25) == 0) /*SSE*/
-+#ifdef __SSE2__
-+        + ((edx & 1<<26) == 0) /*SSE2*/
-+#endif
-+       ;
-+}
-+#endif
-+
- # endif
- #endif
--- 
-1.7.2.5
-
diff --git a/package/opus-tools/opus-tools-largefile.patch b/package/opus-tools/opus-tools-largefile.patch
new file mode 100644
index 0000000..a10fcbc
--- /dev/null
+++ b/package/opus-tools/opus-tools-largefile.patch
@@ -0,0 +1,37 @@
+From f1d9376b383f4ee7ec2d7c5a1728d38cdb692df6 Mon Sep 17 00:00:00 2001
+From: Peter Korsgaard <jacmet@sunsite.dk>
+Date: Sat, 15 Dec 2012 00:05:41 +0100
+Subject: [PATCH] audio-in.c: Don't force largefile support
+
+Buildroot ensures the correct defines are enabled depending on toolchain
+configuration, so don't hard code largefile support here.
+
+Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
+---
+ src/audio-in.c |   10 ----------
+ 1 file changed, 10 deletions(-)
+
+diff --git a/src/audio-in.c b/src/audio-in.c
+index 9bf4f6f..e404629 100644
+--- a/src/audio-in.c
++++ b/src/audio-in.c
+@@ -32,16 +32,6 @@
+ # include <config.h>
+ #endif
+ 
+-#if !defined(_LARGEFILE_SOURCE)
+-# define _LARGEFILE_SOURCE
+-#endif
+-#if !defined(_LARGEFILE64_SOURCE)
+-# define _LARGEFILE64_SOURCE
+-#endif
+-#if !defined(_FILE_OFFSET_BITS)
+-# define _FILE_OFFSET_BITS 64
+-#endif
+-
+ #include <stdlib.h>
+ #include <stdio.h>
+ #include <string.h>
+-- 
+1.7.10.4
+
diff --git a/package/opus-tools/opus-tools.mk b/package/opus-tools/opus-tools.mk
index 2b649dc..7ee708f 100644
--- a/package/opus-tools/opus-tools.mk
+++ b/package/opus-tools/opus-tools.mk
@@ -4,7 +4,7 @@
 #
 #############################################################
 
-OPUS_TOOLS_VERSION = 0.1.5
+OPUS_TOOLS_VERSION = 0.1.6
 OPUS_TOOLS_SITE = http://downloads.xiph.org/releases/opus
 OPUS_TOOLS_CONF_OPT = --disable-oggtest --disable-opustest
 OPUS_TOOLS_DEPENDENCIES = opus libogg host-pkgconf

^ permalink raw reply related

* [Buildroot] [git commit] opus: bump version
From: Peter Korsgaard @ 2012-12-14 22:55 UTC (permalink / raw)
  To: buildroot

commit: http://git.buildroot.net/buildroot/commit/?id=df6e849d4ed3bfcac50cf2bd9c94fabd7545fb68
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
 package/opus/opus.mk |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/package/opus/opus.mk b/package/opus/opus.mk
index 177adfb..adaebfb 100644
--- a/package/opus/opus.mk
+++ b/package/opus/opus.mk
@@ -4,7 +4,7 @@
 #
 #############################################################
 
-OPUS_VERSION = 1.0.1
+OPUS_VERSION = 1.0.2
 OPUS_SITE = http://downloads.xiph.org/releases/opus
 OPUS_INSTALL_STAGING = YES
 OPUS_CONF_OPT = --disable-doc

^ permalink raw reply related

* [Buildroot] [PATCH 03/20] package/usbredir: new package
From: Peter Korsgaard @ 2012-12-14 21:47 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <201212142245.53802.yann.morin.1998@free.fr>

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 >> I would prefer you select libusb.

 Yann> Grudgingly done. ;-)

Thanks ;)

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* [Buildroot] [PATCH 03/20] package/usbredir: new package
From: Yann E. MORIN @ 2012-12-14 21:45 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <87ip84isg2.fsf@dell.be.48ers.dk>

Peter, All,

On Friday 14 December 2012 Peter Korsgaard wrote:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
> 
>  Yann> +comment "usbredir requires libusb"
>  Yann> +	depends on !BR2_PACKAGE_LIBUSB
>  Yann> +
>  >> 
>  >> We normally use select for libraries. Any reason to not use it here?
> 
>  Yann> libusb depends on threads, and I do not want to play the game of
>  Yann> inheriting the dependencies of my own dependencies, and reproduce
>  Yann> the libffi mess.
> 
>  Yann> libusb has a dependency I can not select, so I just depend on it.
[--SNIP--]
> I would prefer you select libusb.

Grudgingly done. ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

^ permalink raw reply

* [Buildroot] [PATCH] gettext: fix build failure with locale and uclibc
From: Peter Korsgaard @ 2012-12-14 21:24 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1355512517-24342-1-git-send-email-gustavo@zacarias.com.ar>

>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:

 Gustavo> As reported by Johan Sagaert in the mailing list, if it's
 Gustavo> building with a uClibc toolchain with locale enabled the build
 Gustavo> fails since the new gettext does a locale hack for glibc which
 Gustavo> isn't needed nor supported.

Committed, thanks.

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* [Buildroot] [git commit] gettext: fix build failure with locale and uclibc
From: Peter Korsgaard @ 2012-12-14 21:24 UTC (permalink / raw)
  To: buildroot

commit: http://git.buildroot.net/buildroot/commit/?id=7b6d368960f2e200a3ca4050d6ed1e7b481bb3f5
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

As reported by Johan Sagaert in the mailing list, if it's building with
a uClibc toolchain with locale enabled the build fails since the new
gettext does a locale hack for glibc which isn't needed nor supported.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
 package/gettext/gettext-uclibc-compat.patch |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/package/gettext/gettext-uclibc-compat.patch b/package/gettext/gettext-uclibc-compat.patch
new file mode 100644
index 0000000..5e52665
--- /dev/null
+++ b/package/gettext/gettext-uclibc-compat.patch
@@ -0,0 +1,27 @@
+The glibc fix/hack isn't valid for uClibc.
+Patch taken from OpenWRT.
+
+Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
+
+--- a/gettext-runtime/intl/localename.c
++++ b/gettext-runtime/intl/localename.c
+@@ -2607,7 +2607,7 @@ gl_locale_name_thread_unsafe (int catego
+     locale_t thread_locale = uselocale (NULL);
+     if (thread_locale != LC_GLOBAL_LOCALE)
+       {
+-#  if __GLIBC__ >= 2
++#  if __GLIBC__ >= 2 && !defined __UCLIBC__
+         /* Work around an incorrect definition of the _NL_LOCALE_NAME macro in
+            glibc < 2.12.
+            See <http://sourceware.org/bugzilla/show_bug.cgi?id=10968>.  */
+--- a/gettext-tools/gnulib-lib/localename.c
++++ b/gettext-tools/gnulib-lib/localename.c
+@@ -2607,7 +2607,7 @@ gl_locale_name_thread_unsafe (int catego
+     locale_t thread_locale = uselocale (NULL);
+     if (thread_locale != LC_GLOBAL_LOCALE)
+       {
+-#  if __GLIBC__ >= 2
++#  if __GLIBC__ >= 2 && !defined __UCLIBC__
+         /* Work around an incorrect definition of the _NL_LOCALE_NAME macro in
+            glibc < 2.12.
+            See <http://sourceware.org/bugzilla/show_bug.cgi?id=10968>.  */

^ permalink raw reply related

* [Buildroot] [PATCH 01/20] package/vde2: new package
From: Yann E. MORIN @ 2012-12-14 21:12 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <87vcc4j0h7.fsf@dell.be.48ers.dk>

Peter, All,

On Friday 14 December 2012 Peter Korsgaard wrote:
>  Yann> diff --git a/package/vde2/Config.in b/package/vde2/Config.in
>  Yann> new file mode 100644
>  Yann> index 0000000..f344d67
>  Yann> --- /dev/null
>  Yann> +++ b/package/vde2/Config.in
>  Yann> @@ -0,0 +1,10 @@
>  Yann> +config BR2_PACKAGE_VDE2
>  Yann> +	bool "vde2"
>  Yann> +	help
>  Yann> +	  VDE is an ethernet compliant virtual network that can be
>  Yann> +	  spawned over a set of physical computers over the Internet.
>  Yann> +	  VDE is part of the virtualsquare project.
>  Yann> +	  
>  Yann> +	  http://vde.sourceforge.net/
>  Yann> +	  
>  Yann> +	  Note: only the libraries are installed.
> 
> Wouldn't it then make more sense to put it under Libraries ->
> Networking?

Nope, we also install the executable to drive the VDE switches. I'll remove
that sentenc from the help text, and leave vde2 in "Network Applications".

> A quick test build seems to show that it needs C++ support:
> 
> checking whether the C++ compiler works... no
> configure: error: in `/home/peko/source/buildroot/vdetest/build/vde2-2.3.2':
> configure: error: C++ compiler cannot create executables
> See `config.log' for more details
> 
> I don't see any C++ source files though, so it's probably better to drop
> AC_PROG_CXX from configure.ac

Yup, fixed.

Thank you!

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

^ permalink raw reply

* [Buildroot] [PATCH] gettext: bump to version 0.18.1.1
From: Stefan Fröberg @ 2012-12-14 21:05 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <50CB93AD.20303@petroprogram.com>

Oh sorry, it seems that Gustavo was faster than I providing patch for this
 :)


14.12.2012 23:01, Stefan Fr?berg kirjoitti:
> Hello Johan
>
> 14.12.2012 20:08, Sagaert Johan kirjoitti:
>> Hi
>>
>> After pulling the latest commits : 
>>
>> libtool: compile:  /home/buildroot12git/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -c
>> -DLOCALEDIR=\"/usr/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/share/locale\" -DLIBDIR=\"/usr/lib\" -DBUILDING_LIBINTL -DBUILDING_DLL
>> -DIN_LIBINTL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/lib\" -DNO_XMALLOC
>> -Dset_relocation_prefix=libintl_set_relocation_prefix -Drelocate=libintl_relocate -DDEPENDS_ON_LIBICONV=1 -DHAVE_CONFIG_H -I. -I.
>> -I.. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
>> -D_FILE_OFFSET_BITS=64 -pipe -Os -fvisibility=hidden ./printf.c -o printf.o >/dev/null 2>&1
>> ./localename.c: In function '_nl_locale_name_thread_unsafe':
>> ./localename.c:2619:31: error: dereferencing pointer to incomplete type
>> make[4]: *** [localename.lo] Error 1
>> make[4]: *** Waiting for unfinished jobs....
>>
>> Using uClibc 0.9.33.1 (NTPL)
>>
>> Regards , Johan
>>  
> Hmmm...
> That sounds familiar. If I remember correctly I hit exactly into same
> problem in my own Linux distro
> some time ago.
>
> Could you please try the following lil patch ?
> (I will include it as an separete attachment here also)
>
> diff --git a/gettext-runtime/intl/localename.c
> b/gettext-runtime/intl/localename.c
> index 89a9692..5e86bc4 100644
> --- a/gettext-runtime/intl/localename.c
> +++ b/gettext-runtime/intl/localename.c
> @@ -2607,7 +2607,7 @@ gl_locale_name_thread_unsafe (int category, const
> char *categoryname)
>      locale_t thread_locale = uselocale (NULL);
>      if (thread_locale != LC_GLOBAL_LOCALE)
>        {
> -#  if __GLIBC__ >= 2
> +#  if __GLIBC__ >= 2 && !defined __UCLIBC__
>          /* Work around an incorrect definition of the _NL_LOCALE_NAME
> macro in
>             glibc < 2.12.
>             See <http://sourceware.org/bugzilla/show_bug.cgi?id=10968>.  */
> diff --git a/gettext-tools/gnulib-lib/localename.c
> b/gettext-tools/gnulib-lib/localename.c
> index dab5e5b..85149ac 100644
> --- a/gettext-tools/gnulib-lib/localename.c
> +++ b/gettext-tools/gnulib-lib/localename.c
> @@ -2607,7 +2607,7 @@ gl_locale_name_thread_unsafe (int category, const
> char *categoryname)
>      locale_t thread_locale = uselocale (NULL);
>      if (thread_locale != LC_GLOBAL_LOCALE)
>        {
> -#  if __GLIBC__ >= 2
> +#  if __GLIBC__ >= 2 && !defined __UCLIBC__
>          /* Work around an incorrect definition of the _NL_LOCALE_NAME
> macro in
>             glibc < 2.12.
>             See <http://sourceware.org/bugzilla/show_bug.cgi?id=10968>.  */
>
> Regards
> Stefan
>
>
>> -----Oorspronkelijk bericht-----
>> Van: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] Namens Peter Korsgaard
>> Verzonden: vrijdag 14 december 2012 12:03
>> Aan: Gustavo Zacarias
>> CC: buildroot at busybox.net
>> Onderwerp: Re: [Buildroot] [PATCH] gettext: bump to version 0.18.1.1
>>
>>>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:
>>  Gustavo> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
>>
>> Committed, thanks.
>>
>> --
>> Bye, Peter Korsgaard
>> _______________________________________________
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121214/16325071/attachment.html>

^ permalink raw reply

* [Buildroot] [PATCH] gettext: bump to version 0.18.1.1
From: Stefan Fröberg @ 2012-12-14 21:01 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <A30A1B4688B14FF0A9174D8D473754CD@JohanW7>

Hello Johan

14.12.2012 20:08, Sagaert Johan kirjoitti:
> Hi
>
> After pulling the latest commits : 
>
> libtool: compile:  /home/buildroot12git/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -c
> -DLOCALEDIR=\"/usr/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/share/locale\" -DLIBDIR=\"/usr/lib\" -DBUILDING_LIBINTL -DBUILDING_DLL
> -DIN_LIBINTL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/lib\" -DNO_XMALLOC
> -Dset_relocation_prefix=libintl_set_relocation_prefix -Drelocate=libintl_relocate -DDEPENDS_ON_LIBICONV=1 -DHAVE_CONFIG_H -I. -I.
> -I.. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64 -pipe -Os -fvisibility=hidden ./printf.c -o printf.o >/dev/null 2>&1
> ./localename.c: In function '_nl_locale_name_thread_unsafe':
> ./localename.c:2619:31: error: dereferencing pointer to incomplete type
> make[4]: *** [localename.lo] Error 1
> make[4]: *** Waiting for unfinished jobs....
>
> Using uClibc 0.9.33.1 (NTPL)
>
> Regards , Johan
>  
Hmmm...
That sounds familiar. If I remember correctly I hit exactly into same
problem in my own Linux distro
some time ago.

Could you please try the following lil patch ?
(I will include it as an separete attachment here also)

diff --git a/gettext-runtime/intl/localename.c
b/gettext-runtime/intl/localename.c
index 89a9692..5e86bc4 100644
--- a/gettext-runtime/intl/localename.c
+++ b/gettext-runtime/intl/localename.c
@@ -2607,7 +2607,7 @@ gl_locale_name_thread_unsafe (int category, const
char *categoryname)
     locale_t thread_locale = uselocale (NULL);
     if (thread_locale != LC_GLOBAL_LOCALE)
       {
-#  if __GLIBC__ >= 2
+#  if __GLIBC__ >= 2 && !defined __UCLIBC__
         /* Work around an incorrect definition of the _NL_LOCALE_NAME
macro in
            glibc < 2.12.
            See <http://sourceware.org/bugzilla/show_bug.cgi?id=10968>.  */
diff --git a/gettext-tools/gnulib-lib/localename.c
b/gettext-tools/gnulib-lib/localename.c
index dab5e5b..85149ac 100644
--- a/gettext-tools/gnulib-lib/localename.c
+++ b/gettext-tools/gnulib-lib/localename.c
@@ -2607,7 +2607,7 @@ gl_locale_name_thread_unsafe (int category, const
char *categoryname)
     locale_t thread_locale = uselocale (NULL);
     if (thread_locale != LC_GLOBAL_LOCALE)
       {
-#  if __GLIBC__ >= 2
+#  if __GLIBC__ >= 2 && !defined __UCLIBC__
         /* Work around an incorrect definition of the _NL_LOCALE_NAME
macro in
            glibc < 2.12.
            See <http://sourceware.org/bugzilla/show_bug.cgi?id=10968>.  */

Regards
Stefan


>
> -----Oorspronkelijk bericht-----
> Van: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] Namens Peter Korsgaard
> Verzonden: vrijdag 14 december 2012 12:03
> Aan: Gustavo Zacarias
> CC: buildroot at busybox.net
> Onderwerp: Re: [Buildroot] [PATCH] gettext: bump to version 0.18.1.1
>
>>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:
>  Gustavo> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
>
> Committed, thanks.
>
> --
> Bye, Peter Korsgaard
> _______________________________________________
> 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 --------------
diff --git a/gettext-runtime/intl/localename.c b/gettext-runtime/intl/localename.c
index 89a9692..5e86bc4 100644
--- a/gettext-runtime/intl/localename.c
+++ b/gettext-runtime/intl/localename.c
@@ -2607,7 +2607,7 @@ gl_locale_name_thread_unsafe (int category, const char *categoryname)
     locale_t thread_locale = uselocale (NULL);
     if (thread_locale != LC_GLOBAL_LOCALE)
       {
-#  if __GLIBC__ >= 2
+#  if __GLIBC__ >= 2 && !defined __UCLIBC__
         /* Work around an incorrect definition of the _NL_LOCALE_NAME macro in
            glibc < 2.12.
            See <http://sourceware.org/bugzilla/show_bug.cgi?id=10968>.  */
diff --git a/gettext-tools/gnulib-lib/localename.c b/gettext-tools/gnulib-lib/localename.c
index dab5e5b..85149ac 100644
--- a/gettext-tools/gnulib-lib/localename.c
+++ b/gettext-tools/gnulib-lib/localename.c
@@ -2607,7 +2607,7 @@ gl_locale_name_thread_unsafe (int category, const char *categoryname)
     locale_t thread_locale = uselocale (NULL);
     if (thread_locale != LC_GLOBAL_LOCALE)
       {
-#  if __GLIBC__ >= 2
+#  if __GLIBC__ >= 2 && !defined __UCLIBC__
         /* Work around an incorrect definition of the _NL_LOCALE_NAME macro in
            glibc < 2.12.
            See <http://sourceware.org/bugzilla/show_bug.cgi?id=10968>.  */

^ permalink raw reply related

* [Buildroot] [PATCH] gettext: bump to version 0.18.1.1
From: Gustavo Zacarias @ 2012-12-14 19:16 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <E47E6E48A97345C3A1DB1002FEE1CBB6@JohanW7>

On 12/14/2012 03:27 PM, Sagaert Johan wrote:

>  Hi
> 
> Oops it is uClibc 0.9.33.2 that I use.
> Here my buildroot .config and my uClibc config file:

Hi.
Patch sent to the list, thanks for the headsup!
Regards.

^ permalink raw reply

* [Buildroot] [PATCH] gettext: fix build failure with locale and uclibc
From: Gustavo Zacarias @ 2012-12-14 19:15 UTC (permalink / raw)
  To: buildroot

As reported by Johan Sagaert in the mailing list, if it's building with
a uClibc toolchain with locale enabled the build fails since the new
gettext does a locale hack for glibc which isn't needed nor supported.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/gettext/gettext-uclibc-compat.patch |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)
 create mode 100644 package/gettext/gettext-uclibc-compat.patch

diff --git a/package/gettext/gettext-uclibc-compat.patch b/package/gettext/gettext-uclibc-compat.patch
new file mode 100644
index 0000000..5e52665
--- /dev/null
+++ b/package/gettext/gettext-uclibc-compat.patch
@@ -0,0 +1,27 @@
+The glibc fix/hack isn't valid for uClibc.
+Patch taken from OpenWRT.
+
+Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
+
+--- a/gettext-runtime/intl/localename.c
++++ b/gettext-runtime/intl/localename.c
+@@ -2607,7 +2607,7 @@ gl_locale_name_thread_unsafe (int catego
+     locale_t thread_locale = uselocale (NULL);
+     if (thread_locale != LC_GLOBAL_LOCALE)
+       {
+-#  if __GLIBC__ >= 2
++#  if __GLIBC__ >= 2 && !defined __UCLIBC__
+         /* Work around an incorrect definition of the _NL_LOCALE_NAME macro in
+            glibc < 2.12.
+            See <http://sourceware.org/bugzilla/show_bug.cgi?id=10968>.  */
+--- a/gettext-tools/gnulib-lib/localename.c
++++ b/gettext-tools/gnulib-lib/localename.c
+@@ -2607,7 +2607,7 @@ gl_locale_name_thread_unsafe (int catego
+     locale_t thread_locale = uselocale (NULL);
+     if (thread_locale != LC_GLOBAL_LOCALE)
+       {
+-#  if __GLIBC__ >= 2
++#  if __GLIBC__ >= 2 && !defined __UCLIBC__
+         /* Work around an incorrect definition of the _NL_LOCALE_NAME macro in
+            glibc < 2.12.
+            See <http://sourceware.org/bugzilla/show_bug.cgi?id=10968>.  */
-- 
1.7.8.6

^ permalink raw reply related

* [Buildroot] [PATCH 4/4] package/qemu: bump version
From: Yann E. MORIN @ 2012-12-14 18:28 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <CAB0FRsv7=iuBTxoeUe_7a5Zh_zCRovj9JZ_k_Qku-xmMGgOUeQ@mail.gmail.com>

Fran?ois, All,

On Friday 14 December 2012 Fran?ois Perrad wrote:
> 2012/12/13 Yann E. MORIN <yann.morin.1998@free.fr>:
> > Bump QEMU to 1.2.1.
> >
> > Note: 1.3.0 is out now, but ./configure has changed a bit, and there are
> > new dependencies, so the bump to 1.3.0 is postponed for a litle while...
> >
> 
> a version 1.2.2 is also available.

Ah, 1.2.2 has just been released two days ago, indeed.
Thanks for the heads up.

> with version 1.3.0, host-qemu depends on host-pixman.

Yep, upgrading to 1.3.0 is on my todo-list, as it adds a few bits I'm
interested in.

Upgrading to 1.3.0 now would make it more complex to review the whole
series, and it is not even easy right now.

So, that will have to wait for after the current series has been upstreamed.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

^ permalink raw reply

* [Buildroot] [PATCH] gettext: bump to version 0.18.1.1
From: Gustavo Zacarias @ 2012-12-14 18:12 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <A30A1B4688B14FF0A9174D8D473754CD@JohanW7>

On 12/14/2012 03:08 PM, Sagaert Johan wrote:

> Hi
> 
> After pulling the latest commits : 
> 
> libtool: compile:  /home/buildroot12git/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -c
> -DLOCALEDIR=\"/usr/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/share/locale\" -DLIBDIR=\"/usr/lib\" -DBUILDING_LIBINTL -DBUILDING_DLL
> -DIN_LIBINTL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/lib\" -DNO_XMALLOC
> -Dset_relocation_prefix=libintl_set_relocation_prefix -Drelocate=libintl_relocate -DDEPENDS_ON_LIBICONV=1 -DHAVE_CONFIG_H -I. -I.
> -I.. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64 -pipe -Os -fvisibility=hidden ./printf.c -o printf.o >/dev/null 2>&1
> ./localename.c: In function '_nl_locale_name_thread_unsafe':
> ./localename.c:2619:31: error: dereferencing pointer to incomplete type
> make[4]: *** [localename.lo] Error 1
> make[4]: *** Waiting for unfinished jobs....
> 
> Using uClibc 0.9.33.1 (NTPL)
> 
> Regards , Johan

.config please
And 0.9.33.1? That's not current.
Regards.

^ permalink raw reply

* [Buildroot] [PATCH] gettext: bump to version 0.18.1.1
From: Sagaert Johan @ 2012-12-14 18:08 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <871ueskiar.fsf@dell.be.48ers.dk>

Hi

After pulling the latest commits : 

libtool: compile:  /home/buildroot12git/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -c
-DLOCALEDIR=\"/usr/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/share/locale\" -DLIBDIR=\"/usr/lib\" -DBUILDING_LIBINTL -DBUILDING_DLL
-DIN_LIBINTL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/lib\" -DNO_XMALLOC
-Dset_relocation_prefix=libintl_set_relocation_prefix -Drelocate=libintl_relocate -DDEPENDS_ON_LIBICONV=1 -DHAVE_CONFIG_H -I. -I.
-I.. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -pipe -Os -fvisibility=hidden ./printf.c -o printf.o >/dev/null 2>&1
./localename.c: In function '_nl_locale_name_thread_unsafe':
./localename.c:2619:31: error: dereferencing pointer to incomplete type
make[4]: *** [localename.lo] Error 1
make[4]: *** Waiting for unfinished jobs....

Using uClibc 0.9.33.1 (NTPL)

Regards , Johan
 

-----Oorspronkelijk bericht-----
Van: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] Namens Peter Korsgaard
Verzonden: vrijdag 14 december 2012 12:03
Aan: Gustavo Zacarias
CC: buildroot at busybox.net
Onderwerp: Re: [Buildroot] [PATCH] gettext: bump to version 0.18.1.1

>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:

 Gustavo> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>

Committed, thanks.

--
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

^ permalink raw reply

* [Buildroot] [PATCH 4/4] package/qemu: bump version
From: François Perrad @ 2012-12-14 15:40 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <b868ae7c3562ef5dd3b7027f28dc7f0ebba3b440.1355434710.git.yann.morin.1998@free.fr>

2012/12/13 Yann E. MORIN <yann.morin.1998@free.fr>:
> Bump QEMU to 1.2.1.
>
> Note: 1.3.0 is out now, but ./configure has changed a bit, and there are
> new dependencies, so the bump to 1.3.0 is postponed for a litle while...
>

a version 1.2.2 is also available.
with version 1.3.0, host-qemu depends on host-pixman.

Fran?ois

> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Francois Perrad <fperrad@gmail.com>
> ---
>  package/qemu/qemu.mk |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/package/qemu/qemu.mk b/package/qemu/qemu.mk
> index 91d0eb8..241a392 100644
> --- a/package/qemu/qemu.mk
> +++ b/package/qemu/qemu.mk
> @@ -4,7 +4,7 @@
>  #
>  #############################################################
>
> -QEMU_VERSION = 1.2.0
> +QEMU_VERSION = 1.2.1
>  QEMU_SOURCE = qemu-$(QEMU_VERSION).tar.bz2
>  QEMU_SITE = http://wiki.qemu.org/download
>  QEMU_LICENSE = GPLv2 LGPLv2.1 MIT BSD-3c BSD-2c Others/BSD-1c
> --
> 1.7.2.5
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

^ permalink raw reply

* [Buildroot] [PATCH] qemu: bump to version 1.3.0
From: Francois Perrad @ 2012-12-14 15:40 UTC (permalink / raw)
  To: buildroot

Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
---
 package/qemu/qemu.mk |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/qemu/qemu.mk b/package/qemu/qemu.mk
index 8d07807..7d1d252 100644
--- a/package/qemu/qemu.mk
+++ b/package/qemu/qemu.mk
@@ -4,7 +4,7 @@
 #
 #############################################################
 
-QEMU_VERSION = 1.2.1
+QEMU_VERSION = 1.3.0
 QEMU_SOURCE = qemu-$(QEMU_VERSION).tar.bz2
 QEMU_SITE = http://wiki.qemu.org/download
 QEMU_LICENSE = GPLv2 LGPLv2.1 MIT BSD-3c BSD-2c Others/BSD-1c
@@ -16,7 +16,7 @@ QEMU_LICENSE_FILES = COPYING COPYING.LIB
 #-------------------------------------------------------------
 # Host-qemu
 
-HOST_QEMU_DEPENDENCIES = host-pkgconf host-zlib host-libglib2
+HOST_QEMU_DEPENDENCIES = host-pkgconf host-zlib host-libglib2 host-pixman
 
 #       BR ARCH         qemu
 #       -------         ----
-- 
1.7.9.5

^ permalink raw reply related

* [Buildroot] [PATCH 03/20] package/usbredir: new package
From: Peter Korsgaard @ 2012-12-14 15:06 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <201212141401.11951.yann.morin.1998@free.fr>

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 Yann> +comment "usbredir requires libusb"
 Yann> +	depends on !BR2_PACKAGE_LIBUSB
 Yann> +
 >> 
 >> We normally use select for libraries. Any reason to not use it here?

 Yann> libusb depends on threads, and I do not want to play the game of
 Yann> inheriting the dependencies of my own dependencies, and reproduce
 Yann> the libffi mess.

 Yann> libusb has a dependency I can not select, so I just depend on it.

Ok, but that just moves the trouble higher up the stack. E.G. you want
to enable qemu, but it tells you that it needs usbredir so you go
hunting around for it only to discover that it needs libusb and finally
you see that you need threads support in your toolchain.

In other words, selects are more user friendly than depends
on. Most likely we have more users than developers, so we should
optimize for making things nice for users rather than devs.

I would prefer you select libusb.

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* [Buildroot] [PATCH] oprofile: bump to version 0.9.8
From: Jérémy Rosen @ 2012-12-14 14:24 UTC (permalink / raw)
  To: buildroot

Signed-off-by: J?r?my Rosen <jeremy.rosen@openwide.fr>
---
 package/oprofile/oprofile.mk |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/package/oprofile/oprofile.mk b/package/oprofile/oprofile.mk
index 75f8407..f3ea23f 100644
--- a/package/oprofile/oprofile.mk
+++ b/package/oprofile/oprofile.mk
@@ -4,13 +4,14 @@
 #
 #############################################################
 
-OPROFILE_VERSION = 0.9.7
+OPROFILE_VERSION = 0.9.8
 OPROFILE_SITE = http://downloads.sourceforge.net/project/oprofile/oprofile/oprofile-$(OPROFILE_VERSION)
 OPROFILE_LICENSE = GPLv2+
 OPROFILE_LICENSE_FILES = COPYING
 OPROFILE_CONF_OPT = --localstatedir=/var --with-kernel-support
 OPROFILE_BINARIES = utils/ophelp pp/opannotate pp/oparchive pp/opgprof
 OPROFILE_BINARIES += pp/opreport opjitconv/opjitconv daemon/oprofiled
+OPROFILE_BINARIES += utils/op-check-perfevents pe_profiling/operf libabi/opimport
 
 ifeq ($(BR2_i386),y)
 OPROFILE_ARCH = i386
@@ -33,6 +34,7 @@ OPROFILE_DEPENDENCIES = popt binutils
 define OPROFILE_INSTALL_TARGET_CMDS
 	$(INSTALL) -d -m 755 $(TARGET_DIR)/usr/bin
 	$(INSTALL) -d -m 755 $(TARGET_DIR)/usr/share/oprofile
+	$(INSTALL) -d -m 755 $(TARGET_DIR)/usr/lib/oprofile
 	if [ -d $(@D)/events/$(OPROFILE_ARCH) ]; then \
 		cp -dpfr $(@D)/events/$(OPROFILE_ARCH) \
 			$(TARGET_DIR)/usr/share/oprofile; \
@@ -40,12 +42,14 @@ define OPROFILE_INSTALL_TARGET_CMDS
 	$(INSTALL) -m 644 $(@D)/libregex/stl.pat $(TARGET_DIR)/usr/share/oprofile
 	$(INSTALL) -m 755 $(@D)/utils/opcontrol $(TARGET_DIR)/usr/bin
 	$(INSTALL) -m 755 $(addprefix $(@D)/, $(OPROFILE_BINARIES)) $(TARGET_DIR)/usr/bin
+	$(INSTALL) -m 755 $(@D)/libopagent/.libs/*.so* $(TARGET_DIR)/usr/lib/oprofile
 endef
 
 define OPROFILE_UNINSTALL_TARGET_CMDS
 	rm -f $(addprefix $(TARGET_DIR)/usr/bin/, $(notdir $(OPROFILE_BINARIES)))
 	rm -f $(TARGET_DIR)/usr/bin/opcontrol
 	rm -rf $(TARGET_DIR)/usr/share/oprofile
+	rm -rf $(TARGET_DIR)/usr/lib/oprofile
 endef
 
 $(eval $(autotools-package))
-- 
1.7.10.4

^ permalink raw reply related

* [Buildroot] [PATCH] pkg-infra: limit -reconfigure and -rebuild actions
From: Arnout Vandecappelle @ 2012-12-14 13:49 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <CA+wH294311rh_e5HP8itswfG149Or1bOoKQ_GzAymRhVPRW9eA@mail.gmail.com>

On 22/07/12 20:27, Alex Bradbury wrote:
> On 21 July 2012 17:14, Samuel Martin<s.martin49@gmail.com>  wrote:
>> Hi all,
>>
>> Here, I'll try to sum up what we talked few days ago on the IRC
>> channel, plus give my opinion about this.
>>
>> To be honest, the first time i tried these -reconfigure and -rebuild
>> targets, I was surprised they didn't behave as I would expect from
>> targets named like that, rebuilding not only the package but the
>> images too. So, I keep doing things by hands... though I understand
>> why things were implemented like this.
>
> I'm a newcomer to buildroot and was surprised by the effect of
> -reconfigure and -rebuild. I'd read about them in the slides from one
> of Tom's talks, and given their description I had assumed they would
> rebuild only the package. Reading the responses here, I can see why it
> is useful to have a target that rebuilds a single package and also
> makes the image (though really, it seems not that hard for the user to
> do another make command to build the image in that case). I would love
> to see a build target with the proposed semantics.

  A colleague of mine (again) made this remark to me today... So, will we
accept this change or not?

  Clearly it changes the behaviour, but I don't expect people will use
-rebuild or -reconfigure in scripts so it shouldn't hurt.


  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

^ permalink raw reply

* [Buildroot] [PATCH 03/20] package/usbredir: new package
From: Yann E. MORIN @ 2012-12-14 13:01 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <87mwxgiylq.fsf@dell.be.48ers.dk>

Peter, All,

On Friday 14 December 2012 13:53:37 Peter Korsgaard wrote:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
>  Yann> diff --git a/package/usbredir/Config.in b/package/usbredir/Config.in
>  Yann> new file mode 100644
>  Yann> index 0000000..8d8ac5a
>  Yann> --- /dev/null
>  Yann> +++ b/package/usbredir/Config.in
>  Yann> @@ -0,0 +1,28 @@
>  Yann> +comment "usbredir requires libusb"
>  Yann> +	depends on !BR2_PACKAGE_LIBUSB
>  Yann> +
> 
> We normally use select for libraries. Any reason to not use it here?

libusb depends on threads, and I do not want to play the game of
inheriting the dependencies of my own dependencies, and reproduce
the libffi mess.

libusb has a dependency I can not select, so I just depend on it.

>  Yann> +USBREDIR_DEPENDENCIES    += host-pkgconf
> 
> Any particular reason to not merge this line with the one above?

Probably no good reason, indeed.

Regards,
Yann E. MORIN.


-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
'------------------------------'-------'------------------'--------------------'

^ permalink raw reply

* [Buildroot] [PATCH 03/20] package/usbredir: new package
From: Peter Korsgaard @ 2012-12-14 12:53 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <b6f27b8d9306f0a01bd003e2c9bdc1f5c5e87128.1355435224.git.yann.morin.1998@free.fr>

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 Yann> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
 Yann> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
 Yann> Cc: Arnout Vandecappelle <arnout@mind.be>
 Yann> ---
 Yann>  package/Config.in            |    1 +
 Yann>  package/usbredir/Config.in   |   28 ++++++++++++++++++++++++++++
 Yann>  package/usbredir/usbredir.mk |   31 +++++++++++++++++++++++++++++++
 Yann>  3 files changed, 60 insertions(+), 0 deletions(-)
 Yann>  create mode 100644 package/usbredir/Config.in
 Yann>  create mode 100644 package/usbredir/usbredir.mk

 Yann> diff --git a/package/Config.in b/package/Config.in
 Yann> index 8edadf9..9d68581 100644
 Yann> --- a/package/Config.in
 Yann> +++ b/package/Config.in
 Yann> @@ -492,6 +492,7 @@ source "package/libupnp/Config.in"
 Yann>  source "package/libvncserver/Config.in"
 Yann>  source "package/nss-mdns/Config.in"
 Yann>  source "package/ortp/Config.in"
 Yann> +source "package/usbredir/Config.in"
 Yann>  source "package/zeromq/Config.in"
 Yann>  endmenu
 
 Yann> diff --git a/package/usbredir/Config.in b/package/usbredir/Config.in
 Yann> new file mode 100644
 Yann> index 0000000..8d8ac5a
 Yann> --- /dev/null
 Yann> +++ b/package/usbredir/Config.in
 Yann> @@ -0,0 +1,28 @@
 Yann> +comment "usbredir requires libusb"
 Yann> +	depends on !BR2_PACKAGE_LIBUSB
 Yann> +

We normally use select for libraries. Any reason to not use it here?

 Yann> +USBREDIR_VERSION         = 0.4.3
 Yann> +USBREDIR_SOURCE          = usbredir-$(USBREDIR_VERSION).tar.bz2
 Yann> +USBREDIR_SITE            = http://spice-space.org/download/usbredir
 Yann> +USBREDIR_LICENSE         = LGPLv2.1+
 Yann> +USBREDIR_LICENSE_FILES   = COPYING.LIB
 Yann> +USBREDIR_INSTALL_STAGING = YES
 Yann> +USBREDIR_DEPENDENCIES    = libusb
 Yann> +
 Yann> +USBREDIR_DEPENDENCIES    += host-pkgconf

Any particular reason to not merge this line with the one above?

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* [Buildroot] [PATCH 02/20] package/libiscsi: new package
From: Peter Korsgaard @ 2012-12-14 12:51 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <270885b540b0b51edc0b6bcd2b11264f44f35d05.1355435224.git.yann.morin.1998@free.fr>

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 Yann> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
 Yann> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Committed, thanks.

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* [Buildroot] [git commit] package/libiscsi: new package
From: Peter Korsgaard @ 2012-12-14 12:48 UTC (permalink / raw)
  To: buildroot

commit: http://git.buildroot.net/buildroot/commit/?id=599b97203012dbdc4a6663be717d6f1162ff26d9
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
 package/Config.in            |    1 +
 package/libiscsi/Config.in   |   12 ++++++++++++
 package/libiscsi/libiscsi.mk |   15 +++++++++++++++
 3 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/package/Config.in b/package/Config.in
index cad1221..dbb6704 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -466,6 +466,7 @@ source "package/libesmtp/Config.in"
 source "package/libeXosip2/Config.in"
 source "package/libfcgi/Config.in"
 source "package/libidn/Config.in"
+source "package/libiscsi/Config.in"
 source "package/liboauth/Config.in"
 source "package/libmicrohttpd/Config.in"
 source "package/neon/Config.in"
diff --git a/package/libiscsi/Config.in b/package/libiscsi/Config.in
new file mode 100644
index 0000000..f3fc29e
--- /dev/null
+++ b/package/libiscsi/Config.in
@@ -0,0 +1,12 @@
+config BR2_PACKAGE_LIBISCSI
+	bool "libiscsi"
+	select BR2_PACKAGE_POPT
+	help
+	  Libiscsi is a client-side library to implement the iSCSI protocol
+	  that can be used to access resource of an iSCSI Target.
+	  
+	  The library is fully async with regards to iscsi commands and scsi
+	  tasks, but a sync layer is also provided for ease of use for simpler
+	  applications.
+	  
+	  https://github.com/sahlberg/libiscsi  (no proper homepage)
diff --git a/package/libiscsi/libiscsi.mk b/package/libiscsi/libiscsi.mk
new file mode 100644
index 0000000..bfebd7e
--- /dev/null
+++ b/package/libiscsi/libiscsi.mk
@@ -0,0 +1,15 @@
+#############################################################
+#
+# libiscsi
+#
+#############################################################
+
+LIBISCSI_VERSION         = 1.6.0
+LIBISCSI_SOURCE          = libiscsi-$(LIBISCSI_VERSION).tar.gz
+LIBISCSI_SITE            = https://github.com/downloads/sahlberg/libiscsi
+LIBISCSI_LICENSE         = GPLv2+ LGPLv2.1+
+LIBISCSI_LICENSE_FILES   = COPYING LICENCE-GPL-2.txt LICENCE-LGPL-2.1.txt
+LIBISCSI_INSTALL_STAGING = YES
+LIBISCSI_DEPENDENCIES    = popt
+
+$(eval $(autotools-package))

^ permalink raw reply related

* [Buildroot] [PATCH 01/20] package/vde2: new package
From: Peter Korsgaard @ 2012-12-14 12:13 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1f7225d5ca0a09c835187bbfea4eb4ce1b6eb121.1355435224.git.yann.morin.1998@free.fr>

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 Yann> VDE is an ethernet compliant virtual network that can be
 Yann> spawned over a set of physical computer over the Internet.

 Yann> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
 Yann> Cc: Arnout Vandecappelle <arnout@mind.be>
 Yann> ---
 Yann>  package/Config.in      |    1 +
 Yann>  package/vde2/Config.in |   10 ++++++++++
 Yann>  package/vde2/vde2.mk   |   36 ++++++++++++++++++++++++++++++++++++
 Yann>  3 files changed, 47 insertions(+), 0 deletions(-)
 Yann>  create mode 100644 package/vde2/Config.in
 Yann>  create mode 100644 package/vde2/vde2.mk

 Yann> diff --git a/package/Config.in b/package/Config.in
 Yann> index cad1221..2345b4b 100644
 Yann> --- a/package/Config.in
 Yann> +++ b/package/Config.in
 Yann> @@ -672,6 +672,7 @@ source "package/ttcp/Config.in"
 Yann>  source "package/udpcast/Config.in"
 Yann>  source "package/ulogd/Config.in"
 Yann>  source "package/ushare/Config.in"
 Yann> +source "package/vde2/Config.in"
 Yann>  source "package/vpnc/Config.in"
 Yann>  source "package/vsftpd/Config.in"
 Yann>  source "package/vtun/Config.in"
 Yann> diff --git a/package/vde2/Config.in b/package/vde2/Config.in
 Yann> new file mode 100644
 Yann> index 0000000..f344d67
 Yann> --- /dev/null
 Yann> +++ b/package/vde2/Config.in
 Yann> @@ -0,0 +1,10 @@
 Yann> +config BR2_PACKAGE_VDE2
 Yann> +	bool "vde2"
 Yann> +	help
 Yann> +	  VDE is an ethernet compliant virtual network that can be
 Yann> +	  spawned over a set of physical computers over the Internet.
 Yann> +	  VDE is part of the virtualsquare project.
 Yann> +	  
 Yann> +	  http://vde.sourceforge.net/
 Yann> +	  
 Yann> +	  Note: only the libraries are installed.

Wouldn't it then make more sense to put it under Libraries ->
Networking?

A quick test build seems to show that it needs C++ support:

checking whether the C++ compiler works... no
configure: error: in `/home/peko/source/buildroot/vdetest/build/vde2-2.3.2':
configure: error: C++ compiler cannot create executables
See `config.log' for more details

I don't see any C++ source files though, so it's probably better to drop
AC_PROG_CXX from configure.ac

-- 
Bye, Peter Korsgaard

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox