[Patch] NZBGet

RalfFriedl · 27 Jul 2011

@MaxMuster
Schicke nochmal Util.cpp durch den Präprozessor mit exakt den gleichen Optionen, die auch beim Übersetzen des Programms angewendet werden.

Ich denke, er13 hat Recht mit den Host-Includes. Das Layout von struct stat, das man in zwei Beiträgen in der Ausgabe von gdb sehen kann, entspricht dem auf einem i386 System.

Ein möglicher Grund dafür könnte sein, dass configure "hilfreicherweise" /usr/include mit angibt. Zumindest gibt es eine Zeile in configure:

Code:

./configure:  --oldincludedir=DIR     C header files for non-gcc [/usr/include]

Ich habe aber keine Stelle gefunden, wo dieser Wert tatsächlich verwendet wird.

er13 · 27 Jul 2011

oldincludedir wird nirgends verwendet. Wie ich in meinem vorigen Post geschrieben habe, muss LIBPREF gesetzt werden (alternativ könnte man für jede verwendete Library --with-libXYZ-includes und --with-libXYZ-libraries angeben, LIBPREF zu setzen ist aber einfacher). Per Default wird LIBPREF auf /usr gesetzt, was dazu führt, dass -I/usr/include zu den CFLAGS und -L/usr/lib zu den LDFLAGS hinzugefügt wird.

MaxMuster · 27 Jul 2011

Vielen Dank für eure Einmischung, so funktioniert es, soweit ich das Testen konnte, genauso, wie das fertige Binary (ich nutze es nicht, sondern habe es nur übersetzt)
(mit CXX... weg und $(PKG)_CONFIGURE_ENV += LIBPREF="$(TARGET_TOOLCHAIN_STAGING_DIR)/usr").
Ich hänge mal das .mk für die Testing-Version sowie das statisch gelinkte mipsel-Binary mit an, damit das mal jemand Testen kann.

Zu den anderen Punkten:
- "(es hat noch nie zu was gutem geführt host-includes mit target-includes zu mischen)": Hab ich da was verkehrt gemacht, oder war das allgemein gesprochen??
- die vielen LDADDs habe ich eingefügt, weil sonst statisches Linken nicht möglich war (ganz viele unresolved Symbols). Hättest du einen anderen Weg?

Ich frage deshalb, weil ich das gerne schon soweit verstehen möchte, dass ich zumindest diese Fehler demnächst nicht mehr mache..

Danke!

Jörg

er13 · 27 Jul 2011

MaxMuster schrieb:
- "(es hat noch nie zu was gutem geführt host-includes mit target-includes zu mischen)": Hab ich da was verkehrt gemacht, oder war das allgemein gesprochen??

Na ja, wenn man verbose übersetzt, dann sticht dieses -I/usr/include doch sofort ins Auge. Wenn man crosscompiliert, sollte man darauf achten, dass keine Host-Includes/-Libs verwendet werden (mit Libs ist es einfacher, Host-Libs können nicht dazu gelinkt werden -> Build-Fehler). Man kann einfach drüber schauen oder aber auch gezielt nach "-I/usr" greppen.

RalfFriedl · 27 Jul 2011

MaxMuster schrieb:
- "(es hat noch nie zu was gutem geführt host-includes mit target-includes zu mischen)": Hab ich da was verkehrt gemacht, oder war das allgemein gesprochen??

Die Ursache war letztlich, dass auf Dateien in /usr/include zugegriffen wurde, also auf Host-Header. Ich würde nicht sagen, dass Du aktiv etwas falsch gemacht hast. Das Problem ist, dass das configure Skript ungefragt /usr/include (und /usr/lib) als Pfade explizit angibt. Wenn man das Programm normal übersetzt, dann ist das nur absolut unnötig, weil diese Pfade sowieso schon verwendet werden. Und wenn man für ein anderes Ziel-System übersetzt, dann ist das sehr schlecht.

Vermutlich wäre es das geschickteste, diese LIBPREF Logik aus dem configure ganz zu entfernen.

srup · 27 Jul 2011

Das ist genau das Problem, welches ich in einem früheren Beitrag erwähnt hatte. Ich nahm allerdings an, daß MaxMustermann es bereits gelöst hatte.

Müssen nicht die Pfade für libxml2 und libsigc++ auch noch angepasst werden, soweit ich sehe greift er da immer noch relativ zu /usr drauf zu (oder es liegt an meiner Kopie/Konfig)?

MaxMuster · 27 Jul 2011

Also die libxml2 ist ja schon "eh da", wenn, dann war die schon immer "verkehrt".
Für die beiden hier neuen Libs (libpar2 und libsig++) finde ich im Makefile nix verdächtiges:

Code:

joerg@joerg-desktop:/ramdisk/freetz-trunk/source/target-mipsel_uClibc-0.9.29/libsigc++-2.2.8$ grep '\-[IL]' Makefile
ACLOCAL_AMFLAGS = -I build ${ACLOCAL_FLAGS}
joerg@joerg-desktop:/ramdisk/freetz-trunk/source/target-mipsel_uClibc-0.9.29/libsigc++-2.2.8$ cd ../libpar2-0.2/
joerg@joerg-desktop:/ramdisk/freetz-trunk/source/target-mipsel_uClibc-0.9.29/libpar2-0.2$ grep '\-[IL]' Makefile
DEFAULT_INCLUDES = -I. -I$(srcdir) -I.
SIGC_CFLAGS = -I/ramdisk/freetz-trunk/toolchain/build/mipsel_gcc-4.4.6_uClibc-0.9.29/mipsel-linux-uclibc/usr/include/sigc++-2.0 -I/ramdisk/freetz-trunk/toolchain/build/mipsel_gcc-4.4.6_uClibc-0.9.29/mipsel-linux-uclibc/usr/lib/sigc++-2.0/include  
SIGC_LIBS = -L/ramdisk/freetz-trunk/toolchain/build/mipsel_gcc-4.4.6_uClibc-0.9.29/mipsel-linux-uclibc/usr/lib -lsigc-2.0  
joerg@joerg-desktop:/ramdisk/freetz-trunk/source/target-mipsel_uClibc-0.9.29/libpar2-0.2$

Als Danke mal das statisch gebaute MIPS-Binary, um ncurses zu nutzen, braucht man dann noch die terminfo-Dateien auf der Box und muss ggf. TERMINFO setzen...

srup · 27 Jul 2011

Danke für deine Mühe

Ich muss erstmal meine neue Box mit Freetz aufsetzen um es auszuprobieren...

MaxMuster · 28 Jul 2011

Also theoretisch solle es auch ohne Freetz funktionieren, ggf. mit einem „Outputmode“ ungleich curses.

srup · 28 Jul 2011

Hallo,

so habe mal die Box gefreezt. Wie ich sehe, ist es die stable (0.7), diese benötigt einen Patch damit der ParCheck auf einer BigEndian CPU (OpenWRT Bug #8749) auch funktioniert. In der 0.8 ist dieser bereits integriert. Hast Du den Patch drin? Hatte jetzt nur eine kleine Datei ohne PARs getestet...

mfG.

MaxMuster · 28 Jul 2011

Du meinst wohl Ticket #8479, denke ich? Ist der Patch für mipsel "unschädlich", so dass der Patch immer angewandt werden kann?
Ich hänge aber mal die 0.8.0-testing Version an, damit sollte es dann ja gehen.

Jörg

srup · 28 Jul 2011

Ich muss mich korrigieren, der Patch ist ja für libpar und nicht für nzbget und muß natürlich dann auch angewandt werden.

EDIT: Ja, 0.8 schlägt beim check fehl. Hatte den Patch bereits auf meiner Kopie angewandt, es vergessen, und dachte daher er wäre schon drin...

EDIT: Hab's gerade mal ausprobiert, mit dem Patch funktionert der parcheck. Reparieren ist nicht getestet, da die Datei ganz war...

sgn · 24 Mai 2012

leider hab ich bisher nirgendwo gefunden wie da sganze auf der box installiert werden kann. ich hab das mipsel-image gezogen. muss ich das jetzt genauso wie fritzload per firmware-image einspielen? ich hab kein freetz drauf und auch kein telefon angeschlossen (wegen telnet), sollte doch aber auch so gehen. ist das webinterface von der sourceforge-seite auch für das fritzbox-image gedacht und kann ich es genauso wie nzbget installieren?

MaxMuster · 8 Feb 2014

Als "Update" mal die aktuellen 12.0-er Binaries und ein patch zum Bauen mit Freetz.

er13 · 8 Feb 2014

Hallo Jörg,

blöde Frage, warum committest Du es nicht? Spricht etwas dagegen?

Grüße,
Gene

MaxMuster · 8 Feb 2014

Ich hab da einmal einen "blöden Hack" drin: Die libpar2 benötigt Patches, und die sind immer im nzbget-Source drin. Ich hab die jetzt händisch soweit angepasst und reinkopiert.

Zum andern hatte ich eben einen "merkwürdigen Fehler", auch bei der "libpar2":

Code:

[...]
par1fileformat.h:56:15: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash PAR1FILEENTRY::hashfull' [enabled by default]
par1fileformat.h:57:15: warning: ignoring packed attribute because of unpacked non-POD field 'MD5Hash PAR1FILEENTRY::hash16k' [enabled by default]
par1fileformat.h:58:20: warning: ignoring packed attribute because of unpacked non-POD field 'leu16 PAR1FILEENTRY::name [0]' [enabled by default]
In file included from /run/shm/freetz-trunk/toolchain/build/mips_gcc-4.7.3_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/include/uClibc++/vector:25:0,
                 from /run/shm/freetz-trunk/toolchain/build/mips_gcc-4.7.3_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/include/uClibc++/string:25,
                 from par2cmdline.h:239,
                 from mainpacket.cpp:20:
/run/shm/freetz-trunk/toolchain/build/mips_gcc-4.7.3_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/include/uClibc++/algorithm: In instantiation of 'void std::sort(RandomAccessIterator, RandomAccessIterator, Compare) [with RandomAccessIterator = Par2CreatorSourceFile**; Compare = bool (*)(const Par2CreatorSourceFile* const&, const Par2CreatorSourceFile* const&)]':
mainpacket.cpp:54:84:   required from here
/run/shm/freetz-trunk/toolchain/build/mips_gcc-4.7.3_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/include/uClibc++/algorithm:836:3: error: 'stable_sort' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
/run/shm/freetz-trunk/toolchain/build/mips_gcc-4.7.3_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/include/uClibc++/algorithm:847:8: note: 'template<class RandomAccessIterator, class Compare> void std::stable_sort(RandomAccessIterator, RandomAccessIterator, Compare)' declared here, later in the translation unit
make[2]: *** [mainpacket.lo] Fehler 1
make[2]: Verlasse Verzeichnis '/run/shm/freetz-trunk/source/target-mips_gcc-4.7.3_uClibc-0.9.33.2-nptl/libpar2-0.2'
make[1]: *** [all] Fehler 2
make[1]: Verlasse Verzeichnis '/run/shm/freetz-trunk/source/target-mips_gcc-4.7.3_uClibc-0.9.33.2-nptl/libpar2-0.2'

ERROR: Build failed.
make: *** [source/target-mips_gcc-4.7.3_uClibc-0.9.33.2-nptl/libpar2-0.2/.libs/libpar2.so.0.0.1] Fehler 1
[...]

"error: 'stable_sort' was not declared in this scope" hab ich bei Google immer nur bei fehlendem include von algorithm gefunden.

Ich muss gestehen, das habe ich nicht ganz verstanden, weil "stable_sort" in algorithm ja drin ist, auch in std.

Konnte es aber "quick and dirty" umgehen, indem ich im uClibc++-Source(!) in der include-Datei algorithm die Reihenfolge so geändert hatte, dass ich "stable_sort" vor den Aufruf in "sort" verschoben hatte:

Code:

--- toolchain/build/mips_gcc-4.7.3_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/include/uClibc++/algorithm~	2014-02-08 13:31:38.204788303 +0100
+++ toolchain/build/mips_gcc-4.7.3_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/include/uClibc++/algorithm	2014-02-08 14:16:06.684768616 +0100
@@ -823,6 +823,24 @@
 		return first;
 	}
 
+	template<class RandomAccessIterator, class Compare> _UCXXEXPORT
+		void stable_sort(RandomAccessIterator first, RandomAccessIterator last, Compare comp)
+	{
+		//FIXME - bubble sort
+		RandomAccessIterator temp;
+		--last;
+		while(last - first > 0){
+			temp = last;
+			while(temp != first){
+				if( comp( *temp, *(temp-1) ) ){
+					iter_swap( temp-1, temp);
+				}
+				--temp;
+			}
+			++first;
+		}
+	}
+
 	template<class RandomAccessIterator> _UCXXEXPORT
 		void sort(RandomAccessIterator first, RandomAccessIterator last)
 	{
@@ -843,24 +861,6 @@
 		stable_sort(first, last, c);
 	}
 
-	template<class RandomAccessIterator, class Compare> _UCXXEXPORT
-		void stable_sort(RandomAccessIterator first, RandomAccessIterator last, Compare comp)
-	{
-		//FIXME - bubble sort
-		RandomAccessIterator temp;
-		--last;
-		while(last - first > 0){
-			temp = last;
-			while(temp != first){
-				if( comp( *temp, *(temp-1) ) ){
-					iter_swap( temp-1, temp);
-				}
-				--temp;
-			}
-			++first;
-		}
-	}
-
 	template<class RandomAccessIterator> _UCXXEXPORT
 		void partial_sort(RandomAccessIterator first, RandomAccessIterator middle, RandomAccessIterator last)
 	{

Das wollte ich erst nochmal genauer prüfen, vielleicht liegt es an einer neueren gcc-Version oder an meiner Toolchain ist was "komisch", oder ...

er13 · 8 Feb 2014

Es hat was mit gcc-4.7 zu tun. S. unter Name lookup changes bzw. bug 24163. Damit ist Deine Änderung der Reihenfolge ein völlig legitimer bzw. korrekter Fix, der auch commitet gehört (separat versteht sich ;-))

MaxMuster · 8 Feb 2014

Oha, wenn ich allein in algorithm schaue, sind da aber sehr viele "Reihenfolgen falsch":
search, search_n, partition, usw.
Auch bei "sort" selbst kommt nochmal sort(f, l) vor sort(f, l, c), obwohl das erstere auf das zweite verweist?!?

er13 · 8 Feb 2014

Wenn viele Reihenfolgen falsch sind, so könntest Du bitte ein entsprechendes Ticket erstellen, wo alle Anpassungen gesammelt werden, ggf. macht es Sinn, das Problem upstream zu melden.

Bis dahin versuche libpar2 mit -fpermissive zu übersetzen, so wie es unter "Name lookup changes" vorgeschlagen wird.

MaxMuster · 8 Feb 2014

Ticket hab ich geöffnet, versuche das mal mit "algorithm" bis zum Ende durchzuziehen, aber heute vermutlich nicht mehr ;-) .

[Patch] NZBGet

IPPF-Urgestein

Aktives Mitglied

IPPF-Promi

Anhänge

Aktives Mitglied

IPPF-Urgestein

Mitglied

IPPF-Promi

Anhänge

Mitglied

IPPF-Promi

Mitglied

IPPF-Promi

Anhänge

Mitglied

Neuer User

IPPF-Promi

Anhänge

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

IPPF-Promi

Statistik des Forums