[OpenWrt-Devel] [PATCH] uclibc++: Fix error with stable_sort declaration
This backports a uclibc++ patch to be able to build a few packages like
crtmpserver and gptfdisk. Otherwise we get these errors:
error: 'stable_sort' was not declared in this scope, and no declarations
were found by argument-dependent lookup at the point of instantiation
[-fpermissive]
stable_sort(first, last, comp);
Signed-off-by: Rosen Penev
---
This is technically a v2. A more complete patch was made 3 months ago
but nobody looked at it.
package/libs/uclibc++/Makefile| 2 +-
...60-algorithm-Fix-decl-of-stable_sort.patch | 109 ++
2 files changed, 110 insertions(+), 1 deletion(-)
create mode 100644
package/libs/uclibc++/patches/060-algorithm-Fix-decl-of-stable_sort.patch
diff --git a/package/libs/uclibc++/Makefile b/package/libs/uclibc++/Makefile
index 7133a7ef33..cdd64591e4 100644
--- a/package/libs/uclibc++/Makefile
+++ b/package/libs/uclibc++/Makefile
@@ -10,7 +10,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=uclibc++
PKG_VERSION:=0.2.4
-PKG_RELEASE:=3
+PKG_RELEASE:=4
PKG_SOURCE:=uClibc++-$(PKG_VERSION).tar.bz2
PKG_SOURCE_URL:=http://cxx.uclibc.org/src/
diff --git
a/package/libs/uclibc++/patches/060-algorithm-Fix-decl-of-stable_sort.patch
b/package/libs/uclibc++/patches/060-algorithm-Fix-decl-of-stable_sort.patch
new file mode 100644
index 00..d78f9d6db1
--- /dev/null
+++ b/package/libs/uclibc++/patches/060-algorithm-Fix-decl-of-stable_sort.patch
@@ -0,0 +1,109 @@
+From adb1d3558256864519771a9214789b75f00e2692 Mon Sep 17 00:00:00 2001
+From: Bernhard Reutner-Fischer
+Date: Fri, 23 Sep 2016 15:29:34 +0200
+Subject: [PATCH] algorithm: Fix decl of stable_sort
+
+Moritz Warning reported that stable_sort needs to be declared before sort.
+
+Signed-off-by: Bernhard Reutner-Fischer
+---
+ include/algorithm | 12 ++--
+ tests/algotest.cpp | 31 +++
+ tests/testoutput/algotest.good | 4 ++--
+ 3 files changed, 39 insertions(+), 8 deletions(-)
+
+diff --git a/include/algorithm b/include/algorithm
+index 5e8f139..af04f97 100644
+--- a/include/algorithm
b/include/algorithm
+@@ -830,12 +830,6 @@ namespace std{
+ sort(first, last, c );
+ }
+
+- template _UCXXEXPORT
+- void sort(RandomAccessIterator first, RandomAccessIterator
last, Compare comp)
+- {
+- stable_sort(first, last, comp);
+- }
+-
+ template _UCXXEXPORT
+ void stable_sort(RandomAccessIterator first,
RandomAccessIterator last)
+ {
+@@ -861,6 +855,12 @@ namespace std{
+ }
+ }
+
++ template _UCXXEXPORT
++ void sort(RandomAccessIterator first, RandomAccessIterator
last, Compare comp)
++ {
++ stable_sort(first, last, comp);
++ }
++
+ template _UCXXEXPORT
+ void partial_sort(RandomAccessIterator first,
RandomAccessIterator middle, RandomAccessIterator last)
+ {
+diff --git a/tests/algotest.cpp b/tests/algotest.cpp
+index cda5919..23ba3ae 100644
+--- a/tests/algotest.cpp
b/tests/algotest.cpp
+@@ -389,6 +389,36 @@ bool testPartialSort(){
+ return true;
+ }
+
++bool testSort() {
++ struct _my_comp {
++ inline bool operator()(const int , const int ) const {
++ return a > b;
++ }
++ };
++ std::vector a;
++ std::vector::iterator i;
++
++ a.push_back(5);
++ a.push_back(2);
++ a.push_back(4);
++ a.push_back(3);
++ a.push_back(1);
++ a.push_back(0);
++
++ i = a.begin();
++
++ std::sort::iterator>(a.begin(), a.end(), _my_comp());
++
++ for (int j = 0; j < 6; ++j) {
++ if (a[j] != 5 - j) {
++ printf("Key %i should be %i but is %i\n", j, 5-j, a[j]);
++ return false;
++ }
++ }
++
++ return true;
++}
++
+ bool testInplaceMerge(){
+ std::vector a;
+ std::vector::iterator i;
+@@ -572,6 +602,7 @@ int main(){
+ TestFramework::AssertReturns(testPushHeap, true);
+ TestFramework::AssertReturns(testSortHeap, true);
+ TestFramework::AssertReturns(testPartialSort, true);
++TestFramework::AssertReturns(testSort, true);
+ TestFramework::AssertReturns(testInplaceMerge, true);
+ TestFramework::AssertReturns(testNextPermutation, true);
+ TestFramework::AssertReturns(testPrevPermutation, true);
+diff --git a/tests/testoutput/algotest.good b/tests/testoutput/algotest.good
+index 53f2bb5..4d30e0a 100644
+--- a/tests/testoutput/algotest.good
b/tests/testoutput/algotest.good
+@@ -1,6 +1,6 @@
+ Beginning algorithm test
+-..
++...
+ --
+-Ran 14 tests
++Ran 15 tests
+
+ OK
+--
+2.20.1
+
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 4/7] uboot-tegra: add U-Boot for tegra boards
On 3/28/19 5:20 PM, Tomasz Maciej Nowak wrote: > Add U-Boot for NVIDIA Tegra based boards, with the first being CompuLab > TrimSlice. This is part of initial support for this board. > > Signed-off-by: Tomasz Maciej Nowak > --- U-Boot uses binman for tegra and binman needs swig to build. In mainline U-Boot sunxi, tegra and x86 are using binman for building and depend on swig at build time. On sunxi I patched this dependency out, but I do not know how we should handle this here? "apt install swig" solves the problem for me, I do not know if we can easily build swig in the tools and if this would be sufficient. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files/hotplug: add "dialout" user group and use it for ttyXYZ devices
Hi, > the "tty" group has been introduced exactly for this purpose some time > ago (1)(2). Any reason why we need "dialout" as well? > > ~ Jo > > 1: > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=5523ee3459a2d3 > 46ad068ce359cdb60dcda1239d 2: > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=124ab1dc0a6235 > 007f60953a796bf29122dfa242 well, it seems that the second commit did not survive (at least in master branch)... I noticed the "tty" group on OpenWrt but on my desktop system, it has slightly different meaning, see https://wiki.debian.org/SystemGroups So I guessed the meaning is the same on OpenWrt, thus the proposal to add "dialout" as well. You are right, that we don't need a second group to the same purpose. However, then I'd propose to rename the group "tty" to "dialout" to prevent other users to do the same mistake like me, i.e. confuse both groups due to mixing knowledge from other distros. Michael signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files/hotplug: add "dialout" user group and use it for ttyXYZ devices
Hi, the "tty" group has been introduced exactly for this purpose some time ago (1)(2). Any reason why we need "dialout" as well? ~ Jo 1: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=5523ee3459a2d346ad068ce359cdb60dcda1239d 2: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=124ab1dc0a6235007f60953a796bf29122dfa242 signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/5] build: image: Add pad-to and pad-rootfs-squashfs helpers
On 2019-03-30 07:48, Petr Štetiar wrote: > Felix Fietkau [2019-03-29 18:14:36]: > >> On 2019-03-29 15:07, Petr Štetiar wrote: >> > + >> > +define Image/pad-root-squashfs >> > + $(call Image/pad-to,$(KDIR)/root.squashfs,$(if >> > $(1),$(1),$(CONFIG_TARGET_ROOTFS_PARTSIZE)M)) >> > +endef >> >> The image should only be padded if CONFIG_TARGET_IMAGES_PAD is set. >> Keeping images not padded by default makes them faster to build and >> faster to write to storage on upgrade. > > I've just flashed the combined image to my apu2 and it works as expected, now > I get it why it should be handled differently only for QEMU. Thanks. > >> I think it would be better to write a separate script to pad images to >> partition size for qemu purposes. > > Since I find it quite useful to be able to download the image from snapshots > and use it on QEMU for quick testing, I'm wondering how to handle this use > case properly. > > Should we simply add CONFIG_QEMU_SQUASHFS_IMAGES (enabled by default) and > CONFIG_QEMU_SQUASHFS_PARTSIZE=32 and use this information for generating of > images for QEMU? On armvirt/malta it will simply produce working images based > on this settings, on x86 it will produce two additional images usable in QEMU > as well: I would like to avoid adding generating padded images by default. I just came up with this simple script, which takes an existing image and pads it to full size: http://nbd.name/pad-image.pl With this, shipping padded images should be unnecessary. > openwrt-x86-64-qemu-combined-squashfs.img > openwrt-x86-64-qemu-rootfs-squashfs.img Another semi-related thing: do we really need those separate rootfs images? We could save some download server storage space by dropping them. If necessary, we could make another script like the one above to extract it from the combined image. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/5] build: image: Add pad-to and pad-rootfs-squashfs helpers
Felix Fietkau [2019-03-29 18:14:36]: > On 2019-03-29 15:07, Petr Štetiar wrote: > > + > > +define Image/pad-root-squashfs > > + $(call Image/pad-to,$(KDIR)/root.squashfs,$(if > > $(1),$(1),$(CONFIG_TARGET_ROOTFS_PARTSIZE)M)) > > +endef > > The image should only be padded if CONFIG_TARGET_IMAGES_PAD is set. > Keeping images not padded by default makes them faster to build and > faster to write to storage on upgrade. I've just flashed the combined image to my apu2 and it works as expected, now I get it why it should be handled differently only for QEMU. Thanks. > I think it would be better to write a separate script to pad images to > partition size for qemu purposes. Since I find it quite useful to be able to download the image from snapshots and use it on QEMU for quick testing, I'm wondering how to handle this use case properly. Should we simply add CONFIG_QEMU_SQUASHFS_IMAGES (enabled by default) and CONFIG_QEMU_SQUASHFS_PARTSIZE=32 and use this information for generating of images for QEMU? On armvirt/malta it will simply produce working images based on this settings, on x86 it will produce two additional images usable in QEMU as well: openwrt-x86-64-qemu-combined-squashfs.img openwrt-x86-64-qemu-rootfs-squashfs.img What do you think? -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
