http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60089 <pre>Understood. Thanks a lot! On 23 May 2013 01:37, Yann E. MORIN &lt;yann.morin.1998-GANU6spQydw&lt; at &gt;public.gmane.org&gt; wrote: </pre> Woody Wu 2013-05-23T03:19:14 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60088 <pre>Fixes: http://autobuild.buildroot.net/results/58c188ad59c62c7897381e110fe3518ccc17867e Signed-off-by: Gilles Talis &lt;gilles.talis-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; --- .../libatomic_ops-nothread-build-failure-fix.patch | 41 ++++++++++++++++++++ 1 files changed, 41 insertions(+), 0 deletions(-) create mode 100644 package/libatomic_ops/libatomic_ops-nothread-build-failure-fix.patch diff --git a/package/libatomic_ops/libatomic_ops-nothread-build-failure-fix.patch b/package/libatomic_ops/libatomic_ops-nothread-build-failure-fix.patch new file mode 100644 index 0000000..cc14b1e --- /dev/null +++ b/package/libatomic_ops/libatomic_ops-nothread-build-failure-fix.patch &lt; at &gt;&lt; at &gt; -0,0 +1,41 &lt; at &gt;&lt; at &gt; +From 7e940ce34ff4de254d460344f1a1a486a14fb045 Mon Sep 17 00:00:00 2001 +From: Gilles Talis &lt;gilles.talis-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; +Date: Wed, 22 May 2013 16:21:26 -0700 +Subject: [PATCH] Fix build failure seen when using toolchain without threads support + +Signed-off-by: Gilles Talis &lt;gilles.talis-Re5JQEe</pre> Gilles Talis 2013-05-23T00:24:07 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60087 <pre>Fixes: http://autobuild.buildroot.org/results/b62/b62289809221b6455fe3db501e869271a64ea454 Signed-off-by: Gilles Talis &lt;gilles.talis-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; --- package/dvb-apps/Config.in | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/package/dvb-apps/Config.in b/package/dvb-apps/Config.in index 7f76330..a77064e 100644 --- a/package/dvb-apps/Config.in +++ b/package/dvb-apps/Config.in &lt; at &gt;&lt; at &gt; -8,12 +8,13 &lt; at &gt;&lt; at &gt; config BR2_PACKAGE_DVB_APPS if BR2_PACKAGE_DVB_APPS -comment "dvb-apps utils needs LARGEFILE support in the toolchain" -depends on !BR2_LARGEFILE +comment "dvb-apps utils needs a toolchain with LARGEFILE and THREADS support" +depends on !BR2_LARGEFILE || !BR2_TOOLCHAIN_HAS_THREADS config BR2_PACKAGE_DVB_APPS_UTILS bool "dvb-apps utilities" depends on BR2_LARGEFILE +depends on BR2_TOOLCHAIN_HAS_THREADS select BR2_PACKAGE_LIBICONV if !BR2_ENABLE_LOCALE help A small number of DVB test and utility programs, </pre> Gilles Talis 2013-05-23T00:24:03 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60086 <pre>Fixes: http://autobuild.buildroot.org/results/ba2/ba2d3832cb6838b2126e0f7db223305eab579d59 Signed-off-by: Gilles Talis &lt;gilles.talis-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; --- package/portaudio/Config.in | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/package/portaudio/Config.in b/package/portaudio/Config.in index df884a7..0a4d71b 100644 --- a/package/portaudio/Config.in +++ b/package/portaudio/Config.in &lt; at &gt;&lt; at &gt; -1,11 +1,15 &lt; at &gt;&lt; at &gt; config BR2_PACKAGE_PORTAUDIO bool "portaudio" +depends on BR2_TOOLCHAIN_HAS_THREADS help PortAudio is a free, cross-platform, open-source, audio I/O library. http://www.portaudio.com/ +comment "portaudio needs a toolchain threads support" +depends on !BR2_TOOLCHAIN_HAS_THREADS + if BR2_PACKAGE_PORTAUDIO config BR2_PACKAGE_PORTAUDIO_ALSA </pre> Gilles Talis 2013-05-23T00:24:05 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60085 <pre>Signed-off-by: Gilles Talis &lt;gilles.talis-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; --- package/tvheadend/Config.in | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/package/tvheadend/Config.in b/package/tvheadend/Config.in index 19ab276..7083b01 100644 --- a/package/tvheadend/Config.in +++ b/package/tvheadend/Config.in &lt; at &gt;&lt; at &gt; -1,9 +1,10 &lt; at &gt;&lt; at &gt; -comment "tvheadend requires a toolchain with LARGEFILE and IPv6 support" - depends on !BR2_LARGEFILE || !BR2_INET_IPV6 +comment "tvheadend needs a toolchain with LARGEFILE, IPv6 and THREADS support" + depends on !BR2_LARGEFILE || !BR2_INET_IPV6 || !BR2_TOOLCHAIN_HAS_THREADS config BR2_PACKAGE_TVHEADEND bool "tvheadend" depends on BR2_LARGEFILE &amp;&amp; BR2_INET_IPV6 +depends on BR2_TOOLCHAIN_HAS_THREADS # tvheadend requires an atomic_add operation. Either you have # a gcc &gt;= 4.3 toolchain and it uses the gcc intrinsics, or it # has special code for x86, x86-64, PPC and ARM. So in the </pre> Gilles Talis 2013-05-23T00:24:04 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60084 <pre>Signed-off-by: Gilles Talis &lt;gilles.talis-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; --- package/portaudio/portaudio.mk | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/package/portaudio/portaudio.mk b/package/portaudio/portaudio.mk index 34b0bd9..917702e 100644 --- a/package/portaudio/portaudio.mk +++ b/package/portaudio/portaudio.mk &lt; at &gt;&lt; at &gt; -9,6 +9,8 &lt; at &gt;&lt; at &gt; PORTAUDIO_SITE = http://www.portaudio.com/archives PORTAUDIO_SOURCE = pa_stable_$(PORTAUDIO_VERSION).tgz PORTAUDIO_INSTALL_STAGING = YES PORTAUDIO_MAKE = $(MAKE1) +PORTAUDIO_LICENSE = MIT +PORTAUDIO_LICENSE_FILES = LICENSE.txt PORTAUDIO_DEPENDENCIES = \ $(if $(BR2_PACKAGE_PORTAUDIO_WITH_ALSA),alsa-lib) </pre> Gilles Talis 2013-05-23T00:24:06 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60083 <pre> Dear all, Ok, I will have to do so work to apply the board patches to the freescale kernel required for the ipu support stuff. The binary firmware imx should be selected too I think when the fsl ipu firmware is build. Can't this kind of situations be anticipated by the buildroot menu system ? Regards Johan -----Oorspronkelijk bericht----- Van: buildroot-bounces-9GAsQqxh4YTR7s880joybQ&lt; at &gt;public.gmane.org [mailto:buildroot-bounces-9GAsQqxh4YTR7s880joybQ&lt; at &gt;public.gmane.org] Namens Thomas Petazzoni Verzonden: woensdag 22 mei 2013 16:42 Aan: Sagaert Johan CC: buildroot-9GAsQqxh4YTR7s880joybQ&lt; at &gt;public.gmane.org; 'Angolini Daiane-B19406' Onderwerp: Re: [Buildroot] gst-fsl plugins imx53 build error Dear Sagaert Johan, On Wed, 22 May 2013 16:25:42 +0200, Sagaert Johan wrote: As Angolini replied to you (without Cc'ing the list, unfortunately), you have to use a Freescale kernel for this gst-fsl plugin to work. The mainline kernel cannot work. menuconfig shows the following comment: comment "gst-fsl-plugins requ</pre> Sagaert Johan 2013-05-22T23:14:15 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60082 <pre>Dear Yann E. MORIN, On Wed, 22 May 2013 19:30:35 +0200, Yann E. MORIN wrote: Ok, thanks. Indeed. In this specific case, I believe a comment could be part of the commit log itself, because it can be useful to preserve in the Git history why the bump was made as a single commit. Thanks, Thomas </pre> Thomas Petazzoni 2013-05-22T18:01:07 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60081 <pre>Woody, All, On 2013-05-22 23:12 +0800, Woody Wu spake thusly: I don't know the details but "GNU EABI" (aka "EABI v0") was following the draft EABI (there's also EABIv4 floating around with the same shortcomings), and was incompatible with the final EABI. That's more or less what I understood myself (but I may be wrong). So, today's toolchains do not produce EABIv0 (nor EABIv4) binaries, only EABIv5; this is the case for Buildroot-built toolchains. If you want to target these libraries, you have to use the same toolchain as was used to build your library. Buildroot won't be able to build one for you. Besides, if you wanted to build such a toolchain, you'd have to use the tools that were current at the time, not the latest versions. Regards, Yann E. MORIN. </pre> Yann E. MORIN 2013-05-22T17:37:03 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60080 <pre>Thanks pointing me at these new patches. Spenser On Wed, May 22, 2013 at 10:57 AM, prabindh &lt;prabu-l0cyMroinI0&lt; at &gt;public.gmane.org&gt; wrote: </pre> Spenser Gilliland 2013-05-22T17:33:51 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60079 <pre>Spenser, Thomas, All, On 2013-05-22 10:57 -0500, Spenser Gilliland spake thusly: Thomas, that was me pointing out that bumping glib2, glibmm and glib-networking separately might be an error, and IIRC Spenser confirmed that with a test build (discussed on IRC some days ago). Spenser, to avoid confusion in the future: - add the relevant commenter as Cc: in the commit log, - and add a little history to your patch commit log, like: blabla: do the foo Some explanations possibly on multiple lines Signed-off-by: you Cc: someone Cc: someone else --- v2 -&gt; v3: - fix this and that (someone else) v1 -&gt; v2: - tweak this and that (someone) So the reviewer know what has changed when you resend your patch(es). Regards, Yann E. MORIN. </pre> Yann E. MORIN 2013-05-22T17:30:35 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60078 <pre> imx-lib 12.09 was not developed/tested to be used on imx53. 12.09 is for imx6 only, although the imx53 source code was the base for 12.09. The kernel you need to use is http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_2.6.35_11.09.01 It would be better if you could use imx-lib from 11.09.01 as well. And fsl multimedia package is 2.0.3 for imx53 But, I don't understand yet which version is included in buildroot tree, so I'm not sure if this information can help you. Regarding unsupported platform you must use PLATFORM = "IMX51" during configure/make process </pre> Daiane Angolini 2013-05-22T16:52:17 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60077 <pre>Hi, I have a cmake based project which I am trying to incorporate into buildroot-2012.05 As part of the configuration of the code I need to pass it an environment variable $(CLIENT_VER) which I generate at the time of building in the source directory (which I check out of SVN). I have tried various approaches without success. This is my mk file #I first tried this approach by generating the cmake configuration #command with a script and then executing that script #but the problem here was I would need to know the location of the #buildroot generated version of cmake and the toolchain file #I could figure these out in the script but I felt there must be a #simpler approach #define CLIENT_BARROW_CONFIGURE_CMDS #(cd $(CLIENT_BARROW_SRCDIR) &amp;&amp; source set_environment.sh \ #&amp;&amp; ./cmake_run \ #) #endef #then I tried this define CLIENT_BARROW_SET_ENVIRONMENT (source $(CLIENT_BARROW_SRCDIR)set_environment.sh \ &amp;&amp; echo "Running Pre Configure Hook " \ ) endef CLIENT_BARROW_PRE_CONFIGURE_HOOKS = CLIENT_BARRO</pre> john 2013-05-22T16:21:55 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60076 <pre>The recipe will be upgraded to the below - I just submitted revised patchset: So please keep that in mind when building your recipe. The new recipe removes lot of unsupported old features, and generally cleans up the rest. http://comments.gmane.org/gmane.linux.embedded.yocto.meta-ti/1946 regards, Prabu From: Spenser Gilliland-2 [via Buildroot (busybox)] [mailto:ml-node+s2317881n45674h97-PdW2FhcaLsRl57MIdRCFDg&lt; at &gt;public.gmane.org] Sent: Wednesday, May 22, 2013 8:10 PM To: Sundareson, Prabindh Subject: Re: Currently packaging Qt5 Prabu &amp; Thomas, I was actually working on this last night! As a resource I am using the ti-meta overlay from http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp/powervr-drivers/omap3-sgx-modules_4.09.00.01.bb . I can download and build the driver (kinda of messy), but I haven't tested it yet. You can see the progress on my Github. I've automated the license acceptance as well as the sgx driver build. Still working on the rest. Spenser On Wed, May 22, 2013 at 9</pre> prabindh 2013-05-22T15:57:52 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60075 <pre>Thomas, Oops, one day I will get the hang of this. Case 1 is correct. I was trying to make the patch bisect-able. It's possible that glibmm and glib-networking would fail to build if the version is not consistent. -- Spenser Gilliland Computer Engineer Doctoral Candidate </pre> Spenser Gilliland 2013-05-22T15:57:30 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60074 <pre>On 22 May 2013 16:52, Thomas Petazzoni &lt;thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8&lt; at &gt;public.gmane.org&gt; wrote: Hi Thomas, Thank you for the clarification. I will prepare a new patch. -- Regards, Markos Chandras </pre> Markos Chandras 2013-05-22T15:56:32 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60073 <pre>Dear Woody Wu, On Wed, 22 May 2013 23:04:31 +0800, Woody Wu wrote: No. You have two ABIs: * OABI, Original ABI (or "Old" ?), which was used by the Linux world on ARM platforms before ARM (the company) standardized an ABI. This ABI is deprecated, both in Buildroot and upstream in gcc, if I remember correctly. * EABI, Enhanced ABI, which is known in the Linux world as GNU EABI. So when you have a arm-linux-gnueabi toolchain, or arm-linux-uclibcgnueabi toolchains, those are using this EABI. This ABI is standardized by ARM. And Buildroot always uses this ABI when it generates a toolchain. Best regards, Thomas </pre> Thomas Petazzoni 2013-05-22T15:54:51 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60072 <pre>Dear Markos Chandras, On Wed, 22 May 2013 15:57:36 +0100, Markos Chandras wrote: Yes, in the external toolchain backend, we support eglibc and glibc similarly, so there's just one single option for both. It is however not needed to put BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC in your condition, because it already selects BR2_TOOLCHAIN_EXTERNAL_GLIBC. So as far as external toolchains are concerned, "depends on BR2_TOOLCHAIN_EXTERNAL_GLIBC" is enough. Thanks, Thomas </pre> Thomas Petazzoni 2013-05-22T15:52:59 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60071 <pre>在 2013-5-22 PM5:34，"Yegor Yefremov" &lt;yegorslists&lt; at &gt;googlemail.com&gt;写道： Hi, Yegor When I compile my new program using buildroot toolchain and link it to a old shared library buit from another uClibC toolchain, it reported EABI version mismatch. My new program is EABI version 5, and the expected to be linked (-lfoo) is EABI version 0. When using readelf to check the library file, it reported it's GNU EABI. That why I thought I should try to make my buildroot to generate GNU EABI object. If I messed some concept, could you please tell me what should I do? Thanks! -narke _______________________________________________ buildroot mailing list buildroot-9GAsQqxh4YTR7s880joybQ&lt; at &gt;public.gmane.org http://lists.busybox.net/mailman/listinfo/buildroot</pre> Woody Wu 2013-05-22T15:12:29 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60070 <pre>在 2013-5-22 PM7:51，"Thomas Petazzoni" &lt;thomas.petazzoni&lt; at &gt;free-electrons.com Hi, Thomas Did you mean the GNU EABI is the OABI? _______________________________________________ buildroot mailing list buildroot-9GAsQqxh4YTR7s880joybQ&lt; at &gt;public.gmane.org http://lists.busybox.net/mailman/listinfo/buildroot</pre> Woody Wu 2013-05-22T15:04:31 http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/60069 <pre>On 22 May 2013 15:43, Thomas Petazzoni &lt;thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8&lt; at &gt;public.gmane.org&gt; wrote: Hi Thomas, No problem. Although I can't find an option for external toolchain + eglibc. So what I have right now is this: # {get,make,swap}context functions present in # {e,}glibc and in uClibc's master branch. depends on BR2_UCLIBC_VERSION_SNAPSHOT || \ BR2_TOOLCHAIN_CTNG_eglibc || \ BR2_TOOLCHAIN_CTNG_glibc || \ BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC || \ BR2_TOOLCHAIN_EXTERNAL_GLIBC I believe this should cover all the cases. Thanks for the review -- Regards, Markos Chandras </pre> Markos Chandras 2013-05-22T14:57:36 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.uclibc.buildroot