* [Buildroot] libgomp.so.1.0.0 not in target image
From: Arnout Vandecappelle @ 2012-11-13 23:06 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121113231021.6995bd28@skate>
On 13/11/12 23:10, Thomas Petazzoni wrote:
> Arnout,
>
> On Tue, 13 Nov 2012 18:34:32 +0100, Arnout Vandecappelle wrote:
>
>> Thomas, I think this should be fixed by adding libgomp to
>> LIB_EXTERNAL_LIBS in ext-tool.mk. Is that right? Will that also
>> work if libgomp doesn't exist?
>
> Do we really need to be linked against libgomp? Under what conditions
> does that happen? Can't we avoid that even if the toolchain has OpenMP
> support?
beecrypt links agains libgomp if libgomp is available; rpm uses beecrypt.
The point is not avoiding to link with libgomp (you have to do that explicitly),
the point is that if somebody links against libgomp, it has to be in target.
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 for-2012.11] qextserialport: don't require Qt GUI module
From: Arnout Vandecappelle @ 2012-11-13 22:51 UTC (permalink / raw)
To: buildroot
Fixes e.g.
http://autobuild.buildroot.net/results/e80ae76fa21f87bef10e08c7452b796dc0986ff2/
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
package/qextserialport/qextserialport-gui.patch | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/package/qextserialport/qextserialport-gui.patch b/package/qextserialport/qextserialport-gui.patch
new file mode 100644
index 0000000..d3dedae
--- /dev/null
+++ b/package/qextserialport/qextserialport-gui.patch
@@ -0,0 +1,16 @@
+Don't require Qt GUI module
+
+Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
+---
+diff -Nrup qextserialport-f83b4e7ca922e53.orig/qextserialport.pro qextserialport-f83b4e7ca922e53/qextserialport.pro
+--- qextserialport-f83b4e7ca922e53.orig/qextserialport.pro 2012-10-17 09:13:53.000000000 +0200
++++ qextserialport-f83b4e7ca922e53/qextserialport.pro 2012-11-13 22:48:29.249431510 +0100
+@@ -41,6 +41,8 @@ macx:qesp_mac_framework {
+
+ win32|mac:!wince*:!win32-msvc:!macx-xcode:CONFIG += debug_and_release build_all
+
++!win32*:!wince*:QT -= gui
++
+ #generate proper library name
+ greaterThan(QT_MAJOR_VERSION, 4) {
+ QESP_LIB_BASENAME = QtExtSerialPort
--
tg: (234fe44..) t/qtextserialport (depends on: master)
^ permalink raw reply related
* [Buildroot] libgomp.so.1.0.0 not in target image
From: Thomas Petazzoni @ 2012-11-13 22:10 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A284A8.9070304@mind.be>
Arnout,
On Tue, 13 Nov 2012 18:34:32 +0100, Arnout Vandecappelle wrote:
> Thomas, I think this should be fixed by adding libgomp to
> LIB_EXTERNAL_LIBS in ext-tool.mk. Is that right? Will that also
> work if libgomp doesn't exist?
Do we really need to be linked against libgomp? Under what conditions
does that happen? Can't we avoid that even if the toolchain has OpenMP
support?
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 v3] xtensa: support configurable processor configurations
From: Chris Zankel @ 2012-11-13 21:54 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121113224442.70f141be@skate>
Hi Thomas,
On 11/13/2012 01:44 PM, Thomas Petazzoni wrote:
> Chris,
>
> On Tue, 13 Nov 2012 13:01:03 -0800, Chris Zankel wrote:
>
>> Sorry, I got your email after I sent out version 4 of the patch, which
>> doesn't include the change you mentioned (somehow, fetchmail was stuck
>> :-( So, please let me know if you want me to send out another version
>> that includes that change. I don't want to confuse Thomas with all
>> those versions...
> You can keep your patch as is wrt to Config.in. What I propose to do is
> that I merge your Xtensa support in one of my branch together with my
> reorganization of the architecture definitions and I send a
> pull-request for the whole thing to Peter.
>
> Would that be OK for you?
That would be great! Could you please use v4 of the two patches as they
include changes suggested by Arnout.
Thanks,
-Chris
^ permalink raw reply
* [Buildroot] [PATCH 2/2 v3] xtensa: support configurable processor configurations
From: Thomas Petazzoni @ 2012-11-13 21:44 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A2B50F.60609@zankel.net>
Chris,
On Tue, 13 Nov 2012 13:01:03 -0800, Chris Zankel wrote:
> Sorry, I got your email after I sent out version 4 of the patch, which
> doesn't include the change you mentioned (somehow, fetchmail was stuck
> :-( So, please let me know if you want me to send out another version
> that includes that change. I don't want to confuse Thomas with all
> those versions...
You can keep your patch as is wrt to Config.in. What I propose to do is
that I merge your Xtensa support in one of my branch together with my
reorganization of the architecture definitions and I send a
pull-request for the whole thing to Peter.
Would that be OK for you?
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] grub problems since upgrading build host to CentOS 6.3
From: Arnout Vandecappelle @ 2012-11-13 21:31 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A17C01.1010109@plexxi.com>
On 12/11/12 23:45, Joe Lorenz wrote:
> We updated our build host to CentOS 6.3 which apparently has a newer host gcc.
>
> Our crosstools are set for x86_64 target, and we know about grub not being supported for 64-bit compiler (Bug 5024).
> This newer gcc and/or binutils might be to blame.
>
> The problem shows when we try to install it - we see this:
>
> grub> device (hd0) /dev/sdb
> grub> root (hd0,1)
> Filesystem type is ext2fs, partition type 0x83
> grub> setup (hd0)
> Checking if "/boot/grub/stage1" exists... no
> Checking if "/grub/stage1" exists... no
>
> Error 15: File not found
> grub>
>
> But 'stage1' and all the others are indeed present on the root partition at /boot/grub/.
Let me try to understand what you're doing.
- You have a buildroot config that includes grub.
- You build on a pre-6.3 machine, boot the resulting image, run grub.
- grub finds /boot/grub/stage1 on /dev/sdb
- You build on a 6.3 machine, boot the resulting image, run grub.
- grub doesn't find /boot/grub/stage1 on /dev/sdb
Is that correct? Sounds weird... Can grub find any files on
(hd0,1)?
>
> It's important to us to be able to build grub as needed in case we have to modify any networking hardware support, so
> falling back to using older binaries is not optimal. We're wondering if anyone else has gotten around this in a CentOS
> 6.3 build environment.
You could add grub2 to your local buildroot - see
http://patchwork.ozlabs.org/patch/191813/
Needs work, of course, but worked for me. grub2 is much better at cross-
compiling than grub.
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] libgomp.so.1.0.0 not in target image
From: Yann E. MORIN @ 2012-11-13 21:31 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A2B9CF.9010007@mind.be>
Arnout, All,
On Tuesday 13 November 2012 Arnout Vandecappelle wrote:
> On 13/11/12 22:19, Yann E. MORIN wrote:
> > In crosstool-NG, libgomp is not automatically built. There is a config
> > knob to enable/disable build of libgomp (the default is not to build it).
> Yes, it's also not built by default in the internal toolchain. But if it is
> built, then libgomp.so should be installed in $(TARGET_DIR) - and currently it
> isn't.
Yes, that's right. I'll cook up a patch for that shortly.
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] libgomp.so.1.0.0 not in target image
From: Alexander Khryukin @ 2012-11-13 21:24 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201211132219.14720.yann.morin.1998@free.fr>
>But still as an external toolchain, right?
Yes, it's external.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121114/a71e7fbe/attachment.html>
^ permalink raw reply
* [Buildroot] libgomp.so.1.0.0 not in target image
From: Arnout Vandecappelle @ 2012-11-13 21:21 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201211132219.14720.yann.morin.1998@free.fr>
On 13/11/12 22:19, Yann E. MORIN wrote:
> Arnout, All,
>
> On Tuesday 13 November 2012 Arnout Vandecappelle wrote:
>>> On 13/11/12 16:30, Alexander Khryukin wrote:
>>>> I'm built rpm5 package but when i trying to run it i see
>>>>
>>>> [root at localhost rpm]# rpmbuild
>>>> rpmbuild: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or
>>>> directory
> [--SNIP--]
>> But still as an external toolchain, right? Ouch, now I see crosstool-ng has the
>> same problem... But an internal toolchain should work, I think.
>
> In crosstool-NG, libgomp is not automatically built. There is a config
> knob to enable/disable build of libgomp (the default is not to build it).
Yes, it's also not built by default in the internal toolchain. But if it is
built, then libgomp.so should be installed in $(TARGET_DIR) - and currently it
isn't.
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] libgomp.so.1.0.0 not in target image
From: Yann E. MORIN @ 2012-11-13 21:19 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A2B716.1070803@mind.be>
Arnout, All,
On Tuesday 13 November 2012 Arnout Vandecappelle wrote:
>> On 13/11/12 16:30, Alexander Khryukin wrote:
>>> I'm built rpm5 package but when i trying to run it i see
>>>
>>> [root at localhost rpm]# rpmbuild
>>> rpmbuild: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or
>>> directory
[--SNIP--]
> But still as an external toolchain, right? Ouch, now I see crosstool-ng has the
> same problem... But an internal toolchain should work, I think.
In crosstool-NG, libgomp is not automatically built. There is a config
knob to enable/disable build of libgomp (the default is not to build it).
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 v2 3/6] Add board files for snowball
From: Arnout Vandecappelle @ 2012-11-13 21:18 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A228F9.20605@calao-systems.com>
On 13/11/12 12:03, Gr?gory Hermant wrote:
> Le 12/11/2012 19:37, Thomas Petazzoni a ?crit :
>> Dear Gregory Hermant,
>>
>> On Mon, 12 Nov 2012 18:41:39 +0100, Gregory Hermant wrote:
>>>
>>> Signed-off-by: Gregory Hermant<gregory.hermant@calao-systems.com>
>>> ---
>>> board/calao/snowball/busybox-1.20.x.config | 1024 ++++++++++++++++++++++++++++
>>
>> Is there a specific reason to have a custom Busybox configuration file?
>
> Enable the firmware loading (mdev).
As I wrote last Friday, that is (or should be) enabled automatically when you
select BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV, which you do in patch 6/6.
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] libgomp.so.1.0.0 not in target image
From: Arnout Vandecappelle @ 2012-11-13 21:09 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CABtOAfyZQW+0KxtNF-cv-eFxBBqkMoyKAw1fSLgTN1WA-S8LrA@mail.gmail.com>
On 13/11/12 21:55, Alexander Khryukin wrote:
>
>
> 2012/11/13 Arnout Vandecappelle <arnout at mind.be <mailto:arnout@mind.be>>
>
> On 13/11/12 16:30, Alexander Khryukin wrote:
>
> Hello.
> I'm built rpm5 package but when i trying to run it i see
>
> [root at localhost rpm]# rpmbuild
> rpmbuild: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or
> directory
>
[snip]
>
> Alexander, you are using a recent external Linaro toolchain, right?
>
> Thomas, I think this should be fixed by adding libgomp to LIB_EXTERNAL_LIBS
> in ext-tool.mk. Is that right? Will that also work if libgomp doesn't exist?
>
[snip]
>
> I'm using own toolchain but it based on linaro
> also linaro toolchain affected too
But still as an external toolchain, right? Ouch, now I see crosstool-ng has the
same problem... But an internal toolchain should work, I think.
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] howto incorporate buildroot into an autobuild
From: Arnout Vandecappelle @ 2012-11-13 21:04 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAHqTa-2vZ_xs26oCX8kFtgQQzGaOcLWG=r2S+hsmUi1E6WZ2Vg@mail.gmail.com>
On 13/11/12 06:02, Avery Pennarun wrote:
> I also severely hacked up buildroot to be able to build multiple
> packages in parallel on a multicore machine; this makes builds
> typically 2-3x faster on our setup, and probably even more so if you
> use a really fast disk (SSD RAID?) and lots of RAM and multiple CPUs.
> You can see our hacked-up version here:
> http://gfiber.googlesource.com/buildroot
>
> Beware, however, as it may burn your eyes. Someday I would like to
> clean up the parallelism patches and submit them here.
Wow! There are a couple of great ideas in that repository. I certainly
wouldn't mind seeing some of these things upstreamed. Like the shuffle
thing, that would be really great for the autobuilders.
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 2/2 v3] xtensa: support configurable processor configurations
From: Chris Zankel @ 2012-11-13 21:01 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A2ADBC.9080704@mind.be>
Hi Arnout,
Sorry, I got your email after I sent out version 4 of the patch, which
doesn't include the change you mentioned (somehow, fetchmail was stuck
:-( So, please let me know if you want me to send out another version
that includes that change. I don't want to confuse Thomas with all those
versions...
Thanks,
-Chris
On 11/13/2012 12:29 PM, Arnout Vandecappelle wrote:
>> I guess I don't understand what that patch does, i.e. where is the
>> 'if...endif'? Could you maybe point to the patch?
> I'm talking about http://patchwork.ozlabs.org/patch/196916/
> In arch/Config.in, it introduces the following construct:
>
> if BR2_xtensa
> source "arch/Config.in.xtensa"
> endif
>
> This removes the need for adding 'depend on BR2_xtensa' in every config
> option in that file.
>
> It's true that _now_ xtensa would be the only one using that scheme, but the
> idea is that if you do that for xtensa now, it will be easier to merge in
> Thomas's patch later (or vice versa, it will be easier to rebase your patch
> once Thomas's patch gets merged).
^ permalink raw reply
* [Buildroot] libgomp.so.1.0.0 not in target image
From: Alexander Khryukin @ 2012-11-13 20:55 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A284A8.9070304@mind.be>
2012/11/13 Arnout Vandecappelle <arnout@mind.be>
> On 13/11/12 16:30, Alexander Khryukin wrote:
>
>> Hello.
>> I'm built rpm5 package but when i trying to run it i see
>>
>> [root at localhost rpm]# rpmbuild
>> rpmbuild: error while loading shared libraries: libgomp.so.1: cannot open
>> shared object file: No such file or directory
>>
>> Lib not exist in filesystem but exit into
>>
>>
>> find . -name *gomp*
>> ./output/host/usr/arm-**buildroot-linux-gnueabi/**
>> sysroot/lib/libgomp.spec
>> ./output/host/usr/arm-**buildroot-linux-gnueabi/**
>> sysroot/lib/libgomp.so.1.0.0
>> ./output/host/usr/arm-**buildroot-linux-gnueabi/**sysroot/lib/libgomp.so
>> ./output/host/usr/arm-**buildroot-linux-gnueabi/**sysroot/lib/libgomp.a
>> ./output/host/usr/arm-**buildroot-linux-gnueabi/**sysroot/lib/libgomp.la<
>> http://libgomp.la>
>>
>> ./output/host/usr/arm-**buildroot-linux-gnueabi/**
>> sysroot/lib/libgomp.so.1
>>
>>
>> It's a bug or feature?
>>
>
> Yep, that's a bug. It's surprising that nobody has run into this before -
> maybe
> OpenMP support was only recently added to the Linaro toolchain.
>
> Alexander, you are using a recent external Linaro toolchain, right?
>
> Thomas, I think this should be fixed by adding libgomp to
> LIB_EXTERNAL_LIBS
> in ext-tool.mk. Is that right? Will that also work if libgomp doesn't
> exist?
>
> 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<http://www.linkedin.com/in/arnoutvandecappelle>
> GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
>
>
I'm using own toolchain but it based on linaro
also linaro toolchain affected too
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121113/014aba4e/attachment.html>
^ permalink raw reply
* [Buildroot] howto incorporate buildroot into an autobuild
From: Arnout Vandecappelle @ 2012-11-13 20:43 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121113094526.6392ab30@skate>
On 13/11/12 09:45, Thomas Petazzoni wrote:
> Hello John,
>
> On Mon, 12 Nov 2012 16:47:29 -0800, John Stile wrote:
>> I am using buildroot for an embedded Arm project.
>>
>> I was wondering how people using buildroot implement continuous
>> integration builds?
>>
>> Do you start from a clean checkout, build the whole tool chain (which
>> takes a long time), and then build the project specific stuff?
>>
>> I worry about not starting from a clean checkout, since some options may
>> change, and the tools won't be rebuilt.
>>
>> But I also worry people will complain how long the build takes.
>>
>> Is there a good strategy to balance these concerns?
>
> If you do continuous integration builds, do you really care that much
> about the build time? Even if the build takes an hour, it is still very
> reasonable for an continuous integration build system.
If you take the approach of e.g. Qt and require *every* patch to pass an
individual CI run before its accepted, then an hour is not acceptable...
> Tips to reduce the build time:
>
> * Get a fast machine. Many people complaining about build time are
> building inside a virtual machine on a slow laptop. This simply
> cannot work. Get a 4 or 8 cores machine, with 16+ GB of RAM, and
> some good I/Os.
I don't know... Buildroot currently serializes a lot (cfr. Avery's
remark), so going beyond 2 cores will not help that much. It's better
to have several machines (or a single big machine) that do different
CI builds in parallel.
> * Use an external toolchain.
I.e. build only your toolchain with BR2_HOST_DIR set to a different path,
and use that path as an external toolchain in future builds.
* Staggered builds. Assuming most commits are in your own software, you
can usually define a base layer that usually doesn't change. Do a build
of this base layer once and reuse it for later builds. Of course, you still
need to do full, clean builds occasionally.
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 2/2 v3] xtensa: support configurable processor configurations
From: Arnout Vandecappelle @ 2012-11-13 20:29 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A18A2B.1050102@zankel.net>
On 13/11/12 00:45, Chris Zankel wrote:
> On 11/12/2012 01:33 PM, Arnout Vandecappelle wrote:
>>
>> Perhaps it's better to move the condition to a
>> if BR2_xtensa
>> ...
>> endif
>> around the entire file. Thomas has a patch lined up to move all
>> the conditions outside of the Config.in.*
>>> It seems Xtensa would be the only one that uses that scheme, so maybe
>>> wait for the generic patch from Thomas?
>> I don't think so. Then it means more work for Thomas to refresh his
>> patch. There will be a merge conflict anyway between the two, but
>> with the condition outside the file the conflict will be small.
>>
>> That said, Peter hasn't merged Thomas's patch even though I acked
>> it, so maybe he has some fundamental objection to the principle.
>> Or maybe it's just because I didn't test it.
> I guess I don't understand what that patch does, i.e. where is the
> 'if...endif'? Could you maybe point to the patch?
I'm talking about http://patchwork.ozlabs.org/patch/196916/
In arch/Config.in, it introduces the following construct:
if BR2_xtensa
source "arch/Config.in.xtensa"
endif
This removes the need for adding 'depend on BR2_xtensa' in every config
option in that file.
It's true that _now_ xtensa would be the only one using that scheme, but the
idea is that if you do that for xtensa now, it will be easier to merge in
Thomas's patch later (or vice versa, it will be easier to rebase your patch
once Thomas's patch gets merged).
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 v2] kexec: disable on avr32
From: Arnout Vandecappelle @ 2012-11-13 20:22 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352796707-9197-1-git-send-email-spdawson@gmail.com>
On 13/11/12 09:51, spdawson at gmail.com wrote:
> From: Simon Dawson<spdawson@gmail.com>
>
> kexec does not support the avr32 architecture; this results in autobuilder
> failures such as the following.
>
> http://autobuild.buildroot.net/results/5f5e91c3eb622bce88402a9afc8a3e7bd5007136/build-end.log
>
> This patch disables support for the kexec package on the avr32 architecture.
>
> Signed-off-by: Simon Dawson<spdawson@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
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 v2] bluez-utils: disable on avr32
From: Arnout Vandecappelle @ 2012-11-13 20:22 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352797007-9509-1-git-send-email-spdawson@gmail.com>
On 13/11/12 09:56, spdawson at gmail.com wrote:
> From: Simon Dawson<spdawson@gmail.com>
>
> The bluez-utils package does not build for the avr32 architecture; this
> results in autobuilder failures such as the following.
>
> http://autobuild.buildroot.net/results/d737d1220d7566289eee802fd580a49d8c456c97/build-end.log
>
> The underlying problem is with the<sys/epoll.h> header provided by the
> antiquated avr32 toolchain; this header lacks definitions for
> epoll_create1() and EPOLL_CLOEXEC.
>
> This patch disables support for the bluez-utils package on the avr32
> architecture.
>
> Signed-off-by: Simon Dawson<spdawson@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This one is for 2012.11.
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] package: add knxweb
From: Arnout Vandecappelle @ 2012-11-13 20:21 UTC (permalink / raw)
To: buildroot
In-Reply-To: <5098C815.8080901@calao-systems.com>
On 06/11/12 09:19, Gr?gory Hermant wrote:
> Hi thomas,
>
> Le 30/10/2012 13:55, Thomas Petazzoni a ?crit :
>> Dear Gregory Hermant,
>>
>> On Tue, 30 Oct 2012 13:24:03 +0100, Gregory Hermant wrote:
>>> diff --git a/package/knxweb/knxweb.mk b/package/knxweb/knxweb.mk
>>> new file mode 100644
>>> index 0000000..5ca1760
>>> --- /dev/null
>>> +++ b/package/knxweb/knxweb.mk
>>> @@ -0,0 +1,20 @@
>>> +#############################################################
>>> +#
>>> +# knxweb
>>> +#
>>> +#############################################################
>>> +
>>> +KNXWEB_VERSION = 0.6.1
>>> +KNXWEB_SOURCE = knxweb-$(KNXWEB_VERSION).tar.gz
>>> +KNXWEB_SITE = http://sourceforge.net/projects/linknx/files/knxweb/knxweb-0.6.1/
This URL doesn't work - it should be
http://downloads.sourceforge.net/project/linknx/knxweb/knxweb-0.6
For this case, you better refactor
KNXWEB_VERSION_MAJOR = 0.6
KNXWEB_VERSION = $(KNXWEB_VERSION_MAJOR).1
KNXWEB_SITE = http://downloads.sourceforge.net/project/linknx/knxweb/knxweb-$(KNXWEB_VERSION_MAJOR)
Note that you can remove KNXWEB_SOURCE, it is the default.
>>
>> The tarball has no license information, this is quite annoying.
>
> How can we manage this kind of package in buildroot ?
There's no solution, it's just annoying. Or actually, it's more than annoying:
since no explicit permission is given to copy the code, any use beyond simply
downloading it is illegal... So I guess you should put:
KNXWEB_LICENSE = none (no permission is given)
>>
>>> +define KNXWEB_INSTALL_TARGET_CMDS
>>> + mkdir -p $(TARGET_DIR)/var/www
>>> + cp -rdpf $(@D)/* $(TARGET_DIR)/var/www
>>> +endef
>>> +
>>> +define KNXWEB__UNINSTALL_TARGET_CMDS
>>> + rm -rf $(TARGET_DIR)/var/www/
>>> +endef
>>
>> Double _ here, so this doesn't work.
>>
>> However, how does this web interface works? I see a few PHP scripts,
>> but they don't seem to be essential for the operation of the Web
>> interface. There's a lot of JS though. Does it communicate with the
>> server somehow?
>>
> knxweb needs a web server with PHP support.
>
>> I'm surprised that no interpreter like PHP, Lua or Python is needed
>> here for the server side, that's why I'm asking.
At the moment we can't select or depend on a web server. Selecting PHP is
possible, however, so I think you should add that to Config.in (not to the
.mk file because there is no build-time dependency)
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 1/1] grantlee: fix lpthread build error
From: Arnout Vandecappelle @ 2012-11-13 20:00 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1352808310-6303-1-git-send-email-mr.zoltan.gyarmati@gmail.com>
On 13/11/12 13:05, Zoltan at osuosl.org wrote:
> From: "Zoltan Gyarmati"<mr.zoltan.gyarmati@gmail.com>
>
>
> Signed-off-by: Zoltan Gyarmati<mr.zoltan.gyarmati@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(it already worked for me, but at least this patch doesn't break things)
However, your patch still misses the following things:
- The commit message is too vague. It should describe the problem in more detail,
including the root cause. For example:
grantlee: fix -lpthread build error
Build fails because of missing -lpthread with toolchains that need it. It
gives an error log like:
Linking CXX executable testgenerictypes_exec
/home/buildroot12git/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld:
/home/buildroot12git/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libQtCore.so: undefined reference
to symbol 'pthread_cancel'
/home/buildroot12git/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld:
note: 'pthread_cancel' is defined in DSO
/home/buildroot12git/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/lib/libpthread.so.0 so try adding it to
the linker command line
/home/buildroot12git/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/lib/libpthread.so.0: could not read
symbols: Invalid operation
collect2: ld returned 1 exit status
make[3]: *** [templates/tests/testgenerictypes_exec] Error 1
make[3]: Leaving directory `/home/buildroot12git/output/build/grantlee-0.2.0'
make[2]: *** [templates/tests/CMakeFiles/testgenerictypes_exec.dir/all] Error 2
make[2]: Leaving directory `/home/buildroot12git/output/build/grantlee-0.2.0'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/buildroot12git/output/build/grantlee-0.2.0'
make: *** [/home/buildroot12git/output/build/grantlee-0.2.0/.stamp_built] Error
- The patch itself should contain an equally detailed description (can be a copy
of the commit message). It should also have your Signed-off-by line.
Both of these are minor things, however.
Regards,
Arnout
> ---
> .../grantlee-0.2.0-fix-lphread-link-error.patch | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
> create mode 100644 package/grantlee/grantlee-0.2.0-fix-lphread-link-error.patch
>
> diff --git a/package/grantlee/grantlee-0.2.0-fix-lphread-link-error.patch b/package/grantlee/grantlee-0.2.0-fix-lphread-link-error.patch
> new file mode 100644
> index 0000000..8293172
> --- /dev/null
> +++ b/package/grantlee/grantlee-0.2.0-fix-lphread-link-error.patch
> @@ -0,0 +1,13 @@
> +diff -rupN grantlee-0.2.0_orig/templates/tests/CMakeLists.txt grantlee-0.2.0/templates/tests/CMakeLists.txt
> +--- grantlee-0.2.0_orig/templates/tests/CMakeLists.txt 2012-11-13 12:11:44.583379820 +0100
> ++++ grantlee-0.2.0/templates/tests/CMakeLists.txt 2012-11-13 11:35:18.000000000 +0100
> +@@ -68,7 +68,8 @@ macro(GRANTLEE_TEMPLATES_UNIT_TESTS)
> + ${_testresource_rcc_src}
> + )
> + add_test(${_testname} ${_testname}_exec )
> +- target_link_libraries(${_testname}_exec ${QT_QTTEST_LIBRARY} grantlee_core )
> ++ find_package (Threads)
> ++ target_link_libraries(${_testname}_exec ${QT_QTTEST_LIBRARY} ${CMAKE_THREAD_LIBS_INIT} grantlee_core )
> +
> + set_property(GLOBAL APPEND PROPERTY TEST_COVERAGE "${CMAKE_CURRENT_BINARY_DIR}/${_testname}_exec" )
> + endforeach(_testname)
--
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] Udev on a live CD system does not appear to populate /dev
From: Stefan Fröberg @ 2012-11-13 18:07 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A1EE50.4010008@mind.be>
13.11.2012 8:53, Arnout Vandecappelle kirjoitti:
> On 08/11/12 17:29, Stefan Fr?berg wrote:
>> If you ever want to use the maximum compression method supported by
>> modern kernels (XZ compression)
>> then change that initramfs generation command to this:
>>
>> find . -not \( -path "./boot" -prune \) -print0 | cpio --null -ov
>> --format=newc
>> | xz --check=crc32> /livecd/initramfs.xz
>>
>> Without that --check=crc32 parameter you won't be able to boot
>> XZ-compressed initramfs.
>
> It would be good to have this in buildroot. Care to add a config option
> BR2_TARGET_ROOTFS_CPIO_XZ? Using host-xz, of course, since not all
> systems
> have xz installed.
>
Sure, no problem.
So far I have only done initramfs my own manual way but I will take this
weekend a look how buildroot does its
own initramfs.
Regards
Stefan
>
> Regards,
> Arnout
^ permalink raw reply
* [Buildroot] libgomp.so.1.0.0 not in target image
From: Arnout Vandecappelle @ 2012-11-13 17:34 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CABtOAfzcjFWUVELMn0X4fRF8fcdqBL5HsBzo7sw1wt8JJc+Ghw@mail.gmail.com>
On 13/11/12 16:30, Alexander Khryukin wrote:
> Hello.
> I'm built rpm5 package but when i trying to run it i see
>
> [root at localhost rpm]# rpmbuild
> rpmbuild: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory
>
> Lib not exist in filesystem but exit into
>
>
> find . -name *gomp*
> ./output/host/usr/arm-buildroot-linux-gnueabi/sysroot/lib/libgomp.spec
> ./output/host/usr/arm-buildroot-linux-gnueabi/sysroot/lib/libgomp.so.1.0.0
> ./output/host/usr/arm-buildroot-linux-gnueabi/sysroot/lib/libgomp.so
> ./output/host/usr/arm-buildroot-linux-gnueabi/sysroot/lib/libgomp.a
> ./output/host/usr/arm-buildroot-linux-gnueabi/sysroot/lib/libgomp.la <http://libgomp.la>
> ./output/host/usr/arm-buildroot-linux-gnueabi/sysroot/lib/libgomp.so.1
>
>
> It's a bug or feature?
Yep, that's a bug. It's surprising that nobody has run into this before - maybe
OpenMP support was only recently added to the Linaro toolchain.
Alexander, you are using a recent external Linaro toolchain, right?
Thomas, I think this should be fixed by adding libgomp to LIB_EXTERNAL_LIBS
in ext-tool.mk. Is that right? Will that also work if libgomp doesn't exist?
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] [Bug 5678] New: linux.mk: linux-menuconfig fails
From: bugzilla at busybox.net @ 2012-11-13 15:43 UTC (permalink / raw)
To: buildroot
https://bugs.busybox.net/show_bug.cgi?id=5678
Summary: linux.mk: linux-menuconfig fails
Product: buildroot
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: trivial
Priority: P5
Component: Other
AssignedTo: unassigned at buildroot.uclibc.org
ReportedBy: matzeton at googlemail.com
CC: buildroot at uclibc.org
Estimated Hours: 0.0
make linux-menuconfig fails after make clean if using c cache
This was caused by the missing dep hostcc.
--
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] libgomp.so.1.0.0 not in target image
From: Alexander Khryukin @ 2012-11-13 15:30 UTC (permalink / raw)
To: buildroot
Hello.
I'm built rpm5 package but when i trying to run it i see
[root at localhost rpm]# rpmbuild
rpmbuild: error while loading shared libraries: libgomp.so.1: cannot open
shared object file: No such file or directory
Lib not exist in filesystem but exit into
find . -name *gomp*
./output/host/usr/arm-buildroot-linux-gnueabi/sysroot/lib/libgomp.spec
./output/host/usr/arm-buildroot-linux-gnueabi/sysroot/lib/libgomp.so.1.0.0
./output/host/usr/arm-buildroot-linux-gnueabi/sysroot/lib/libgomp.so
./output/host/usr/arm-buildroot-linux-gnueabi/sysroot/lib/libgomp.a
./output/host/usr/arm-buildroot-linux-gnueabi/sysroot/lib/libgomp.la
./output/host/usr/arm-buildroot-linux-gnueabi/sysroot/lib/libgomp.so.1
It's a bug or feature?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121113/8f056b91/attachment.html>
^ 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