* [Buildroot] Problem building libglib2
From: Thomas Petazzoni @ 2012-11-29 23:11 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50B7C54C.3010103@mind.be>
Dear Arnout Vandecappelle,
On Thu, 29 Nov 2012 21:27:56 +0100, Arnout Vandecappelle wrote:
> We could obviously solve this by unexporting PKG_CONFIG_SYSROOT_DIR, but
> perhaps the better approach is to remove those environment variables from our
> custom pkgconf?
No, we use PKG_CONFIG_SYSROOT_DIR="/" when we build packages for the
host, so we can't simply remove support for the PKG_CONFIG_SYSROOT_DIR
environment variable. Unexporting PKG_CONFIG_SYSROOT_DIR sounds like
the good solution here.
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 1/1] strace: remove undef-CTL_PROC patch
From: Arnout Vandecappelle @ 2012-11-29 22:44 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354209118-12653-1-git-send-email-james.hogan@imgtec.com>
On 29/11/12 18:11, James Hogan wrote:
> 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>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
--
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 6/6] manual: add generated *-list.txt
From: Arnout Vandecappelle @ 2012-11-29 22:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354175268-6909-3-git-send-email-s.martin49@gmail.com>
On 29/11/12 08:47, Samuel Martin wrote:
> diff --git a/docs/manual/pkg-list.txt b/docs/manual/package-list.txt
> similarity index 99%
> rename from docs/manual/pkg-list.txt
> rename to docs/manual/package-list.txt
> index 5d9b54f..d06316f 100644
> --- a/docs/manual/pkg-list.txt
> +++ b/docs/manual/package-list.txt
> @@ -1,3 +1,12 @@
> +
> +//
> +// Autogenerated file
> +//
> +
> +[[package-list]]
> +Available packages
> +------------------
> +
> * acl
> * acpid
> * alsa-lib
> @@ -346,6 +355,7 @@
> * luaexpat
> * luafilesystem
> * luajit
> +* lua-msgpack-native
> * luasocket
> * lvm2
> * lzma
I love this! Now you can easily see what has changed between two versions.
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 3/6] manual: add deprecated-list.txt generation support
From: Arnout Vandecappelle @ 2012-11-29 22:41 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354175268-6909-2-git-send-email-s.martin49@gmail.com>
On 29/11/12 08:47, Samuel Martin wrote:
> The whole deprecated-list.txt file is generated by the deprecated.py
> script by searching for symbols depending on BR2_DEPRECATED in the
> Buildroot code base.
>
> Signed-off-by: Samuel Martin<s.martin49@gmail.com>
> ---
>
> Change since v1:
>
> * rename the script deprecated.py -> gen-deprecated-list.py (to keep consistency)
>
> ---
> docs/manual/manual.mk | 3 +
> support/scripts/gen-deprecated-list.py | 144 +++++++++++++++++++++++++++++++++
> 2 files changed, 147 insertions(+)
> create mode 100755 support/scripts/gen-deprecated-list.py
>
> diff --git a/docs/manual/manual.mk b/docs/manual/manual.mk
> index d8437ba..4cd5839 100644
> --- a/docs/manual/manual.mk
> +++ b/docs/manual/manual.mk
> @@ -27,6 +27,9 @@ endef
> $(TOPDIR)/docs/manual/package-list.txt:
> $(TOPDIR)/support/scripts/gen-manual-pkg-list.sh> $@
>
> +$(TOPDIR)/docs/manual/deprecated-list.txt:
> + python2 $(TOPDIR)/support/scripts/gen-deprecated-list.py> $@
We don't have python2 in dependencies.sh, and anyway some things
don't currently work if python is python3. So I'd just call the
script without the python2. Anyway, does it not work with python3?
> +
> ################################################################################
> # GENDOC -- generates the make targets needed to build asciidoc documentation.
> #
> diff --git a/support/scripts/gen-deprecated-list.py b/support/scripts/gen-deprecated-list.py
> new file mode 100755
> index 0000000..cd8c288
> --- /dev/null
> +++ b/support/scripts/gen-deprecated-list.py
> @@ -0,0 +1,144 @@
> +#!/usr/bin/env python
> +##
> +## deprecated-packages.py
> +##
> +## Author(s):
> +## - Samuel MARTIN<s.martin49@gmail.com>
> +##
> +## Copyright (C) 2012 Samuel MARTIN
> +##
> +
> +# Python 2.7 script searching for kconfig symbols depending on 'BR2_DEPRECATED'
> +# and generating (printing to the standard output) the manual file in asciidoc.
> +
> +import os
> +import re
> +import sys
> +
> +
> +ASCIIDOC_HEADER = """\
> +//
> +// Autogenerated file
> +//
> +
> +[[deprecated]]
> +Deprecated list
> +---------------
> +
> +The following stuff are marked as _deprecated_ in Buildroot due to
> +their status either too old or unmaintained.
Better:
The following packages are marked as _deprecated_ because they are
either too old or unmaintained in buildroot.
> +
> +// Please check and sort by grepping the source running:
> +//
> +// $ git grep -EB4 'depends on BR2_DEPRECATED'
> +//
> +// and:
> +//
> +// $ git grep -EB4 'depends on BR2_DEPRECATED' | \\
> +// grep -Eo '(:|-).*?(config|comment) BR2_.*'
This is redundant now. Instead, mention the make target
after 'Autogenerated'.
> +"""
> +
> +NOT_SEARCHED = (".git", "board", "configs", "docs", "output", "support")
> +
> +# Relative path to category data map
> +# key: relative path from buildroot topdir to the search location
> +# value: (rank_in_menuconfig, category_name, recursive_search)
> +# rank_in_menuconfig is used for ordering the diplaying
> +# category_name is used in the diplaying
> +# recursive_search when searching for deprecated stuff
> +CAT_DIR2DATA = {
> + 'arch' : (0, "target architecture", True),
> + '.' : (1, "build options", False),
> + 'toolchain' : (2, "toolchain", True),
> + 'system' : (3, "system configuration", True),
> + 'package' : (4, "package selection", True),
> + 'fs' : (5, "filesystem images", True),
> + 'boot' : (6, "bootloaders", True),
> + 'linux' : (7, "kernel", True),
> + }
> +
> +DEPR_SYMBOL = "BR2_DEPRECATED"
> +
> +_REGEX = r"config BR2_(.*?)\n" + \
> + "((.*?(?!config)(prompt|bool|string|int) \"(.*?)\".*?|[^\n]+)\n)*" + \
> + "(.*?(?!config )" + DEPR_SYMBOL + ".*?)\n" + \
> + "((.*?(?!config)(prompt|bool|string|int) \"(.*?)\".*?|[^\n]+)\n)*"
This regex warrants some documentation :-) perhaps with re.VERBOSE
Why is the !config needed in the prompt lines?
Is there a reason to use the non-greedy .*? (except between the quotes)?
I would also name the "interesting" parts with (?P<...>) and use finditer()
and m.group() to retrieve them. But that's a matter of taste, I guess.
> +
> +REGEX = re.compile(_REGEX, flags=re.MULTILINE)
> +
> +
> +def _get_buildroot_topdir():
> + topdir = os.path.join(os.path.dirname(__file__), "..", "..")
> + topdir = os.path.abspath(topdir)
> + return topdir
I would just use the current directory as topdir. All the rest of
buildroot anyway assumes it's being run from the topdir.
> +
> +def get_dir_list():
> + root = _get_buildroot_topdir()
> + dirs = ['.']
> + for dir_ in os.listdir(root):
> + if dir_ in NOT_SEARCHED:
> + continue
> + dir__ = os.path.join(root, dir_)
> + if not os.path.isdir(dir__):
> + continue
> + dirs += [dir_]
> + return dirs
> +
> +def find_deprecated(root, recursive):
> + deprecated = list()
> + for root_, _, files_ in os.walk(root):
> + if not recursive and root_ != root:
> + break
> + for file_ in files_:
> + if not file_.startswith("Config.in"):
> + continue
> + with open(os.path.join(root_, file_), "r") as f:
> + content = f.read()
> + if not DEPR_SYMBOL in content:
> + continue
> + found = REGEX.findall(content)
> + if found:
> + deprecated += found
> + return deprecated
It's quite a big change, but: why not use the source statements
in Config.in to do the recursion? The regex it easy enough:
r'^\s*source "(?<path>.*?)"$' This would be more future-safe:
when new directories are added, they will be handled correctly.
It would also be good if you could add a warning when
len(found) != len(re.findall(DEPR_SYMBOL, content))
> +
> +
> +class Category():
> +
> + def __init__(self, directory):
> + self.path = os.path.join(_get_buildroot_topdir(), directory)
> + rank, name, rec = CAT_DIR2DATA.get(directory, (99, directory, True))
> + self.name = name
> + self.rank = rank
You can directly do
self.rank, self.name, rec = CAT_DIR2DATA.get(directory, (99, directory, True))
> + self.depr_items = find_deprecated(self.path, rec)
> +
> + def __str__(self):
> + items_ = list()
> + for item in self.depr_items:
> + name_ = item[0].lower().replace("_", " ")
> + name_ = re.sub("^package ", "", name_)
> + vers = re.sub(".*?(version )?([0-9].*)", r'\2', name_)
> + if vers:
> + vers = re.sub(" ", ".", vers)
> + name_ = re.sub("(version )?([0-9].*)", vers, name_)
> + symbol = item[4]
> + if not symbol:
> + symbol = item[9]
> + items_ += ["** %-25s +[%s]+" % (name_, symbol)]
I don't think the name_ part adds much value. In most cases, symbol
is either the same or more descriptive. There are a few exceptions,
but these could be fixed by changing the Config.in. These need to be
modified: gcc target, squashfs3 rootfs, uboot 11.06 and 11.09.
BTW, symbol is not really symbol but rather 'description' or something
similar.
> + items_.sort()
> + output = "\n* %s:\n\n" % self.name.capitalize()
> + output += "\n".join(items_)
> + output += "\n"
> + return output
> +
> +def main():
> + categories = [Category(directory) for directory in get_dir_list()]
> + categories = [category for category in categories if category.depr_items]
> + categories.sort(cmp=lambda x, y: x.rank - y.rank if x.rank != y.rank \
> + else cmp(x.name, y.name))
categories.sort(key=lambda x: (x.rank, x.name))
> + output = ASCIIDOC_HEADER
> + for category in categories:
> + output += str(category)
> + print output
Don't concat the output, just print directly.
print ASCIIDOC_HEADER
for category in categories:
print category
Regards,
Arnout
> +
> +if __name__ == "__main__":
> + main()
--
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 2/6] manual: add package-list.txt generation support
From: Arnout Vandecappelle @ 2012-11-29 20:48 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1354175268-6909-1-git-send-email-s.martin49@gmail.com>
On 29/11/12 08:47, Samuel Martin wrote:
>
> Signed-off-by: Samuel Martin<s.martin49@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(untested)
But since I'm pedantic, I still have some comments :-)
[snip]
> diff --git a/support/scripts/gen-manual-pkg-list.sh b/support/scripts/gen-manual-pkg-list.sh
> new file mode 100755
> index 0000000..f11b4de
> --- /dev/null
> +++ b/support/scripts/gen-manual-pkg-list.sh
> @@ -0,0 +1,19 @@
> +#!/bin/sh
> +##
> +## gen-manual-pkg-list.sh
> +##
> +## Author(s):
> +## - Samuel MARTIN<s.martin49@gmail.com>
> +##
> +## Copyright (C) 2012 Samuel MARTIN
If you add a copyright statement, ideally you should also refer to the GPL:
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
(The fact that you put the Copyright statement there makes it look as if
it's proprietary. Adding the GPL reference disambiguates it. Of course,
it is implied by the global buildroot license even if you leave out the
GPL reference.)
> +##
> +
> +# Generate the manual package-list.txt content (in asciidoc format) and print it
> +# to the standard output.
> +
> +printf "\n//\n// Autogenerated file\n//\n\n"
> +printf "[[package-list]]\n"
> +printf "Available packages\n"
> +printf -- "------------------\n\n"
Since this is now part of a script, you can just cat a here document.
Much more readable.
> +grep -rlE --color=never '\((autotools|cmake|generic)-package\)' package | \
We globally unexport GREP_OPTIONS, so the --color=never is redundant.
In addition, it would barf on non-gnu-grep.
Regards,
Arnout
> + sed -ne '/.*\/\(.*\).mk$/ s//* \1/p' | sort
--
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] Problem building libglib2
From: Arnout Vandecappelle @ 2012-11-29 20:27 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201211300731.53056.manningc2@actrix.gen.nz>
On 29/11/12 19:31, Charles Manning wrote:
> export
> PKG_CONFIG_SYSROOT_DIR=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi
That's the one.
Charles, could you verify by setting this variable and rebuilding libglib2:
PKG_CONFIG_SYSROOT_DIR=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi \
make libglib2-dirclean libglib2
All,
We could obviously solve this by unexporting PKG_CONFIG_SYSROOT_DIR, but
perhaps the better approach is to remove those environment variables from our
custom pkgconf?
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] Buildroot for avr32
From: Thiago A. Corrêa @ 2012-11-29 18:48 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129193123.503b489b@skate>
On Thu, Nov 29, 2012 at 4:31 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> Ok, so your suggestion is to just maintain the AVR32 support in
> Buildroot as is, and not spend time improving it. Is that correct?
>
Actually I was trying not to suggest that, while trying to inform of
my past experience that might help somehow. I had edited the message a
few times before sending :)
Clearly there are still users, I don't feel it's right by them for me
to suggest that, but I don't know what the policy will be on this
case. I mean, gcc patches probably will not be accepted mainstream,
and I have a hard time believing someone will put in the effort after
Atmel droped the ball. It's also not realistic to expect buildroot, qt
or the kernel to carry that support indefinetly.
So, I guess what I'm saying is: I'm sure we would all appreciate if
the support can be improved, but if it's not possible, at least kept
for a while.
Althought you haven't said it, I believe you wish to drop the old gcc
options, and the avr32 toolchain is in the way.
^ permalink raw reply
* [Buildroot] Problem building libglib2
From: Charles Manning @ 2012-11-29 18:31 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129190813.5dc97298@skate>
On Friday 30 November 2012 07:08:13 Thomas Petazzoni wrote:
> 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.
>
The problem was cause by running the openembedded toolchain env setup script
shown below and attached incase it gets too badly messed up by mail.
export PATH=/usr/local/angstrom/arm/bin:$PATH
export LIBTOOL_SYSROOT_PATH=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi
export
PKG_CONFIG_SYSROOT_DIR=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi
export
PKG_CONFIG_PATH=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib/pkgconfig
export QTDIR=/usr/local/angstrom/arm
export CONFIG_SITE=/usr/local/angstrom/arm/site-config
alias
opkg='LD_LIBRARY_PATH=/usr/local/angstrom/arm/lib /usr/local/angstrom/arm/bin/opkg-cl -f /usr/local/angstrom/arm/etc/opkg-sdk.conf -o /usr/local/angstrom/arm'
alias
opkg-target='LD_LIBRARY_PATH=/usr/local/angstrom/arm/lib /usr/local/angstrom/arm/bin/opkg-cl -f /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/etc/opkg.conf -o /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi'
I had added the following line to bashrc:
. /path/environment-setup
that caused it to always be added.
I see the Makefile has a line
unexport PKG_CONFIG_PATH
perhaps that should be
unset PKG_CONFIG_PATH
Is that enough info?
Sorry I have to go to the day job now, so if you want more I will have to work
on that later.
Thanks for your efforts!
-- CHarles
-------------- next part --------------
export PATH=/usr/local/angstrom/arm/bin:$PATH
export LIBTOOL_SYSROOT_PATH=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi
export PKG_CONFIG_SYSROOT_DIR=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi
export PKG_CONFIG_PATH=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib/pkgconfig
export QTDIR=/usr/local/angstrom/arm
export CONFIG_SITE=/usr/local/angstrom/arm/site-config
alias opkg='LD_LIBRARY_PATH=/usr/local/angstrom/arm/lib /usr/local/angstrom/arm/bin/opkg-cl -f /usr/local/angstrom/arm/etc/opkg-sdk.conf -o /usr/local/angstrom/arm'
alias opkg-target='LD_LIBRARY_PATH=/usr/local/angstrom/arm/lib /usr/local/angstrom/arm/bin/opkg-cl -f /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/etc/opkg.conf -o /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi'
^ permalink raw reply
* [Buildroot] Buildroot for avr32
From: Thomas Petazzoni @ 2012-11-29 18:31 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAExDhva8qpnukgyEAogo=cJhxZkdWaFU9ekPAujCgBtgMbaTOw@mail.gmail.com>
Dear Thiago A. Corr?a,
On Thu, 29 Nov 2012 16:25:23 -0200, Thiago A. Corr?a wrote:
> I'm talking from memory, because I haven't touched much of this for a while.
> Back then I tried patches from them and from Atmel, but complex
> software such as Qt had problems with them. They might have been
> updated since, but the most stable option was the current 4.2.2.
>
> I suspect that at some point the AVR32 support will be dropped, even
> from kernel.
Ok, so your suggestion is to just maintain the AVR32 support in
Buildroot as is, and not spend time improving it. Is that correct?
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: Thiago A. Corrêa @ 2012-11-29 18:25 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129190955.416f2373@skate>
Hi Thomas,
On Thu, Nov 29, 2012 at 4:09 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thiago A. Corr?a,
>
> On Thu, 29 Nov 2012 14:10:36 -0200, Thiago A. Corr?a wrote:
>
>> 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.
>
> OpenWRT has gcc 4.4.7 patches and binutils 2.21.1 patches. I've tried
> them, but unfortunately ld segfaults when linking uClibc. I'll do a
> quick investigation, but I don't think I want to invest too much time
> in this architecture...
>
I'm talking from memory, because I haven't touched much of this for a while.
Back then I tried patches from them and from Atmel, but complex
software such as Qt had problems with them. They might have been
updated since, but the most stable option was the current 4.2.2.
I suspect that at some point the AVR32 support will be dropped, even
from kernel.
^ permalink raw reply
* [Buildroot] Problem building libglib2
From: Arnout Vandecappelle @ 2012-11-29 18:22 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121129190813.5dc97298@skate>
On 29/11/12 19:08, Thomas Petazzoni wrote:
> 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.
After a second look in config.log:
pkg_cv_DBUS1_CFLAGS='-I/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include/dbus-1.0
-I/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib/dbus-1.0/include '
pkg_cv_DBUS1_LIBS='-L/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib -ldbus-1 -lpthread -lrt '
pkg_cv_LIBFFI_CFLAGS=' '
pkg_cv_LIBFFI_LIBS='-L/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib -lffi '
pkg_cv_ZLIB_CFLAGS='-I/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/include '
pkg_cv_ZLIB_LIBS='-L/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib -lz '
I really don't see how this can happen: we unexport PKG_CONFIG_PATH and set
PKG_CONFIG explicitly in the Makefile...
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] Buildroot for avr32
From: Thomas Petazzoni @ 2012-11-29 18:09 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAExDhvZUT2KpJfuxqg__y=PqpLYQsHXaSEa6s1Ni61UW6D4skQ@mail.gmail.com>
Dear Thiago A. Corr?a,
On Thu, 29 Nov 2012 14:10:36 -0200, Thiago A. Corr?a wrote:
> 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.
OpenWRT has gcc 4.4.7 patches and binutils 2.21.1 patches. I've tried
them, but unfortunately ld segfaults when linking uClibc. I'll do a
quick investigation, but I don't think I want to invest too much time
in this architecture...
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: 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
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