* [Buildroot] Problem building libglib2
From: Thomas Petazzoni @ 2012-11-29 18:08 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201211300652.45293.manningc2@actrix.gen.nz>
Dear Charles Manning,
On Fri, 30 Nov 2012 06:52:44 +1300, Charles Manning wrote:
> > Maybe there's something fishy in your environment. Can you run
> > env | grep /lib
>
> Aaaarrrrggghhhh!!!!
>
> I have this system set up to automatically set up for openembedded.
> That defines PKG_CONFIG_PATH and adds some stuff to PATH which is probably
> messing things up.
>
> I turned off the openembedded auto configuration, nuked output/ and make ran
> to completion.
>
> I have now also learned a lot more about digging around in buildroot.
Wait, wait, could you please reproduce the problem, and reply to
Arnout's questions (sending us the output of env | grep /lib, or even
the entire output of env if it doesn't contain any sensitive
information).
I would like to this which environment variable was causing the
problem, and if we can add a check in Buildroot for this environment
variable, in order to avoid similar issues in the future.
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] Problem building libglib2
From: Charles Manning @ 2012-11-29 17:52 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50B72AAB.2020402@mind.be>
On Thursday 29 November 2012 22:28:11 Arnout Vandecappelle wrote:
> On 28/11/12 23:21, Charles Manning wrote:
> > On Thursday 29 November 2012 10:59:04 Arnout Vandecappelle wrote:
>
> [snip]
>
> >> Could you (and Alex):
> >> - tell us which host environment you have;
> >> - re-run the failed build with 'V=1 make libglib2' and
> >> post the failed command (should be something starting with:
> >> /bin/sh ../../libtool --tag=CC --mode=link ...)
> >> - post output/build/libglib2-2.30.3/config.log
> >> - post output/build/libglib2-2.30.3/gobject/Makefile
> >>
> >>
> >> I vaguely remember having seen this problem before, but can't
> >> remember if and how I solved it :-(
> >
> > Thanks for the help so far...
> >
> > I get this problem on my main work PC which is running Ubuntu 10.10 x32.
> > It works OK on a machine with Ubuntu 10.04 x64.
>
> So the link command ran by libtool is:
>
> /opt/buildroot/buildroot/output/host/usr/bin/arm-none-linux-gnueabi-gcc
> -shared -fPIC -DPIC .libs/libgobject_2_0_la-gatomicarray.o
> .libs/libgobject_2_0_la-gbinding.o .libs/libgobject_2_0_la-gboxed.o
> .libs/libgobject_2_0_la-gclosure.o .libs/libgobject_2_0_la-genums.o
> .libs/libgobject_2_0_la-gmarshal.o .libs/libgobject_2_0_la-gobject.o
> .libs/libgobject_2_0_la-gparam.o .libs/libgobject_2_0_la-gparamspecs.o
> .libs/libgobject_2_0_la-gsignal.o .libs/libgobject_2_0_la-gsourceclosure.o
> .libs/libgobject_2_0_la-gtype.o .libs/libgobject_2_0_la-gtypemodule.o
> .libs/libgobject_2_0_la-gtypeplugin.o .libs/libgobject_2_0_la-gvalue.o
> .libs/libgobject_2_0_la-gvaluearray.o
> .libs/libgobject_2_0_la-gvaluetransform.o
> .libs/libgobject_2_0_la-gvaluetypes.o -Wl,-rpath
> -Wl,/opt/buildroot/buildroot/output/build/libglib2-2.30.3/glib/.libs
> -Wl,-rpath
> -Wl,/opt/buildroot/buildroot/output/build/libglib2-2.30.3/gthread/.libs
> -L/opt/buildroot/buildroot/output/build/libglib2-2.30.3/glib/.libs
> ../glib/.libs/libglib-2.0.so ../ gthread/.libs/libgthread-2.0.so -lpthread
> /opt/buildroot/buildroot/output/build/libglib2-2.30.3/glib/.libs/libglib-2.
>0.so -lrt -L/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib -lffi
> -Os -Wl,-Bsymbolic-functions -Wl,-soname -Wl,libgobject-2.0.so.0
> -Wl,-version-script -Wl,.libs/libgobject-2.0.ver -o
> .libs/libgobject-2.0.so.0.3000.3
>
> (Just to be sure, could you go to the gobject directory and run the
> above command to verify that it fails in the same way? And also add the
> -v option to it, so we can see how exactly gcc calls ld.)
>
> There are two strange things with this:
>
> 1. There is no mention at all of /lib or /usr/lib so why is ld looking
> for pthread in those paths?
>
> 2. libtool adds
> -L/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib -- where does
> that come from?
>
> Maybe there's something fishy in your environment. Can you run
> env | grep /lib
Aaaarrrrggghhhh!!!!
I have this system set up to automatically set up for openembedded.
That defines PKG_CONFIG_PATH and adds some stuff to PATH which is probably
messing things up.
I turned off the openembedded auto configuration, nuked output/ and make ran
to completion.
I have now also learned a lot more about digging around in buildroot.
Thanks.
Charles
^ permalink raw reply
* [Buildroot] [PATCH 1/1] strace: remove undef-CTL_PROC patch
From: James Hogan @ 2012-11-29 17:11 UTC (permalink / raw)
To: buildroot
This patch is no longer necessary since strace-v4.5.15 which always
defines CTL_PROC. Specifically strace git commit
35a55785ea8ff44d214af52085e3a5ea624730aa.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
---
package/strace/strace-undef-CTL_PROC.patch | 12 ------------
1 files changed, 0 insertions(+), 12 deletions(-)
delete mode 100644 package/strace/strace-undef-CTL_PROC.patch
diff --git a/package/strace/strace-undef-CTL_PROC.patch b/package/strace/strace-undef-CTL_PROC.patch
deleted file mode 100644
index d841999..0000000
--- a/package/strace/strace-undef-CTL_PROC.patch
+++ /dev/null
@@ -1,12 +0,0 @@
---- a/system.c
-+++ b/system.c
-@@ -1614,7 +1614,9 @@ static const struct xlat sysctl_root[] =
- { CTL_KERN, "CTL_KERN" },
- { CTL_VM, "CTL_VM" },
- { CTL_NET, "CTL_NET" },
-+#ifdef CTL_PROC
- { CTL_PROC, "CTL_PROC" },
-+#endif
- { CTL_FS, "CTL_FS" },
- { CTL_DEBUG, "CTL_DEBUG" },
- { CTL_DEV, "CTL_DEV" },
--
1.7.7.6
^ permalink raw reply related
* [Buildroot] Buildroot for avr32
From: Thiago A. Corrêa @ 2012-11-29 16:10 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAHt8ZCO6Be2V+qPZ6Lu5y8kMaKipt2J=JgbbU7ZHqRXSF0c=tg@mail.gmail.com>
On Thu, Nov 29, 2012 at 2:05 PM, Simon Dawson <spdawson@gmail.com> wrote:
> Hi Thomas,
>
> On 29 Nov 2012 15:29, "Thomas Petazzoni"
> <thomas.petazzoni@free-electrons.com> wrote:
>> Do you know what is the status of AVR32 support in upstream gcc,
>> binutils and gdb?
>
> No, I don't. I suspect Atmel have all but stopped attempting to upstream
> patches for the architecture, but that is pure conjecture.
>
I have bugged them in support ticket and even in public forum which
they keep in avrfreaks.net before the EOL announcement.
The answer was that they would after finishing porting their patches
to gcc 3.4.x, but I guess they never did.
^ permalink raw reply
* [Buildroot] Buildroot for avr32
From: Simon Dawson @ 2012-11-29 16:05 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129162848.5a761c63@skate>
Hi Thomas,
On 29 Nov 2012 15:29, "Thomas Petazzoni" <
thomas.petazzoni@free-electrons.com> wrote:
> Do you know what is the status of AVR32 support in upstream gcc,
> binutils and gdb?
No, I don't. I suspect Atmel have all but stopped attempting to upstream
patches for the architecture, but that is pure conjecture.
Simon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121129/5020c7ae/attachment.html>
^ permalink raw reply
* [Buildroot] Buildroot for avr32
From: Thomas Petazzoni @ 2012-11-29 15:28 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAHt8ZCN5eB8shsxz+gVz6neYbwVC7kE-O=cT66MCTRQNq6o_qQ@mail.gmail.com>
Simon,
On Thu, 29 Nov 2012 11:35:18 +0000, Simon Dawson wrote:
> I'd be very interested in helping with the migration to uClibc 0.9.33.
Do you know what is the status of AVR32 support in upstream gcc,
binutils and gdb?
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] Buildroot for avr32
From: Thomas Petazzoni @ 2012-11-29 15:19 UTC (permalink / raw)
To: buildroot
In-Reply-To: <memo.20121129145816.4232J@postmaster+dexdyne.com.cix.co.uk>
Dear David Collier,
On Thu, 29 Nov 2012 14:58 +0000 (GMT Standard Time), David Collier
> So one interesting question is - does std buildroot include OpenVPN, and
> if so what revision :-)
Sure, we have OpenVPN 2.2.2.
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 03/51] package/dtc: add option to install programs
From: Arnout Vandecappelle @ 2012-11-29 15:00 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354146890-27380-4-git-send-email-yann.morin.1998@free.fr>
On 29/11/12 00:54, Yann E. MORIN wrote:
> By default, we only install the libfdt library.
>
> As suggested by Arnout, add an option that also
> installs the few dtc programs.
>
> Cc: Arnout Vandecappelle<arnout@mind.be>
> Signed-off-by: "Yann E. MORIN"<yann.morin.1998@free.fr>
[snip]
> +# libfdt_install is our own install rule added by our patch
> +DTC_BUILD_RULE=$(if $(BR2_PACKAGE_DTC_BINARY),,libfdt)
> +DTC_INSTALL_RULE=$(if $(BR2_PACKAGE_DTC_BINARY),install,libfdt_install)
> +
I (and I think Peter as well) prefer the more verbose
ifeq ($(BR2_PACKAGE_DTC_BINARY),y)
DTC_INSTALL_RULE = install
else
DTC_BUILD_RULE = libfdt
DTC_INSTALL_RULE = libfdt_install
endif
I would also call it _TARGET instead of _RULE.
> define DTC_BUILD_CMDS
> $(TARGET_CONFIGURE_OPTS) \
> CFLAGS="$(TARGET_CFLAGS)" \
> - $(MAKE) -C $(@D) PREFIX=/usr libfdt
> + $(MAKE) -C $(@D) PREFIX=/usr $(DTC_BUILD_RULE)
> endef
>
> -# libfdt_install is our own install rule added by our patch
> +# For staging, only the library is needed
> define DTC_INSTALL_STAGING_CMDS
> $(MAKE) -C $(@D) DESTDIR=$(STAGING_DIR) PREFIX=/usr libfdt_install
> endef
>
> define DTC_INSTALL_TARGET_CMDS
> - $(MAKE) -C $(@D) DESTDIR=$(TARGET_DIR) PREFIX=/usr libfdt_install
> + $(MAKE) -C $(@D) DESTDIR=$(TARGET_DIR) PREFIX=/usr $(DTC_INSTALL_RULE)
> endef
I would prefer the same rule for staging and target install:
- it doesn't hurt to have the executable in staging;
- it's easier to read if it's the same;
- when we finally get around to creating $(make-package), the default install
commands will be
$(MAKE) -C $(@D) DESTDIR=... $($(PKG)_INSTALL_TARGET)
(where _INSTALL_TARGET is the same for target and staging and defaults to
'install')
Regards,
Arnout
>
> define DTC_CLEAN_CMDS
--
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] Buildroot for avr32
From: David Collier @ 2012-11-29 14:58 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAEYzJUFwwAQnBu3opGyLKkpmc98FJL-rfvndtuPns4rATx8A7w@mail.gmail.com>
In article
<CAEYzJUFwwAQnBu3opGyLKkpmc98FJL-rfvndtuPns4rATx8A7w@mail.gmail.com>,
bjorn.forsman at gmail.com (Bj?rn Forsman) wrote:
> I'm not sure what Atmel put in their Buildroot fork, but we've been
> using
> mainline buildroot 2010.08 for one of our AVR32 projects.
I'm not sure what Atmel put in their Buildroot fork, but we've been using
mainline buildroot 2010.08 for one of our AVR32 projects.
yes indeed. That's what's in their buildroot.
I was provoked into this by the fact that on another board I have openVPN
2.1_rc11 , whereas the one on my AVR32 board is 2.0.9
One insists on a particular line in the config file before running user
scripts, and the other won't tolerate it.
So I was hoping to upgrade to a more recent openVPN - and hoping it would
come in a more recent buildroot.
So one interesting question is - does std buildroot include OpenVPN, and
if so what revision :-)
D
^ permalink raw reply
* [Buildroot] Buildroot for avr32
From: Thiago A. Corrêa @ 2012-11-29 13:53 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAHt8ZCN5eB8shsxz+gVz6neYbwVC7kE-O=cT66MCTRQNq6o_qQ@mail.gmail.com>
Hi,
On Thu, Nov 29, 2012 at 9:35 AM, Simon Dawson <spdawson@gmail.com> wrote:
>
> I'm using mainline Buildroot for a custom board that is based on the
> Atmel NGW100 board, with an ap7000 processor. I haven't had any major
> problems; I've had to patch the 3.6.x mainline kernel to get the board
> to boot from SD card --- I'm not using any Atmel kernel patches.
>
Same here. I think our u-boot is from atmel, the rest is mainline,
including buildroot. Haven't tried any new buildroot releases thou. We
have moved to ARM but we still have several AVR32's in the field.
Kind Regards,
Thiago A. Correa
^ permalink raw reply
* [Buildroot] Buildroot and ClassPath
From: Thomas Petazzoni @ 2012-11-29 13:10 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50B721D7.4050607@univ-rouen.fr>
Dear Alain Mouflet,
First of all, please don't use an existing message of the list when
starting a new thread: you break discussion threads.
On Thu, 29 Nov 2012 09:50:31 +0100, Alain Mouflet wrote:
> I'm trying to add classPath and Jamvm to build root.
> I've got the fixjava.patch of D.Smyth then I can compile jamvm but... on
> my rootfs, I haven't the /usr/share/classpath/ directory...
We used to have packages for jamvm and classpath in Buildroot, but
nobody was maintaining/updating them, so we removed them. You can still
find them in the Git history of the project, though.
Regarding your specific problem, it's impossible to help you: you don't
even give the modifications you've made to Buildroot, nor your
Buildroot configuration. There's no way we can help you if you don't
provide all the details needed for us to reproduce the situation you're
seeing.
See http://www.catb.org/esr/faqs/smart-questions.html#beprecise
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH] libroxml: bump version to 2.2.1
From: Arnout Vandecappelle @ 2012-11-29 12:58 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354169996-22703-1-git-send-email-blunderer@blunderer.org>
On 29/11/12 07:19, blunderer at blunderer.org wrote:
> From: Tristan Lelong<tristan.lelong@blunderer.org>
>
> Signed-off-by: Tristan Lelong<tristan.lelong@blunderer.org>
> ---
> package/libroxml/libroxml-2.2.0-werror.patch | 22 ----------------------
> package/libroxml/libroxml-2.2.1-werror.patch | 22 ++++++++++++++++++++++
Please send patches with the -M option to git send-email (or format-patch).
That will detect that this is just a rename.
Please also rename it to libroxml-werror.patch, i.e. removing the version
number. Nowadays, the policy is to make patches without version number,
unless a package supports several versions.
Regards,
Arnout
> package/libroxml/libroxml.mk | 2 +-
> 3 files changed, 23 insertions(+), 23 deletions(-)
> delete mode 100644 package/libroxml/libroxml-2.2.0-werror.patch
> create mode 100644 package/libroxml/libroxml-2.2.1-werror.patch
[snip]
--
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 18/33] linux-fusion: bump to version 8.10.4
From: Simon Dawson @ 2012-11-29 12:38 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353543503-8952-19-git-send-email-s.martin49@gmail.com>
On 22 November 2012 00:18, Samuel Martin <s.martin49@gmail.com> wrote:
> Also fix directfb build avoiding the following error to occur
> (since FCEF_FOLLOW has been added in linux-fusion-8.9.0):
>
> libtool: compile: /opt/br/output/host/usr/bin/ccache /opt/br/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../lib -I../../include -I../../lib -DDATADIR=\"/usr/share/directfb-1.4.17\" -DMODULEDIR=\"/usr/lib/directfb-1.4-6\" -D_REENTRANT -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -ffast-math -pipe -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Os -g2 -g3 -fno-inline -Wno-inline -D_GNU_SOURCE -finstrument-functions -std=gnu99 -Werror-implicit-function-declaration -MT call.lo -MD -MP -MF .deps/call.Tpo -c call.c -fPIC -DPIC -o .libs/call.o
> call.c: In function 'fusion_call_execute3':
> call.c:311:66: error 'FCEF_FOLLOW' undeclared (first use in this function)
> call.c:311:66: note: each undeclared identifier is reported only once for each function it appears in
> call.c: In function 'fusion_world_flush_calls':
> call.c:444:54: error 'FCEF_FOLLOW' undeclared (first use in this function)
> make[5]: *** [call.lo] Error 1
> make[5]: Leaving directory `/opt/br/output/build/directfb-1.4.17/lib/fusion'
>
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
> package/linux-fusion/linux-fusion.mk | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Simon Dawson <spdawson@gmail.com>
Tested-by: Simon Dawson <spdawson@gmail.com>
(built-test on a minimal arm config)
^ permalink raw reply
* [Buildroot] [PATCH 09/33] linux-fusion: fix build
From: Simon Dawson @ 2012-11-29 12:38 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353543503-8952-10-git-send-email-s.martin49@gmail.com>
On 22 November 2012 00:17, Samuel Martin <s.martin49@gmail.com> wrote:
>
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
> .../linux-fusion/linux-fusion-fix-include.patch | 52 ++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
> create mode 100644 package/linux-fusion/linux-fusion-fix-include.patch
>
Acked-by: Simon Dawson <spdawson@gmail.com>
Tested-by: Simon Dawson <spdawson@gmail.com>
(built-test on a minimal arm config)
^ permalink raw reply
* [Buildroot] Buildroot for avr32
From: Simon Dawson @ 2012-11-29 11:35 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129113710.63d5676c@skate>
Hi David, Thomas.
On Thu, 29 Nov 2012 10:20 +0000 (GMT Standard Time), David Collier
> So the question is - should I be able to use "standard buildroot" with an
> AVR32 - or was Atmel adding some magic of their own that has not been
> back-ported to the main trunk?
On 29 November 2012 10:37, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Normally, we have a working AVR32 setup, with certainly old versions of
> uClibc, binutils and gdb. I was told by AVR32 people that upgrading to
> uClibc 0.9.33 should work, but there are a few missing system calls in
> the AVR32 upstream kernel. If you are interested, we can look at this
> together, as I lack AVR32 hardware to dive into this.
I'm using mainline Buildroot for a custom board that is based on the
Atmel NGW100 board, with an ap7000 processor. I haven't had any major
problems; I've had to patch the 3.6.x mainline kernel to get the board
to boot from SD card --- I'm not using any Atmel kernel patches.
I'd be very interested in helping with the migration to uClibc 0.9.33.
Simon.
^ permalink raw reply
* [Buildroot] Buildroot for avr32
From: Bjørn Forsman @ 2012-11-29 11:26 UTC (permalink / raw)
To: buildroot
In-Reply-To: <memo.20121129102031.4232H@postmaster+dexdyne.com.cix.co.uk>
On 29 November 2012 11:20, David Collier <from_buildroot@dexdyne.com> wrote:
> Hi - we have a design based on the AVR32.
>
> Historically Atmel provided a "special-buildroot-for-AVR32". Trouble is
> their only AVR32 that ran Linux is now end-of-life, and I'm not sure they
> have any interest.
>
> The last version of it I can find is based on a buildroot that is 2 years
> out of date.
>
> So the question is - should I be able to use "standard buildroot" with an
> AVR32 - or was Atmel adding some magic of their own that has not been
> back-ported to the main trunk?
>
I'm not sure what Atmel put in their Buildroot fork, but we've been using
mainline buildroot 2010.08 for one of our AVR32 projects. The only thing
needed to make that version build (I think) is to apply this commit:
http://git.buildroot.net/buildroot/commit/?id=96652637ccfd94442224019c54341bf86094366a
But right now I'm actually in the process of switching that project over to
using an ARM device ;-)
Best regards,
Bj?rn Forsman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121129/d749267f/attachment-0001.html>
^ permalink raw reply
* [Buildroot] Buildroot for avr32
From: Thomas Petazzoni @ 2012-11-29 10:37 UTC (permalink / raw)
To: buildroot
In-Reply-To: <memo.20121129102031.4232H@postmaster+dexdyne.com.cix.co.uk>
Dear David Collier,
On Thu, 29 Nov 2012 10:20 +0000 (GMT Standard Time), David Collier
wrote:
> Hi - we have a design based on the AVR32.
Aaah great!
> Historically Atmel provided a "special-buildroot-for-AVR32". Trouble is
> their only AVR32 that ran Linux is now end-of-life, and I'm not sure they
> have any interest.
>
> The last version of it I can find is based on a buildroot that is 2 years
> out of date.
>
> So the question is - should I be able to use "standard buildroot" with an
> AVR32 - or was Atmel adding some magic of their own that has not been
> back-ported to the main trunk?
Good to see someone using AVR32. We've been wondering what to do with
our AVR32 support, because not many people have been using it.
Normally, we have a working AVR32 setup, with certainly old versions of
uClibc, binutils and gdb. I was told by AVR32 people that upgrading to
uClibc 0.9.33 should work, but there are a few missing system calls in
the AVR32 upstream kernel. If you are interested, we can look at this
together, as I lack AVR32 hardware to dive into this.
So, I would definitely be interested if you could try out the mainline
Buildroot, and report what the problems are (if any), and we'll see how
to move from here.
Of course, if you are aware of the availability for AVR32 of a more
recent gcc than the 4.2.x we're using and a more recent binutils than
the 2.18 we're using, we're interested as well.
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] Buildroot for avr32
From: David Collier @ 2012-11-29 10:20 UTC (permalink / raw)
To: buildroot
Hi - we have a design based on the AVR32.
Historically Atmel provided a "special-buildroot-for-AVR32". Trouble is
their only AVR32 that ran Linux is now end-of-life, and I'm not sure they
have any interest.
The last version of it I can find is based on a buildroot that is 2 years
out of date.
So the question is - should I be able to use "standard buildroot" with an
AVR32 - or was Atmel adding some magic of their own that has not been
back-ported to the main trunk?
TVM
David
^ permalink raw reply
* [Buildroot] Problem building libglib2
From: Arnout Vandecappelle @ 2012-11-29 9:28 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201211291121.46456.manningc2@actrix.gen.nz>
On 28/11/12 23:21, Charles Manning wrote:
> On Thursday 29 November 2012 10:59:04 Arnout Vandecappelle wrote:
[snip]
>> Could you (and Alex):
>> - tell us which host environment you have;
>> - re-run the failed build with 'V=1 make libglib2' and
>> post the failed command (should be something starting with:
>> /bin/sh ../../libtool --tag=CC --mode=link ...)
>> - post output/build/libglib2-2.30.3/config.log
>> - post output/build/libglib2-2.30.3/gobject/Makefile
>>
>>
>> I vaguely remember having seen this problem before, but can't remember
>> if and how I solved it :-(
>
> Thanks for the help so far...
>
> I get this problem on my main work PC which is running Ubuntu 10.10 x32. It
> works OK on a machine with Ubuntu 10.04 x64.
So the link command ran by libtool is:
/opt/buildroot/buildroot/output/host/usr/bin/arm-none-linux-gnueabi-gcc -shared -fPIC -DPIC
.libs/libgobject_2_0_la-gatomicarray.o .libs/libgobject_2_0_la-gbinding.o .libs/libgobject_2_0_la-gboxed.o
.libs/libgobject_2_0_la-gclosure.o .libs/libgobject_2_0_la-genums.o .libs/libgobject_2_0_la-gmarshal.o
.libs/libgobject_2_0_la-gobject.o .libs/libgobject_2_0_la-gparam.o .libs/libgobject_2_0_la-gparamspecs.o
.libs/libgobject_2_0_la-gsignal.o .libs/libgobject_2_0_la-gsourceclosure.o .libs/libgobject_2_0_la-gtype.o
.libs/libgobject_2_0_la-gtypemodule.o .libs/libgobject_2_0_la-gtypeplugin.o .libs/libgobject_2_0_la-gvalue.o
.libs/libgobject_2_0_la-gvaluearray.o .libs/libgobject_2_0_la-gvaluetransform.o .libs/libgobject_2_0_la-gvaluetypes.o
-Wl,-rpath -Wl,/opt/buildroot/buildroot/output/build/libglib2-2.30.3/glib/.libs -Wl,-rpath
-Wl,/opt/buildroot/buildroot/output/build/libglib2-2.30.3/gthread/.libs
-L/opt/buildroot/buildroot/output/build/libglib2-2.30.3/glib/.libs ../glib/.libs/libglib-2.0.so ../
gthread/.libs/libgthread-2.0.so -lpthread
/opt/buildroot/buildroot/output/build/libglib2-2.30.3/glib/.libs/libglib-2.0.so -lrt
-L/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib -lffi -Os -Wl,-Bsymbolic-functions -Wl,-soname
-Wl,libgobject-2.0.so.0 -Wl,-version-script -Wl,.libs/libgobject-2.0.ver -o .libs/libgobject-2.0.so.0.3000.3
(Just to be sure, could you go to the gobject directory and run the
above command to verify that it fails in the same way? And also add the
-v option to it, so we can see how exactly gcc calls ld.)
There are two strange things with this:
1. There is no mention at all of /lib or /usr/lib so why is ld looking
for pthread in those paths?
2. libtool adds -L/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib
-- where does that come from?
Maybe there's something fishy in your environment. Can you run
env | grep /lib
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] no /etc/hosts error in building root
From: Woody Wu @ 2012-11-29 8:52 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129093416.2cf28e51@skate>
On 2012-11-29, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>
wrote:
> Dear Woody Wu,
>
> On Thu, 29 Nov 2012 03:31:16 +0000 (UTC), Woody Wu wrote:
>
>> BTW: If I also want the root iamges under output/images directory to be
>> regenerated, is that enough to only remobe the output/target and run
>> 'make'? I tried something like 'make root-rebuild' and 'make
>> rootfs-rebuild' but they do not work.
>
> Just run "make". The images in output/images/ and re-generated from the
> contents of output/target at every make invocation.
>
> Thomas
This is a good news. Thanks.
--
woody
I can't go back to yesterday - because I was a different person then.
^ permalink raw reply
* [Buildroot] no /etc/hosts error in building root
From: Woody Wu @ 2012-11-29 8:51 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129093344.0d4c46a0@skate>
On 2012-11-29, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>
wrote:
> Dear Woody Wu,
>
> On Thu, 29 Nov 2012 03:31:16 +0000 (UTC), Woody Wu wrote:
>
>> I just removed the output/target directory and want to root filesystem
>> to be rebuilt by running 'make' again. But this time I got an error:
>
> This is not supported. You can't remove output/target and expect
> Buildroot to reinstall everything.
>
> Best regards,
>
> Thomas
Yes, I understood. After did that, I now already get a strange error
in building. Now I had already delete everything from the disck and
trying to rebuild from scratch.
Thanks.
--
woody
I can't go back to yesterday - because I was a different person then.
^ permalink raw reply
* [Buildroot] Buildroot and ClassPath
From: Alain Mouflet @ 2012-11-29 8:50 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129094247.03f7c7d2@skate>
Hello,
I'm trying to add classPath and Jamvm to build root.
I've got the fixjava.patch of D.Smyth then I can compile jamvm but... on
my rootfs, I haven't the /usr/share/classpath/ directory...
What's happens ?
Thank a lot,
Alain
^ permalink raw reply
* [Buildroot] [PATCH 06/51] package/usbredir: new package
From: Thomas Petazzoni @ 2012-11-29 8:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354146890-27380-7-git-send-email-yann.morin.1998@free.fr>
Dear Yann E. MORIN,
On Thu, 29 Nov 2012 00:54:05 +0100, Yann E. MORIN wrote:
> +comment "usbredir requires libusb"
> + depends on !BR2_PACKAGE_LIBUSB
Hum, why a "depends on" and not a "select", like we normally do for
libraries? libusb is not a "big" thing, so I'd say it should be
automatically selected.
> diff --git a/package/usbredir/usbredir.mk b/package/usbredir/usbredir.mk
> new file mode 100644
> index 0000000..9f6c011
> --- /dev/null
> +++ b/package/usbredir/usbredir.mk
> @@ -0,0 +1,31 @@
> +#############################################################
> +#
> +# usbredir
> +#
> +#############################################################
> +
> +USBREDIR_VERSION = 0.4.3
> +USBREDIR_SOURCE = usbredir-$(USBREDIR_VERSION).tar.bz2
> +USBREDIR_SITE = http://spice-space.org/download/usbredir
> +USBREDIR_LICENSE = LGPLv2.1+
Maybe:
USBREDIR_LICENSE = LGPLv2.1+ (library)
> +USBREDIR_LICENSE_FILES = COPYING.LIB
> +USBREDIR_INSTALL_STAGING = YES
> +USBREDIR_DEPENDENCIES = libusb
> +
> +USBREDIR_DEPENDENCIES += host-pkgconf
> +
> +ifeq ($(BR2_PACKAGE_USBREDIR_SERVER),y)
> +
> +USBREDIR_LICENSE += GPLv2+
USBREDIR_LICENSE += , GPLv2+ (server)
Or something equivalent, as per the conclusion of the Buildroot
Developer Days.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH 03/51] package/dtc: add option to install programs
From: Thomas Petazzoni @ 2012-11-29 8:40 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354146890-27380-4-git-send-email-yann.morin.1998@free.fr>
Dear Yann E. MORIN,
On Thu, 29 Nov 2012 00:54:02 +0100, Yann E. MORIN wrote:
> There is some (minor?) issues wrt the licensing terms.
> The libfdt library is dual-licensed GPLv2+/BSD-2c, and the
> executables are licensed GPLv2+.
>
> There is no way in BR to properly convey this information.
> So I decided to add some explanatory comments in the .mk
> file, in retaliation. ;-)
As per the discussion during the Developers Days, there is now a way to
convey this information. From the report:
multiple licenses: we don't want to make things very complex. It
doesn't have to be machine-readable (we don't need to support
machine analysis of the license field), so we don't have to
formally decide how the license text must be written. It does make
sense to have some convention, though. Proposal: "GPLv2+ or BSD-2c
for the library, GPLv2+ for the dtc executable".
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH 05/51] package/libiscsi: new package
From: Thomas Petazzoni @ 2012-11-29 8:39 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354146890-27380-6-git-send-email-yann.morin.1998@free.fr>
Dear Yann E. MORIN,
On Thu, 29 Nov 2012 00:54:04 +0100, Yann E. MORIN wrote:
> +LIBISCSI_AUTORECONF = YES
> +# Having a m4/ directory is mandatory for autoreconf to work
> +define LIBISCSI_CREATE_M4_DIR
> + mkdir -p $(@D)/m4
> +endef
> +LIBISCSI_PRE_CONFIGURE_HOOKS += LIBISCSI_CREATE_M4_DIR
I think the reason why AUTORECONF=YES is needed should be mention with
a comment on top of it. You don't have any patch touching
configure.{ac,in} or Makefile.am, so the need for AUTORECONF=YES
doesn't seem very obvious.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ 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