* [Buildroot] Who calls to the defined function/s
From: Arnout Vandecappelle @ 2012-11-21 6:39 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CACUGKYNs2gHvS_6eJS22gYgZOE7rhSciSaCAeCxbEm4q5Dm=Kw@mail.gmail.com>
On 20/11/12 19:26, John Tobias wrote:
> I was thinking to support the package
> management in the buildroot. Where, if I define XXX_CREATE_PACKAGE in
> my hello.mk
> the buildroot (for example) will create an opkg file (off-course I
> have supply the necessary information to create the package file).
>
> I know the buildroot community did not support it package management
> but I would like to add some flexibility on my buildroot environment.
Even though it's very likely that we will not include support for packages in
buildroot, it's worthwhile to post your patches to the list. That way, anybody
else that needs it can pick it up. In addition, you may get some review comments
which are useful for yourself.
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] How to regenerate zImage?
From: Woody Wu @ 2012-11-21 4:40 UTC (permalink / raw)
To: buildroot
In-Reply-To: <slrnkamq24.2u9.narkewoody@zuhnb712.local.com>
On 2012-11-20, Woody Wu
<narkewoody@gmail.com> wrote:
>> However, note that making changing to the source code anywhere in
>> output/build/... is a really stupid idea, as all those changes will
>> be lost next time you do 'make clean'.
>>
> Yes, I agree this is stupid. So I also really like to know whta's the
> best practice to do this kind of work. Would you be so kind to have a
> introduction or point me to a docment? Thanks
>
Hi, Thomas
Would you be so kind to draw a comment on this?
--
woody
I can't go back to yesterday - because I was a different person then.
^ permalink raw reply
* [Buildroot] [PATCH] cjson: fix copy/paste error in target installation
From: Danomi Manchego @ 2012-11-21 3:21 UTC (permalink / raw)
To: buildroot
Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
---
package/cjson/cjson.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/cjson/cjson.mk b/package/cjson/cjson.mk
index dd64010..ccc6010 100644
--- a/package/cjson/cjson.mk
+++ b/package/cjson/cjson.mk
@@ -23,7 +23,7 @@ define CJSON_INSTALL_STAGING_CMDS
endef
define CJSON_INSTALL_TARGET_CMDS
- $(INSTALL) -D $(@D)/cJSON/cJSON.h $(STAGING_DIR)/usr/include/cJSON.h
+ $(INSTALL) -D $(@D)/cJSON/cJSON.h $(TARGET_DIR)/usr/include/cJSON.h
$(INSTALL) -D $(@D)/cJSON/libcJSON.so $(TARGET_DIR)/usr/lib/libcJSON.so
endef
--
1.7.9.5
^ permalink raw reply related
* [Buildroot] Who calls to the defined function/s
From: John Tobias @ 2012-11-21 0:52 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CACUGKYMPEgomG3VJnNitxBr7Dtxed4XuPzMdVRH0rJi_iKB7DQ@mail.gmail.com>
Hi Thomas,
I found where to add the function.
Regards,
john
On Tue, Nov 20, 2012 at 3:00 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
> Hi Thomas,
>
> I added some function in generic-package (snapshot of added function):
>
> $(BUILD_DIR)/%/.stamp_create_package:
> @$(call MESSAGE,"Creating package")
> $(Q)touch $@
>
>
> In buildroot directory, when I issue a command:
>
> make hello-create-package, it calls the said function. But, since the
> new function didn't know by the buildroot, I cannot do the make hello
> then the buildroot will call the create-package.
>
> The question is what environment variable should I modify in order the
> buildroot should call the create-package too?
>
> Regards,
>
> john
>
> On Tue, Nov 20, 2012 at 10:26 AM, John Tobias <john.tobias.ph@gmail.com> wrote:
>> Dear Thomas Petazzoni,
>>
>> Thank you for the response. I was thinking to support the package
>> management in the buildroot. Where, if I define XXX_CREATE_PACKAGE in
>> my hello.mk
>> the buildroot (for example) will create an opkg file (off-course I
>> have supply the necessary information to create the package file).
>>
>> I know the buildroot community did not support it package management
>> but I would like to add some flexibility on my buildroot environment.
>>
>> Regards,
>>
>> john
>>
>> On Tue, Nov 20, 2012 at 12:59 AM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>>> Dear John Tobias,
>>>
>>> On Mon, 19 Nov 2012 18:21:03 -0800, John Tobias wrote:
>>>
>>>> I was trying to (fully) understand the dataflow of the buildroot's
>>>> Makefile. How/who parse/calls to the functions like:
>>>>
>>>> HELLO_INSTALL_TARGET_CMDS
>>>> HELLO_BUILD_CMDS
>>>>
>>>> $(eval $(generic-package))
>>>
>>> The generic-package macro will find in which directory your Makefile
>>> is, for example package/hello/. It will take this "hello" convert it to
>>> uppercase, and use it as the prefix for all variables. So basically, a
>>> package in package/hello/hello.mk will have to define HELLO_SITE,
>>> HELLO_SOURCE, HELLO_VERSION, and possibly HELLO_BUILD_CMDS,
>>> HELLO_INSTALL_TARGET_CMDS, etc.
>>>
>>>> So, How I can tell to the generic-package to call HELLO_TEST_CMDS too?
>>>>
>>>> example:
>>>> define HELLO_TEST_CMDS
>>>> ...
>>>> endef
>>>
>>> That would require a modification of the package infrastructure, which
>>> you probably don't want to do. What are you trying to achieve with a
>>> new command exactly?
>>>
>>> New commands are normally not needed:
>>>
>>> *) For autotools-package and cmake-package, you have hooks so that you
>>> can do something after extraction, after patching, after
>>> configuration, after installation, etc.
>>>
>>> *) For generic-package, you can do something like:
>>>
>>> ifeq ($(BR2_PACKAGE_HELLO_SOMETHING),y)
>>> define HELLO_DO_THIS_CMDS
>>> $(MAKE) -C $(@D) do-this
>>> endef
>>> endif
>>>
>>> ifeq ($(BR2_PACKAGE_HELLO_SOMETHING_ELSE),y)
>>> define HELLO_DO_THAT_CMDS
>>> $(MAKE) -C $(@D) do-that
>>> endef
>>> endif
>>>
>>> define HELLO_BUILD_CMDS
>>> $(HELLO_DO_THIS_CMDS)
>>> $(HELLO_DO_THAT_CMDS)
>>> endef
>>>
>>> Please make sure to read our documentation at
>>> http://buildroot.org/downloads/manual/manual.html#_adding_new_packages_to_buildroot
>>> which explains all of this with quite some details and examples.
>>>
>>> Do not hesitate to get back to the list if you need further details,
>>>
>>> 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] Xtensa in the autobuilders, first build failures
From: Chris Zankel @ 2012-11-21 0:35 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121119234601.6274d4a6@skate>
Hi Thomas,
On 11/19/2012 02:46 PM, Thomas Petazzoni wrote:
> On Mon, 19 Nov 2012 13:45:50 -0800, Chris Zankel wrote:
>
>> However, I noticed that it was not the most recent version where I
>> incorporated suggestions from Arnout, so will provide a small patch on
>> top of it.
> Ah, sorry, my bad. Don't hesitate to send a follow-up patch that fixes
> the remaining problems.
No worries, I think my email system wasn't working, so maybe you didn't
even get them.
I'm lining up a few patches, just running some more build tests (which
always take some time)
> Adding support for one architecture in libffi is not very simple, so if
> you don't need it for your own projects, I don't think you'll have the
> energy to work on this.
You are right, it looks like some work, and it would be lower priority.
I'll just disable it for Xtensa for now.
>>> Besides those issues, I'm just reminding you that we are still very
>>> interested in having a Qemu Xtensa configuration to be able to run the
>>> Xtensa systems we generate with Buildroot.
>> I'm juggling between kernel, uClibc, and buildroot, so, please allow me
>> some more time.
> Sure, no problem!
How do you actually build qemu inside buildroot, or is this not
supported? I couldn't find any config option to enable it.
Also note that the current kernel version (3.6) doesn't have all
required patches, we are 'forward-focusing' at the moment, so things
will be easier in the future.
>> Regarding patches, should I send them to you and cc buildroot, or only
>> to the mailing list? What's the best path to get them looked at and
>> integrated into the tree?
> Just send them to the list. You can Cc: me as well if you want, but I'm
> basically reading everything that goes on the Buildroot list, so I
> should catch them even if you don't Cc: me.
Thanks. I'll keep them coming :-)
Cheers!
-Chris
^ permalink raw reply
* [Buildroot] Udev on a live CD system does not appear to populate /dev
From: Stefan Fröberg @ 2012-11-20 23:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <50A940FA.7020402@petroprogram.com>
18.11.2012 22:11, Stefan Fr?berg kirjoitti:
> 18.11.2012 22:02, Arnout Vandecappelle kirjoitti:
>> On 17/11/12 23:54, Stefan Fr?berg wrote:
>> [snip]
>>> But the real problem now is that grub refuses to load. It just shows
>>> Loading stage2 .... and hangs there.
>>>
>>> If I copy my old grub stuff (namely, the stage2_eltorito file) from
>>> 2012.05 build to inside the boot/grub/ of the
>>> new buildroot generated livecd (of course, first mounted throught
>>> loopback and copied to some other dir for modifying)
>>> and then build the livecd from that manually, it will work and show
>>> grub menu normally.
>>>
>>> I did a quick *md5sum* and *ls* and there indeed is a difference with
>>> the git-version and 2012.05 version of
>>> stage2_eltorito file, git-version of stage2_eltorito being very
>>> large (258 KB vs. working 103 KB)
>>>
>> Is this on a x86_64 target? Then a difference is that we removed
>> -fPIC -DPIC from CFLAGS. Can you try if that makes a difference?
>>
> No, just building i586 target inside 32-bit Fedora 16 host.
>
> Ok, Im now going to rebuild both 2012.05 and latest git again and
> see what happens.
>
> Regards
> Stefan
>
>> Regards,
>> Arnout
>
I have now investigated this matter three days and found out the following:
1 )
That size difference (258 KB vs. working 103 KB) was because in
buildroot grub I had enabled every network NIC available.
But the following was shocking to me:
The working 103 KB stage2_eltorito was not from buildroot at all in the
first place but from Gentoo!
I vaguely remember copying it to buildroot system from my Gentoo setup
several months ago.
Because I found out that the livecd build process did not work.
But this also means that even 2012.05 buildroot grub did not work for me.
2 )
I built my own version of grub with my own uClibc-based distro and found
out that grub is very nit-pick about CFLAGS and LDFLAGS it is feed.
It doesn't like optimiziation very much.
So after unsetting both flags and applying four patches from Gentoo I
managed to run my very own made grub. Yay!! :-)
3 )
Naturally I then tried this CFLAGS and LDFLAGS unsetting in
boot/grub/grub.mk.
Also used only default buildroot configuration, with newest git.
The damn thing still didn't show grub menu! :-(
And now Im beginning to suspect that buildroot grub is very broken as it
is now and needs some serious patching.
The patches it uses (grub_0.97-35.diff.gz) are from old debian tree from
2008!!
I will now grab the latest debian patches (grub_0.97-66.diff.gz), use
only -Os for CFLAGS and nothing for LDFLAGS and see how far it will take me
this time.
Regards
Stefan
^ permalink raw reply
* [Buildroot] Who calls to the defined function/s
From: John Tobias @ 2012-11-20 23:00 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CACUGKYNs2gHvS_6eJS22gYgZOE7rhSciSaCAeCxbEm4q5Dm=Kw@mail.gmail.com>
Hi Thomas,
I added some function in generic-package (snapshot of added function):
$(BUILD_DIR)/%/.stamp_create_package:
@$(call MESSAGE,"Creating package")
$(Q)touch $@
In buildroot directory, when I issue a command:
make hello-create-package, it calls the said function. But, since the
new function didn't know by the buildroot, I cannot do the make hello
then the buildroot will call the create-package.
The question is what environment variable should I modify in order the
buildroot should call the create-package too?
Regards,
john
On Tue, Nov 20, 2012 at 10:26 AM, John Tobias <john.tobias.ph@gmail.com> wrote:
> Dear Thomas Petazzoni,
>
> Thank you for the response. I was thinking to support the package
> management in the buildroot. Where, if I define XXX_CREATE_PACKAGE in
> my hello.mk
> the buildroot (for example) will create an opkg file (off-course I
> have supply the necessary information to create the package file).
>
> I know the buildroot community did not support it package management
> but I would like to add some flexibility on my buildroot environment.
>
> Regards,
>
> john
>
> On Tue, Nov 20, 2012 at 12:59 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Dear John Tobias,
>>
>> On Mon, 19 Nov 2012 18:21:03 -0800, John Tobias wrote:
>>
>>> I was trying to (fully) understand the dataflow of the buildroot's
>>> Makefile. How/who parse/calls to the functions like:
>>>
>>> HELLO_INSTALL_TARGET_CMDS
>>> HELLO_BUILD_CMDS
>>>
>>> $(eval $(generic-package))
>>
>> The generic-package macro will find in which directory your Makefile
>> is, for example package/hello/. It will take this "hello" convert it to
>> uppercase, and use it as the prefix for all variables. So basically, a
>> package in package/hello/hello.mk will have to define HELLO_SITE,
>> HELLO_SOURCE, HELLO_VERSION, and possibly HELLO_BUILD_CMDS,
>> HELLO_INSTALL_TARGET_CMDS, etc.
>>
>>> So, How I can tell to the generic-package to call HELLO_TEST_CMDS too?
>>>
>>> example:
>>> define HELLO_TEST_CMDS
>>> ...
>>> endef
>>
>> That would require a modification of the package infrastructure, which
>> you probably don't want to do. What are you trying to achieve with a
>> new command exactly?
>>
>> New commands are normally not needed:
>>
>> *) For autotools-package and cmake-package, you have hooks so that you
>> can do something after extraction, after patching, after
>> configuration, after installation, etc.
>>
>> *) For generic-package, you can do something like:
>>
>> ifeq ($(BR2_PACKAGE_HELLO_SOMETHING),y)
>> define HELLO_DO_THIS_CMDS
>> $(MAKE) -C $(@D) do-this
>> endef
>> endif
>>
>> ifeq ($(BR2_PACKAGE_HELLO_SOMETHING_ELSE),y)
>> define HELLO_DO_THAT_CMDS
>> $(MAKE) -C $(@D) do-that
>> endef
>> endif
>>
>> define HELLO_BUILD_CMDS
>> $(HELLO_DO_THIS_CMDS)
>> $(HELLO_DO_THAT_CMDS)
>> endef
>>
>> Please make sure to read our documentation at
>> http://buildroot.org/downloads/manual/manual.html#_adding_new_packages_to_buildroot
>> which explains all of this with quite some details and examples.
>>
>> Do not hesitate to get back to the list if you need further details,
>>
>> 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 3/3] xtensa: disable libffi for Xtensa
From: Chris Zankel @ 2012-11-20 19:01 UTC (permalink / raw)
To: buildroot
Xtensa currently doesn't support libffi.
Signed-off-by: Chris Zankel <chris@zankel.net>
---
package/libffi/Config.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/package/libffi/Config.in b/package/libffi/Config.in
index 7211f8f..4afb669 100644
--- a/package/libffi/Config.in
+++ b/package/libffi/Config.in
@@ -1,5 +1,6 @@
config BR2_PACKAGE_LIBFFI
bool "libffi"
+ depends on !BR2_xtensa
help
The libffi library provides a portable, high level
programming interface to various calling conventions. This
--
1.7.9.5
^ permalink raw reply related
* [Buildroot] [PATCH 2/3] xtensa: fix target gdb build and 64-bit host side gdb
From: Chris Zankel @ 2012-11-20 18:43 UTC (permalink / raw)
To: buildroot
Fix build breakage, use the version of the ptrace header file in asm
instead of sys. Also, fix GDB running on 64 bit hosts. GDB was using
unsigned long for 32-bit registers, but unsigned long is 64 bit on
64-bit hosts.
Signed-off-by: Chris Zankel <chris@zankel.net>
---
toolchain/gdb/7.4.1/xtensa-asm-ptrace-h.patch | 22 ++++++++++++++++++++++
toolchain/gdb/7.4.1/xtensa-gdb-regsize.patch | 19 +++++++++++++++++++
2 files changed, 41 insertions(+)
create mode 100644 toolchain/gdb/7.4.1/xtensa-asm-ptrace-h.patch
create mode 100644 toolchain/gdb/7.4.1/xtensa-gdb-regsize.patch
diff --git a/toolchain/gdb/7.4.1/xtensa-asm-ptrace-h.patch b/toolchain/gdb/7.4.1/xtensa-asm-ptrace-h.patch
new file mode 100644
index 0000000..3d1b07c
--- /dev/null
+++ b/toolchain/gdb/7.4.1/xtensa-asm-ptrace-h.patch
@@ -0,0 +1,22 @@
+--- gdb-7.4.1/gdb/xtensa-linux-nat.c.orig 2012-10-19 16:23:06.908165323 -0700
++++ gdb-7.4.1/gdb/xtensa-linux-nat.c 2012-10-19 16:35:30.792134876 -0700
+@@ -36,7 +36,7 @@
+ #include "gdb_wait.h"
+ #include <fcntl.h>
+ #include <sys/procfs.h>
+-#include <sys/ptrace.h>
++#include <asm/ptrace.h>
+
+ #include "gregset.h"
+ #include "xtensa-tdep.h"
+--- gdb-7.4.1/gdb/gdbserver/linux-xtensa-low.c.orig 2012-10-19 16:24:06.260162894 -0700
++++ gdb-7.4.1/gdb/gdbserver/linux-xtensa-low.c 2012-10-19 16:36:07.920133357 -0700
+@@ -23,7 +23,7 @@
+ /* Defined in auto-generated file reg-xtensa.c. */
+ void init_registers_xtensa (void);
+
+-#include <sys/ptrace.h>
++#include <asm/ptrace.h>
+ #include <xtensa-config.h>
+
+ #include "xtensa-xtregs.c"
diff --git a/toolchain/gdb/7.4.1/xtensa-gdb-regsize.patch b/toolchain/gdb/7.4.1/xtensa-gdb-regsize.patch
new file mode 100644
index 0000000..e10bb8f
--- /dev/null
+++ b/toolchain/gdb/7.4.1/xtensa-gdb-regsize.patch
@@ -0,0 +1,19 @@
+--- gdb-7.4.1/gdb/xtensa-tdep.h.orig 2012-10-30 11:40:23.546448594 -0700
++++ gdb-7.4.1/gdb/xtensa-tdep.h 2012-10-30 11:41:43.078445337 -0700
+@@ -17,6 +17,7 @@
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
++#include <stdint.h>
+
+ /* XTENSA_TDEP_VERSION can/should be changed along with XTENSA_CONFIG_VERSION
+ whenever the "tdep" structure changes in an incompatible way. */
+@@ -84,7 +85,7 @@
+ /* Xtensa ELF core file register set representation ('.reg' section).
+ Copied from target-side ELF header <xtensa/elf.h>. */
+
+-typedef unsigned long xtensa_elf_greg_t;
++typedef uint32_t xtensa_elf_greg_t;
+
+ typedef struct
+ {
--
1.7.9.5
^ permalink raw reply related
* [Buildroot] [PATCH 1/3] xtensa: use uppercase for configurations and modofied overlay structure
From: Chris Zankel @ 2012-11-20 18:31 UTC (permalink / raw)
To: buildroot
Except for architecture and processor names, buildroot uses capitalized
configuration names, so change the macro names for xtensa to follow that
standard.
Change the overlay file to have a subdirectory for each component
(gdb, binutils, gcc, etc.) to make it more future-prove.
Signed-off-by: Chris Zankel <chris@zankel.net>
---
arch/Config.in.xtensa | 26 +++++++++++++++-----------
package/binutils/binutils.mk | 6 +++---
toolchain/gcc/gcc-uclibc-4.x.mk | 6 +++---
toolchain/gdb/gdb.mk | 6 +++---
4 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/arch/Config.in.xtensa b/arch/Config.in.xtensa
index af66125..60c03f5 100644
--- a/arch/Config.in.xtensa
+++ b/arch/Config.in.xtensa
@@ -2,32 +2,36 @@ choice
prompt "Target Architecture Variant"
depends on BR2_xtensa
default BR2_xtensa_fsf
-config BR2_xtensa_custom
+config BR2_XTENSA_CUSTOM
bool "Custom Xtensa processor configuration"
config BR2_xtensa_fsf
bool "fsf - Default configuration"
endchoice
-config BR2_xtensa_custom_name
- string "Custom Xtensa processor configuration anme"
- depends on BR2_xtensa_custom
+config BR2_XTENSA_CUSTOM_NAME
+ string "Custom Xtensa processor configuration name"
+ depends on BR2_XTENSA_CUSTOM
default ""
help
Name given to a custom Xtensa processor configuration.
-config BR2_xtensa_core_name
+config BR2_XTENSA_CORE_NAME
string
- default BR2_xtensa_custom_name if BR2_xtensa_custom
+ default BR2_XTENSA_CUSTOM_NAME if BR2_XTENSA_CUSTOM
default "" if BR2_xtensa_fsf
-config BR2_xtensa_overlay_dir
+config BR2_XTENSA_OVERLAY_DIR
string "Overlay directory for custom configuration"
- depends on BR2_xtensa_custom
+ depends on BR2_XTENSA_CUSTOM
default ""
help
- Provide a directory path that contains the overlay files
- for the custom configuration. The path is based on the
- buildroot top directory.
+ Provide the directory path that contains the overlay file
+ for a custom processor configuration. The path is relative
+ to the top directory of buildroot.
+ These overlay files are tar packages with updated configuration
+ files for various toolchain packages and Xtensa processor
+ configurations. They are provided by the processor vendor or
+ directly from Tensilica.
config BR2_ARCH
default "xtensa" if BR2_xtensa
diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk
index 82f8fd2..92e0a74 100644
--- a/package/binutils/binutils.mk
+++ b/package/binutils/binutils.mk
@@ -68,11 +68,11 @@ define BINUTILS_INSTALL_TARGET_CMDS
endef
endif
-XTENSA_CORE_NAME = $(call qstrip, $(BR2_xtensa_core_name))
+XTENSA_CORE_NAME = $(call qstrip, $(BR2_XTENSA_CORE_NAME))
ifneq ($(XTENSA_CORE_NAME),)
define BINUTILS_XTENSA_PRE_PATCH
- tar xf $(BR2_xtensa_overlay_dir)/xtensa_$(XTENSA_CORE_NAME).tar \
- -C $(@D) bfd include ld
+ tar xf $(BR2_XTENSA_OVERLAY_DIR)/xtensa_$(XTENSA_CORE_NAME).tar \
+ -C $(@D) --strip-components=1 binutils
endef
HOST_BINUTILS_PRE_PATCH_HOOKS += BINUTILS_XTENSA_PRE_PATCH
endif
diff --git a/toolchain/gcc/gcc-uclibc-4.x.mk b/toolchain/gcc/gcc-uclibc-4.x.mk
index 1710070..7a0b4ca 100644
--- a/toolchain/gcc/gcc-uclibc-4.x.mk
+++ b/toolchain/gcc/gcc-uclibc-4.x.mk
@@ -251,9 +251,9 @@ $(GCC_DIR)/.unpacked: $(DL_DIR)/$(GCC_SOURCE)
rm -rf $(GCC_DIR)
$(GCC_CAT) $(DL_DIR)/$(GCC_SOURCE) | tar -C $(TOOLCHAIN_DIR) $(TAR_OPTIONS) -
$(call CONFIG_UPDATE,$(@D))
-ifneq ($(call qstrip, $(BR2_xtensa_core_name)),)
- tar xf $(BR2_xtensa_overlay_dir)/xtensa_$(call qstrip,\
- $(BR2_xtensa_core_name)).tar -C $(@D) include
+ifneq ($(call qstrip, $(BR2_XTENSA_CORE_NAME)),)
+ tar xf $(BR2_XTENSA_OVERLAY_DIR)/xtensa_$(call qstrip,\
+ $(BR2_XTENSA_CORE_NAME)).tar -C $(@D) --strip-components=1 gcc
endif
touch $@
diff --git a/toolchain/gdb/gdb.mk b/toolchain/gdb/gdb.mk
index dc305a6..c42c755 100644
--- a/toolchain/gdb/gdb.mk
+++ b/toolchain/gdb/gdb.mk
@@ -25,9 +25,9 @@ gdb-unpacked: $(GDB_DIR)/.unpacked
$(GDB_DIR)/.unpacked: $(DL_DIR)/$(GDB_SOURCE)
mkdir -p $(GDB_DIR)
$(GDB_CAT) $(DL_DIR)/$(GDB_SOURCE) | tar -C $(GDB_DIR) $(TAR_STRIP_COMPONENTS)=1 $(TAR_OPTIONS) -
-ifneq ($(call qstrip, $(BR2_xtensa_core_name)),)
- tar xf $(BR2_xtensa_overlay_dir)/xtensa_$(call qstrip, \
- $(BR2_xtensa_core_name)).tar -C $(@D) bfd include gdb
+ifneq ($(call qstrip, $(BR2_XTENSA_CORE_NAME)),)
+ tar xf $(BR2_XTENSA_OVERLAY_DIR)/xtensa_$(call qstrip, \
+ $(BR2_XTENSA_CORE_NAME)).tar -C $(@D) --strip-components=1 gdb
endif
ifneq ($(wildcard $(GDB_PATCH_DIR)),)
support/scripts/apply-patches.sh $(GDB_DIR) $(GDB_PATCH_DIR) \*.patch
--
1.7.9.5
^ permalink raw reply related
* [Buildroot] Who calls to the defined function/s
From: John Tobias @ 2012-11-20 18:26 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121120095904.20264654@skate>
Dear Thomas Petazzoni,
Thank you for the response. I was thinking to support the package
management in the buildroot. Where, if I define XXX_CREATE_PACKAGE in
my hello.mk
the buildroot (for example) will create an opkg file (off-course I
have supply the necessary information to create the package file).
I know the buildroot community did not support it package management
but I would like to add some flexibility on my buildroot environment.
Regards,
john
On Tue, Nov 20, 2012 at 12:59 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear John Tobias,
>
> On Mon, 19 Nov 2012 18:21:03 -0800, John Tobias wrote:
>
>> I was trying to (fully) understand the dataflow of the buildroot's
>> Makefile. How/who parse/calls to the functions like:
>>
>> HELLO_INSTALL_TARGET_CMDS
>> HELLO_BUILD_CMDS
>>
>> $(eval $(generic-package))
>
> The generic-package macro will find in which directory your Makefile
> is, for example package/hello/. It will take this "hello" convert it to
> uppercase, and use it as the prefix for all variables. So basically, a
> package in package/hello/hello.mk will have to define HELLO_SITE,
> HELLO_SOURCE, HELLO_VERSION, and possibly HELLO_BUILD_CMDS,
> HELLO_INSTALL_TARGET_CMDS, etc.
>
>> So, How I can tell to the generic-package to call HELLO_TEST_CMDS too?
>>
>> example:
>> define HELLO_TEST_CMDS
>> ...
>> endef
>
> That would require a modification of the package infrastructure, which
> you probably don't want to do. What are you trying to achieve with a
> new command exactly?
>
> New commands are normally not needed:
>
> *) For autotools-package and cmake-package, you have hooks so that you
> can do something after extraction, after patching, after
> configuration, after installation, etc.
>
> *) For generic-package, you can do something like:
>
> ifeq ($(BR2_PACKAGE_HELLO_SOMETHING),y)
> define HELLO_DO_THIS_CMDS
> $(MAKE) -C $(@D) do-this
> endef
> endif
>
> ifeq ($(BR2_PACKAGE_HELLO_SOMETHING_ELSE),y)
> define HELLO_DO_THAT_CMDS
> $(MAKE) -C $(@D) do-that
> endef
> endif
>
> define HELLO_BUILD_CMDS
> $(HELLO_DO_THIS_CMDS)
> $(HELLO_DO_THAT_CMDS)
> endef
>
> Please make sure to read our documentation at
> http://buildroot.org/downloads/manual/manual.html#_adding_new_packages_to_buildroot
> which explains all of this with quite some details and examples.
>
> Do not hesitate to get back to the list if you need further details,
>
> 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] toolchain-crosstool-ng: install libthread_db if appropriate
From: Yann E. MORIN @ 2012-11-20 17:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353430797-26819-1-git-send-email-rbraun@sceen.net>
On Tuesday 20 November 2012 Richard Braun wrote:
> Signed-off-by: Richard Braun <rbraun@sceen.net>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> ---
> toolchain/toolchain-crosstool-ng/crosstool-ng.mk | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
> index 5f9119d..ebc7b4b 100644
> --- a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
> +++ b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
> @@ -41,6 +41,10 @@ uclibc-source: $(CTNG_DIR)/.config
> CTNG_LIBS_LIB := ld*.so libc.so libcrypt.so libdl.so libgcc_s.so libm.so \
> libnsl.so libpthread.so libresolv.so librt.so libutil.so
>
> +ifeq ($(BR2_PACKAGE_GDB_SERVER),y)
> +CTNG_LIBS_LIB += libthread_db.so
> +endif
> +
> #--------------
> # The libc-specific system libraries (in /lib)
> # Note: it may be needed to tweak the NSS libs in the glibc and eglibc cases...
> --
> 1.7.2.5
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
>
--
.-----------------.--------------------.------------------.--------------------.
| 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] toolchain-crosstool-ng: install libthread_db if appropriate
From: Richard Braun @ 2012-11-20 17:38 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201211201836.50589.yann.morin.1998@free.fr>
On Tue, Nov 20, 2012 at 06:36:50PM +0100, Yann E. MORIN wrote:
> > +ifeq ($(BR2_PACKAGE_GDB_SERVER),y)
> > +CTNG_LIBS_LIB += libthread_db.so
>
> Shouldn't that be:
> CTNG_LIBS_USR_LIB += libthread_db.so
I don't think so, at least I've always seen libthread_db installed in
/lib, and it does work this way.
--
Richard Braun
^ permalink raw reply
* [Buildroot] [PATCH] toolchain-crosstool-ng: install libthread_db if appropriate
From: Yann E. MORIN @ 2012-11-20 17:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353430797-26819-1-git-send-email-rbraun@sceen.net>
Richard, All,
On Tuesday 20 November 2012 Richard Braun wrote:
> Signed-off-by: Richard Braun <rbraun@sceen.net>
> ---
> toolchain/toolchain-crosstool-ng/crosstool-ng.mk | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
> index 5f9119d..ebc7b4b 100644
> --- a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
> +++ b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
> @@ -41,6 +41,10 @@ uclibc-source: $(CTNG_DIR)/.config
> CTNG_LIBS_LIB := ld*.so libc.so libcrypt.so libdl.so libgcc_s.so libm.so \
> libnsl.so libpthread.so libresolv.so librt.so libutil.so
>
> +ifeq ($(BR2_PACKAGE_GDB_SERVER),y)
> +CTNG_LIBS_LIB += libthread_db.so
Shouldn't that be:
CTNG_LIBS_USR_LIB += libthread_db.so
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] Makefile: fix thread libraries stripping
From: Richard Braun @ 2012-11-20 17:18 UTC (permalink / raw)
To: buildroot
Strip libthread_db the same as any other library, but strip libpthread
with --strip-debug. See the relevant mailing list discussion [1] for
additional details.
[1] http://lists.busybox.net/pipermail/buildroot/2012-October/060126.html
Signed-off-by: Richard Braun <rbraun@sceen.net>
---
Makefile | 10 +++++++++-
package/Makefile.in | 2 ++
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 21aa054..4db5cbc 100644
--- a/Makefile
+++ b/Makefile
@@ -419,7 +419,7 @@ ifneq (,$(call qstrip,$(BR2_STRIP_EXCLUDE_DIRS)))
STRIP_FIND_CMD += \( $(call finddirclauses,$(TARGET_DIR),$(call qstrip,$(BR2_STRIP_EXCLUDE_DIRS))) \) -prune -o
endif
STRIP_FIND_CMD += -type f -perm +111
-STRIP_FIND_CMD += -not \( $(call findfileclauses,libthread_db*.so* $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) -print
+STRIP_FIND_CMD += -not \( $(call findfileclauses,libpthread*.so* $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) -print
target-finalize:
ifeq ($(BR2_HAVE_DEVFILES),y)
@@ -450,6 +450,14 @@ endif
find $(TARGET_DIR)/lib/modules -type f -name '*.ko' | \
xargs -r $(KSTRIPCMD) || true
+# See http://sourceware.org/gdb/wiki/FAQ, "GDB does not see any threads
+# besides the one in which crash occurred; or SIGTRAP kills my program when
+# I set a breakpoint"
+ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
+ find $(TARGET_DIR)/lib -type f -name 'libpthread*.so*' | \
+ xargs $(STRIPCMD) $(STRIP_STRIP_DEBUG) || true
+endif
+
mkdir -p $(TARGET_DIR)/etc
# Mandatory configuration file and auxilliary cache directory
# for recent versions of ldconfig
diff --git a/package/Makefile.in b/package/Makefile.in
index 9fdc745..4813674 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -126,6 +126,7 @@ TARGET_CXX := $(CCACHE) $(TARGET_CXX)
endif
ifeq ($(BR2_STRIP_strip),y)
+STRIP_STRIP_DEBUG:=--strip-debug
STRIP_STRIP_UNNEEDED:=--strip-unneeded
STRIP_STRIP_ALL:=--strip-all
TARGET_STRIP=$(TARGET_CROSS)strip
@@ -133,6 +134,7 @@ STRIPCMD=$(TARGET_CROSS)strip --remove-section=.comment --remove-section=.note
KSTRIPCMD=$(STRIPCMD) $(STRIP_STRIP_UNNEEDED)
endif
ifeq ($(BR2_STRIP_sstrip),y)
+STRIP_STRIP_DEBUG:=
STRIP_STRIP_UNNEEDED:=
STRIP_STRIP_ALL:=
TARGET_STRIP=$(HOST_DIR)/usr/bin/$(GNU_TARGET_NAME)-sstrip
--
1.7.2.5
^ permalink raw reply related
* [Buildroot] [PATCH] toolchain-crosstool-ng: install libthread_db if appropriate
From: Richard Braun @ 2012-11-20 16:59 UTC (permalink / raw)
To: buildroot
Signed-off-by: Richard Braun <rbraun@sceen.net>
---
toolchain/toolchain-crosstool-ng/crosstool-ng.mk | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
index 5f9119d..ebc7b4b 100644
--- a/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
+++ b/toolchain/toolchain-crosstool-ng/crosstool-ng.mk
@@ -41,6 +41,10 @@ uclibc-source: $(CTNG_DIR)/.config
CTNG_LIBS_LIB := ld*.so libc.so libcrypt.so libdl.so libgcc_s.so libm.so \
libnsl.so libpthread.so libresolv.so librt.so libutil.so
+ifeq ($(BR2_PACKAGE_GDB_SERVER),y)
+CTNG_LIBS_LIB += libthread_db.so
+endif
+
#--------------
# The libc-specific system libraries (in /lib)
# Note: it may be needed to tweak the NSS libs in the glibc and eglibc cases...
--
1.7.2.5
^ permalink raw reply related
* [Buildroot] [PATCH] toolchain-external: fix installation of libthread_db
From: Richard Braun @ 2012-11-20 16:17 UTC (permalink / raw)
To: buildroot
Whatever the gdbserver source, as long as it's installed on the target,
assume it requires libthread_db.
Signed-off-by: Richard Braun <rbraun@sceen.net>
---
toolchain/toolchain-external/ext-tool.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/toolchain/toolchain-external/ext-tool.mk b/toolchain/toolchain-external/ext-tool.mk
index a6025db..8ce0a84 100644
--- a/toolchain/toolchain-external/ext-tool.mk
+++ b/toolchain/toolchain-external/ext-tool.mk
@@ -61,7 +61,7 @@ endif
ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
LIB_EXTERNAL_LIBS+=libpthread.so
-ifeq ($(BR2_PACKAGE_GDB_SERVER),y)
+ifneq ($(BR2_PACKAGE_GDB_SERVER)$(BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY),)
LIB_EXTERNAL_LIBS+=libthread_db.so
endif # gdbserver
endif # ! no threads
--
1.7.2.5
^ permalink raw reply related
* [Buildroot] [PATCH] pppd: ol2tpv* patch updated from 2.6.35 header to 3.6
From: Gustavo Zacarias @ 2012-11-20 11:40 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353408222-4111-1-git-send-email-fenixk19@mail.ru>
On 11/20/2012 07:43 AM, Alexander Varnin wrote:
> pppd-2.4.5 doesn't build anymore with v3.6 headers installed.
> This patch replaces the old one, for 2.6.35 header, and makes
> it to build correctly.
It's already fixed in git by Peter's commit 94ce13a56 for the 2012.11
release.
Regards.
^ permalink raw reply
* [Buildroot] How to regenerate zImage?
From: Woody Wu @ 2012-11-20 11:24 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121120100158.15b1b159@skate>
On 2012-11-20, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>
wrote:
> Dear Woody Wu,
>
> On Tue, 20 Nov 2012 08:17:54 +0000 (UTC), Woody Wu wrote:
>> After I made any small changes in kernel source, I can force the
>> kernel to be rebuilt by removing the .stamp_built under the
>> output/build/linux-version directory. But, it's strange that the
>> output/zImage file always not get recreated or rebuilt.
>>
>> How should I force the buildroot to regenerate the zImage file for
>> me?
>
> make linux-rebuild
Thanks, I will try.
>
> However, note that making changing to the source code anywhere in
> output/build/... is a really stupid idea, as all those changes will be
> lost next time you do 'make clean'.
>
Yes, I agree this is stupid. So I also really like to know whta's the
best practice to do this kind of work. Would you be so kind to have a
introduction or point me to a docment? Thanks
--
woody
I can't go back to yesterday - because I was a different person then.
^ permalink raw reply
* [Buildroot] [PATCH] barebox: Add BR2_TARGET_BAREBOX_2012_11
From: Gregory Hermant @ 2012-11-20 11:14 UTC (permalink / raw)
To: buildroot
Signed-off-by: Gregory Hermant <gregory.hermant@calao-systems.com>
---
boot/barebox/Config.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/boot/barebox/Config.in b/boot/barebox/Config.in
index c9e7088..997f45b 100644
--- a/boot/barebox/Config.in
+++ b/boot/barebox/Config.in
@@ -45,6 +45,7 @@ config BR2_TARGET_BAREBOX_VERSION
default "2012.08.0" if BR2_TARGET_BAREBOX_2012_08
default "2012.09.0" if BR2_TARGET_BAREBOX_2012_09
default "2012.10.0" if BR2_TARGET_BAREBOX_2012_10
+ default "2012.11.0" if BR2_TARGET_BAREBOX_2012_11
default "custom" if BR2_TARGET_BAREBOX_CUSTOM_TARBALL
default $BR2_TARGET_BAREBOX_CUSTOM_GIT_VERSION if BR2_TARGET_BAREBOX_CUSTOM_GIT
--
1.7.9.5
^ permalink raw reply related
* [Buildroot] GTK vs Qt
From: Zoran Djordjevic @ 2012-11-20 11:06 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121120114507.0a14be55@skate>
Thanks, it's more clear now. I will read articles you
pointed at. Maybe I will have some more questions then.
?
Regards
________________________________
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Zoran Djordjevic <djdjdjole@yahoo.com>
Cc: "buildroot at busybox.net" <buildroot@busybox.net>
Sent: Tuesday, November 20, 2012 11:45 AM
Subject: Re: [Buildroot] GTK vs Qt
Dear Zoran Djordjevic,
On Tue, 20 Nov 2012 02:23:35 -0800 (PST), Zoran Djordjevic wrote:
> OK -let me put question this way. If I successfully compile/run
> QT program on desktop, and then recompile the same source with
> let's say Builtroot built compiler (for ARM), should I expect that
> this program will understand -qws option (which I thought is strictly
> related to QtCreator). The only way I succeeded to start Qt demo
> programs was with -qws. Hope it's more clear question.
Aaah. Ok. No, -qws *has* nothing to do with Qt Creator.
-qws is the option to tell Qt to start the Qt Windowing System.
When you run a Qt application on your desktop, there is already a
windowing system (X.org) and a window manager. So Qt is just a toolkit
like any other, it just draws inside a window provided by the windowing
system.
However, when you build Qt for your embedded system so that it runs
directly on the framebuffer, there is no windowing system provided. So
Qt has its own, that you must enable for the *first* Qt application you
run, using the -qws option.
You can run multiple Qt applications on your embedded system thanks to
this. The first one will have to be started with -qws, the other ones
will automatically connect to the first one thanks to a Unix socket,
and therefore be able to share the screen.
You probably want to read:
http://doc.qt.digia.com/qt/qt-embedded-architecture.html
http://doc.qt.digia.com/qt/qt-embedded-running.html
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121120/eec4210b/attachment.html>
^ permalink raw reply
* [Buildroot] GTK vs Qt
From: Thomas Petazzoni @ 2012-11-20 10:45 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353407015.92864.YahooMailNeo@web164601.mail.gq1.yahoo.com>
Dear Zoran Djordjevic,
On Tue, 20 Nov 2012 02:23:35 -0800 (PST), Zoran Djordjevic wrote:
> OK -let me put question this way. If I successfully compile/run
> QT program on desktop, and then recompile the same source with
> let's say Builtroot built compiler (for ARM), should I expect that
> this program will understand -qws option (which I thought is strictly
> related to QtCreator). The only way I succeeded to start Qt demo
> programs was with -qws. Hope it's more clear question.
Aaah. Ok. No, -qws *has* nothing to do with Qt Creator.
-qws is the option to tell Qt to start the Qt Windowing System.
When you run a Qt application on your desktop, there is already a
windowing system (X.org) and a window manager. So Qt is just a toolkit
like any other, it just draws inside a window provided by the windowing
system.
However, when you build Qt for your embedded system so that it runs
directly on the framebuffer, there is no windowing system provided. So
Qt has its own, that you must enable for the *first* Qt application you
run, using the -qws option.
You can run multiple Qt applications on your embedded system thanks to
this. The first one will have to be started with -qws, the other ones
will automatically connect to the first one thanks to a Unix socket,
and therefore be able to share the screen.
You probably want to read:
http://doc.qt.digia.com/qt/qt-embedded-architecture.html
http://doc.qt.digia.com/qt/qt-embedded-running.html
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] pppd: ol2tpv* patch updated from 2.6.35 header to 3.6
From: Alexander Varnin @ 2012-11-20 10:43 UTC (permalink / raw)
To: buildroot
pppd-2.4.5 doesn't build anymore with v3.6 headers installed.
This patch replaces the old one, for 2.6.35 header, and makes
it to build correctly.
Signed-off-by: Alexander Varnin <fenixk19@mail.ru>
---
package/pppd/pppd-2.4.5-ol2tp-v3.6.patch | 99 ++++++++++++++++++++++++++
package/pppd/pppd-2.4.5-ol2tpv3-2.6.35.patch | 24 ------
2 files changed, 99 insertions(+), 24 deletions(-)
create mode 100644 package/pppd/pppd-2.4.5-ol2tp-v3.6.patch
delete mode 100644 package/pppd/pppd-2.4.5-ol2tpv3-2.6.35.patch
diff --git a/package/pppd/pppd-2.4.5-ol2tp-v3.6.patch b/package/pppd/pppd-2.4.5-ol2tp-v3.6.patch
new file mode 100644
index 0000000..b9936eb
--- /dev/null
+++ b/package/pppd/pppd-2.4.5-ol2tp-v3.6.patch
@@ -0,0 +1,99 @@
+diff -rp ppp-2.4.5-old/include/linux/if_pppol2tp.h ppp-2.4.5-new/include/linux/if_pppol2tp.h
+*** ppp-2.4.5-old/include/linux/if_pppol2tp.h 2009-11-17 01:26:07.000000000 +0300
+--- ppp-2.4.5-new/include/linux/if_pppol2tp.h 2012-11-08 20:16:38.000000000 +0400
+***************
+*** 2,8 ****
+ * Linux PPP over L2TP (PPPoL2TP) Socket Implementation (RFC 2661)
+ *
+ * This file supplies definitions required by the PPP over L2TP driver
+! * (pppol2tp.c). All version information wrt this file is located in pppol2tp.c
+ *
+ * License:
+ * This program is free software; you can redistribute it and/or
+--- 2,8 ----
+ * Linux PPP over L2TP (PPPoL2TP) Socket Implementation (RFC 2661)
+ *
+ * This file supplies definitions required by the PPP over L2TP driver
+! * (l2tp_ppp.c). All version information wrt this file is located in l2tp_ppp.c
+ *
+ * License:
+ * This program is free software; you can redistribute it and/or
+***************
+*** 15,28 ****
+ #ifndef __LINUX_IF_PPPOL2TP_H
+ #define __LINUX_IF_PPPOL2TP_H
+
+! #include <asm/types.h>
+
+ /* Structure used to connect() the socket to a particular tunnel UDP
+! * socket.
+ */
+! struct pppol2tp_addr
+! {
+! pid_t pid; /* pid that owns the fd.
+ * 0 => current */
+ int fd; /* FD of UDP socket to use */
+
+--- 15,28 ----
+ #ifndef __LINUX_IF_PPPOL2TP_H
+ #define __LINUX_IF_PPPOL2TP_H
+
+! #include <linux/types.h>
+!
+
+ /* Structure used to connect() the socket to a particular tunnel UDP
+! * socket over IPv4.
+ */
+! struct pppol2tp_addr {
+! __kernel_pid_t pid; /* pid that owns the fd.
+ * 0 => current */
+ int fd; /* FD of UDP socket to use */
+
+*************** struct pppol2tp_addr
+*** 32,37 ****
+--- 32,76 ----
+ __u16 d_tunnel, d_session; /* For sending outgoing packets */
+ };
+
++ /* Structure used to connect() the socket to a particular tunnel UDP
++ * socket over IPv6.
++ */
++ struct pppol2tpin6_addr {
++ __kernel_pid_t pid; /* pid that owns the fd.
++ * 0 => current */
++ int fd; /* FD of UDP socket to use */
++
++ __u16 s_tunnel, s_session; /* For matching incoming packets */
++ __u16 d_tunnel, d_session; /* For sending outgoing packets */
++
++ struct sockaddr_in6 addr; /* IP address and port to send to */
++ };
++
++ /* The L2TPv3 protocol changes tunnel and session ids from 16 to 32
++ * bits. So we need a different sockaddr structure.
++ */
++ struct pppol2tpv3_addr {
++ __kernel_pid_t pid; /* pid that owns the fd.
++ * 0 => current */
++ int fd; /* FD of UDP or IP socket to use */
++
++ struct sockaddr_in addr; /* IP address and port to send to */
++
++ __u32 s_tunnel, s_session; /* For matching incoming packets */
++ __u32 d_tunnel, d_session; /* For sending outgoing packets */
++ };
++
++ struct pppol2tpv3in6_addr {
++ __kernel_pid_t pid; /* pid that owns the fd.
++ * 0 => current */
++ int fd; /* FD of UDP or IP socket to use */
++
++ __u32 s_tunnel, s_session; /* For matching incoming packets */
++ __u32 d_tunnel, d_session; /* For sending outgoing packets */
++
++ struct sockaddr_in6 addr; /* IP address and port to send to */
++ };
++
+ /* Socket options:
+ * DEBUG - bitmask of debug message categories
+ * SENDSEQ - 0 => don't send packets with sequence numbers
diff --git a/package/pppd/pppd-2.4.5-ol2tpv3-2.6.35.patch b/package/pppd/pppd-2.4.5-ol2tpv3-2.6.35.patch
deleted file mode 100644
index 0e71e24..0000000
--- a/package/pppd/pppd-2.4.5-ol2tpv3-2.6.35.patch
+++ /dev/null
@@ -1,24 +0,0 @@
---- ppp-2.4.5/include/linux/if_pppol2tp.h 2009-11-16 22:26:07.000000000 +0000
-+++ ppp-2.4.5/include/linux/if_pppol2tp.h 2010-07-16 22:35:22.000000000 +0100
-@@ -32,6 +32,20 @@
- __u16 d_tunnel, d_session; /* For sending outgoing packets */
- };
-
-+/* The L2TPv3 protocol changes tunnel and session ids from 16 to 32
-+ * bits. So we need a different sockaddr structure.
-+ */
-+struct pppol2tpv3_addr {
-+ pid_t pid; /* pid that owns the fd.
-+ * 0 => current */
-+ int fd; /* FD of UDP or IP socket to use */
-+
-+ struct sockaddr_in addr; /* IP address and port to send to */
-+
-+ __u32 s_tunnel, s_session; /* For matching incoming packets */
-+ __u32 d_tunnel, d_session; /* For sending outgoing packets */
-+};
-+
- /* Socket options:
- * DEBUG - bitmask of debug message categories
- * SENDSEQ - 0 => don't send packets with sequence numbers
-
--
1.7.2.5
^ permalink raw reply related
* [Buildroot] GTK vs Qt
From: Zoran Djordjevic @ 2012-11-20 10:23 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121120110936.4ca119a4@skate>
OK -let me put question this way. If I successfully compile/run
QT program on desktop, and then recompile the same source with
let's say Builtroot built compiler (for ARM), should I expect that
this program will understand -qws option (which I thought is strictly
related to QtCreator). The only way I succeeded to start Qt demo
programs was with -qws. Hope it's more clear question.
?
Regards
________________________________
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Zoran Djordjevic <djdjdjole@yahoo.com>
Cc: "buildroot at busybox.net" <buildroot@busybox.net>
Sent: Tuesday, November 20, 2012 11:09 AM
Subject: Re: [Buildroot] GTK vs Qt
Dear Zoran Djordjevic,
On Tue, 20 Nov 2012 02:02:51 -0800 (PST), Zoran Djordjevic wrote:
> Does it mean that I cannot start?Qt programs built the way
> to use X (on Buildroot built linux)?
Sorry, I don't understand your question. I'll try to explain things
differently.
At the moment, Buildroot is only capable of building a Qt library that
works on top of the framebuffer. It is possible to add support to build
Qt on X.org, but no-one has worked on that until now. So for your
target, with the current Buildroot, if you use Qt, it's on the
framebuffer.
That said, your Qt application itself, if written correctly, can also
be compiled for your desktop machine, and in this case, the Qt you have
in your desktop distribution uses X.org as its graphic backend.
> Or does it mean that I must use QtCreator if I want GUI on embedded
> boards with Buildroot built linux ?
I really don't see the relation between QtCreator and the whole
discussion. QtCreator is an IDE that has some interesting features to
do Qt development, but:
* You can do Qt development without QtCreator. I've done quite a bit
? of Qt development in Emacs.
* You can do non-Qt development with QtCreator.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121120/015f88c3/attachment-0001.html>
^ permalink raw reply
* [Buildroot] GTK vs Qt
From: Thomas Petazzoni @ 2012-11-20 10:09 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1353405771.50495.YahooMailNeo@web164602.mail.gq1.yahoo.com>
Dear Zoran Djordjevic,
On Tue, 20 Nov 2012 02:02:51 -0800 (PST), Zoran Djordjevic wrote:
> Does it mean that I cannot start?Qt programs built the way
> to use X (on Buildroot built linux)?
Sorry, I don't understand your question. I'll try to explain things
differently.
At the moment, Buildroot is only capable of building a Qt library that
works on top of the framebuffer. It is possible to add support to build
Qt on X.org, but no-one has worked on that until now. So for your
target, with the current Buildroot, if you use Qt, it's on the
framebuffer.
That said, your Qt application itself, if written correctly, can also
be compiled for your desktop machine, and in this case, the Qt you have
in your desktop distribution uses X.org as its graphic backend.
> Or does it mean that I must use QtCreator if I want GUI on embedded
> boards with Buildroot built linux ?
I really don't see the relation between QtCreator and the whole
discussion. QtCreator is an IDE that has some interesting features to
do Qt development, but:
* You can do Qt development without QtCreator. I've done quite a bit
of Qt development in Emacs.
* You can do non-Qt development with QtCreator.
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