Subversion auf Fritzbox

[Luemmel]

Nachdem ich nun auch eine funktionierende Toolchain habe, versuche ich im Moment svnserve,svnadmin und svn zu bauen. Leider scheitert er schon an den apr-includes mit dem Fehler

[matthias@buzz subversion-1.1.4]$ make svnserve
mipsel-linux-gcc -DLINUX=2 -D_REENTRANT  -g -O2  -g -O2   -I./subversion/include -I./subversion -I/home/matthias/Desktop/subversion-1.1.4/neon/src -I/usr/local/include/neon -I/home/matthias/Desktop/subversion-1.1.4/apr/include   -I/home/matthias/Desktop/subversion-1.1.4/apr-util/include -I/home/matthias/Desktop/subversion-1.1.4/apr-util/xml/expat/lib -o subversion/svnserve/main.o -c subversion/svnserve/main.c
In file included from /home/matthias/Desktop/subversion-1.1.4/apr/include/apr_want.h:17,
                 from subversion/svnserve/main.c:22:
/home/matthias/Desktop/subversion-1.1.4/apr/include/apr.h:341:2: error: #error Can not determine the proper size for ssize_t
/home/matthias/Desktop/subversion-1.1.4/apr/include/apr.h:344:2: error: #error Can not determine the proper size for size_t

Daher meine Frage: Wie habt ihr überhaupt Subversion gebaut?

Und ja: BDB ist nicht drin, dafür gibt es einen configure-switch bzw. sucht autoconf auch nach den Libs auf dem System, wenn diese nicht vorhanden sind, funktioniert nur FSFS.

 

[Goodbyte]

Ich hab auch grad mal versucht, Subversion in einer Knoppix5.0-VM zu bauen, bin aber schon am configure gescheitert.

./configure --with-berkeley-db=/usr/lib --build=i386-linux-gnu --target=mipsel-linux --host=mipsel-linux

führt zu

checking whether setpgrp takes no argument... configure: error: cannot check setpgrp when cross compiling
configure failed for apr

apr, apr-util, etc. sind (durch das subversion-dep-Paket) alle da.
Was bedeutet denn der Fehler und wie kann man den wegbekommen?

 

[Luemmel]

Hi Goodbyte,

ich würde erst mal versuchen, svn ohne bdb zu bauen. Den Fehler, den Du bekommst, hatte ich auch. Er kommt daher, dass bestimmte Tests, die autoconf automatisch ausführt, nicht gemacht werden können, da du ja nicht auf der Zielplattform kompilierst. Deinen oben beschriebenen Fehler kannst Du einfach abstellen, in dem Du configure wie folgt aufrufst:

env ac_cv_func_setpgrp_void=yes ./configure --build=i386-linux-gnu --target=mipsel-linux --host=mipsel-linux

Das setzt die Variable von vornherein auf einen bestimmten Wert und autoconf lässt den Test weg.

Außerdem würde ich Dir empfehlen, nicht die SVN 1.4.0 zu nehmen, ich bin dabei jedenfalls in Probleme mit der zlib gelaufen. 1.3.2 läuft zumindest durchs configure durch.

Luemmel

Aber hier nochmal die Frage: Wie habt ihr SVN überhaupt kompilieren können?

 

[Salgar]

svn kompilieren

Hallo,
ich habe subversion ohne berkdb-support gebaut, weil ich ein fsfs-repository habe, das ich auf die fritzbox bringen will. Leider hatte ich seit dem compilieren von svn keine Zeit mehr weiterzubasteln.

Habe mir damals einige Notizen gemacht, als ich subversion kompiliert habe. Habe zuerst eine toolchain erstellt mit dem ds mod, dann subversion 1.4 aus dem repository geholt. Hier meine Notizen:

CC="/data/fritzbox/ds-0.2.9/toolchain/target/bin/mipsel-linux-uclibc-gcc"
CXX="/data/fritzbox/ds-0.2.9/toolchain/target/bin/mipsel-linux-uclibc-c++"
PATH=/data/fritzbox/ds-0.2.9/toolchain/build/gcc-4.1.0-uClibc-0.9.26/mipsel-linux-uclibc/bin:/bin:/sbin:/usr/bin:/usr/sbin

cd /data/fritzbox/ds-0.2.9/toolchain/build/gcc-4.1.0-uClibc-0.9.26/mipsel-linux-uclibc/usr/include
cp z* ../../mipsel-linux-uclibc/sys-include/

cd /data/fritzbox/ds-0.2.9/toolchain/build/gcc-4.1.0-uClibc-0.9.26/mipsel-linux-uclibc/usr/lib
cp libz* ../../mipsel-linux-uclibc/lib/

./configure --build=i686-linux-gnu --target=mipsel-linux --host=mipsel-linux --prefix=/home/phits/fritzboxsvn/ --without-apache --without-neon --without-berkeley-db --without-apxs --without-apache --without-serf --without-ssl --without-jdk --without-jikes --without-swig --without-junit

in apr/include/apr.h
SIZE_T und SSIZE_T auf "d" stellen (fehlermeldung löschen.

expat in apr/xml/expat erstellen (configure --prefix=/data/fritzbox/ds-0.2.9/toolchain/build/gcc-4.1.0-uClibc-0.9.26/mipsel-linux-uclibc/usr/ , make, make install)
dann includes und libs kopiere wie bei zlib oben.

make

cd subversion/svn && /bin/sh /data/fritzbox/ds-0.2.9/subversion/subversion-1.4.0/libtool --tag=CC --silent --mode=link mipsel-linux-gcc  -g -O2  -g -O2   -rpath /home/phits/fritzboxsvn//lib -o svn  add-cmd.o blame-cmd.o cat-cmd.o checkout-cmd.o cleanup-cmd.o commit-cmd.o copy-cmd.o delete-cmd.o diff-cmd.o export-cmd.o help-cmd.o import-cmd.o info-cmd.o list-cmd.o lock-cmd.o log-cmd.o main.o merge-cmd.o mkdir-cmd.o move-cmd.o notify.o propdel-cmd.o propedit-cmd.o propget-cmd.o proplist-cmd.o props.o propset-cmd.o resolved-cmd.o revert-cmd.o status-cmd.o status.o switch-cmd.o unlock-cmd.o update-cmd.o util.o ../../subversion/libsvn_client/libsvn_client-1.la ../../subversion/libsvn_wc/libsvn_wc-1.la ../../subversion/libsvn_ra/libsvn_ra-1.la ../../subversion/libsvn_delta/libsvn_delta-1.la ../../subversion/libsvn_diff/libsvn_diff-1.la ../../subversion/libsvn_subr/libsvn_subr-1.la /data/fritzbox/ds-0.2.9/subversion/subversion-1.4.0/apr-util/libaprutil-0.la -lexpat /data/fritzbox/ds-0.2.9/subversion/subversion-1.4.0/apr/libapr-0.la /data/fritzbox/ds-0.2.9/build/original/filesystem/lib/libpthread.so -lm -lcrypt -lnsl  -ldl  -lz

svn-revision.txt suchen in Makefile und auskommentieren.
make install

PS: Pfade entsprechend anpassen
In /data/fritzbox/ds-0.2.9/ liegt bei mir der dsmod.
/home/phits/fritzboxsvn/ ist das vz, in dem die svn-binaries landen sollten.

 

[Luemmel]

Hi,

@Salgar: kurz nachdem ich Dir geschrieben hatte, habe ich dann auch begriffen, dass der Fehler im Source absichtlich provoziert wurde durch den Preprozessor (steht ja schließlich im Code!) Allerdings habe ich beide durch "ld" ersetzt.

Im Moment teste ich noch, aber es sieht alles recht gut aus. Bis zu meinem ersten svnadmin ist es nicht mehr weit

Andere Frage: Bist Du sicher, dass Du beim configure so viele Sachen wirklichen Abschalten musst? Wie siehts mit den defaults dafür aus?

Ausserdem ist mir noch nicht ganz klar, warum du nicht die autoconf Variable func_setpgrp_void auf cached setzten musst. Bei mir gibt's anderenfalls einen Abbruch.
Ich hab's jetzt mal so geconft wie Du und schaue mal, was dabei rauskommt.

 

[Goodbyte]

Hab hier ein ähnliches Problem wie vorher schon mal. Diesmal geht der Test "checking for working PROCESS_SHARED locks..." schief wegen cross-compiling.

Ich denke mal, da gibt es wieder 'ne tolle Umgebungsvariable die ich setzen muß - aber wie bekommt man raus, wie sie heißen muß??? Bitte nicht nur schreiben, wie sie heißt, sondern auch wo man das rausbekommt. Dann muß ich hier nicht jedesmal fragen

 

[Salgar]

Andere Frage: Bist Du sicher, dass Du beim configure so viele Sachen wirklichen Abschalten musst? Wie siehts mit den defaults dafür aus?

Einiges davon ist bestimmt per default schon aus. Aber wozu nachschauen, so kann ich sicher sein, dass es aus ist. Ich habe mir wie gesagt ein subversion gebaut, das meinen Anforderungen entspricht, da brauchte ich den ganzen apache-(sehe grade, der switch ist doppelt bei meinem configure-aufruf), apx-, neon-kram und berkdb etc. nicht.
Ausserdem: Erstmal mit einer minimalen Konfiguration überhaupt zum laufen bringen, als mit allem mögl. Schnick-Schnack gar nicht

Ausserdem ist mir noch nicht ganz klar, warum du nicht die autoconf Variable func_setpgrp_void auf cached setzten musst. Bei mir gibt's anderenfalls einen Abbruch.

Es kann sehr gut sein, das meine Notizen nicht vollständig sind.

Viele Grüße

Salgar

 

[Luemmel]

Bin leider mit dem Problem beim FSFS nicht weitergekommen. Daher habe ich mich entschieden eine Version mit Berkeley DB zu bauen.

Subversion 1.4.2 mit Berkeley DB 4.5.20.

In dem Archiv befinden sich Subversion inklusive der benötigten Libs und ein Verzeichnis xtralibs, welches ein paar Bibliotheken enthält, die einige vielleicht ohnehin schon haben. Diese wollte ich nicht direkt ins Subversionverzeichnis kippen.

Lümmel

 

[lord-of-linux]

Funktioniert diese Binary dann?

 

[Luemmel]

Ich würde nichts posten, wenn ich es nicht getestet hätte

 

[lord-of-linux]

OK, dass werde ich mal probieren. Allerdings nicht mehr heute.

Wie ist es den bei den BDB's mit Backups? Weil FSFS lässt sich ja locker kopieren.

 

[Luemmel]

Wie ist es den bei den BDB's mit Backups? Weil FSFS lässt sich ja locker kopieren.

Problemlos. Einfach das komplette Verzeichnis kopieren. Bin damit noch nie auf Probleme beim Wiederherstellen gestoßen.

 

[Goodbyte]

Einen Haken gibts leider an BDB: Es ist nicht portabel
Also nix mit Repository von der Box runterholen und auf oder Laptop schieben und dort weiterarbeiten oder so...

 

[Goodbyte]

Bin leider mit dem Problem beim FSFS nicht weitergekommen. Daher habe ich mich entschieden eine Version mit Berkeley DB zu bauen.
Subversion 1.4.2 mit Berkeley DB 4.5.20.

Kannst du mir kurz erklären, wie du das gemacht hast? Ich bin ja leider bei dem PROCESS_SHARED im configure hängen geblieben.
Ich würde nämlich gerne einige Sachen anders kompilieren (BDB 4.3, wie empfohlen; fs_fs raus wenn es denn eh nicht geht; fs_local raus; wc und subr evtl. auch raus - müßte mich erkundigen, wofür die sind) und auch mal mein Glück am FSFS versuchen...

 

[Luemmel]

Verstehe nicht ganz wo das Problem der Portabilität bei BDB besteht. Ich teste heute mal das Repo auf einen Linuxrechner zu kopieren und von dort zu serven. Abgesehen davon sucht Subversion nach 4.4. Da gabs allerdings Probleme oder wollte ich dann einfach nicht mehr?

Die Erklärung wie ich das gemacht habe, kommt später, weil ich im Moment ein wenig eingespannt bin und das ganze nur so nebenher läuft. Notizen sind da, allerdings nur für mich verständlich Falls Du eine spezielle Konfiguration brauchst, kannst Du mir bescheidsagen, am besten mit den switches für's configure. Ich bau das dann einfach und schick's Dir zum Testen.

Lümmel

 

[Goodbyte]

ALso ich hab es gestern abend mal versucht, ein BDB-Repository von der Box auf mein Windows zu bringen, und das war danach nicht mehr benutzbar. Kann aber möglicherweise auch andere Gründe haben.
Wie sieht es denn bei PC und Box mit der Byte-order aus? Sind beide Little Endian? Das ist wohl bei BDB irgendwie kritisch (aber irgenwdie wohl auch nicht... keine Ahnung...), läßt sich aber im aufrufenden Code (also SVN-Server) vernünftig setzen, so dass es kein Problem mehr ist:
BDB Dokumentation: Selecting a byte order

 

[Luemmel]

Wie sieht es denn bei PC und Box mit der Byte-order aus? Sind beide Little Endian? Das ist wohl bei BDB irgendwie kritisch (aber irgenwdie wohl auch nicht... keine Ahnung...), läßt sich aber im aufrufenden Code (also SVN-Server) vernünftig setzen, so dass es kein Problem mehr ist:
BDB Dokumentation: Selecting a byte order

Im svnserve werde ich sicher nichts verändern. Der Link zeigt unter anderem einen API-Befehl, den man dazu nutzen könnte, aber wie gesagt, keine Dinge im Source ändern, das macht nur Ärger bei einer neuen Version.

MIPS ist Big- und x86 Little-Endian, insofern könnte es da ein Problem geben. Allerdings hoffe ich, ohne nachgesehen zu haben, dass Subversion das Ablegen auf beiden Plattformen identisch handhabt, d.h. also intern sich auf eine Reihenfolge einigt. Das wäre vor allem wünschenswert, da es nicht nur little und big sondern auch true-little-endian Systeme gibt. Getestet habe ich es noch nicht. Folgt noch.

 

[Goodbyte]

Ich hatte auch irgendwie im Kopf, dass es die Byte-Order unterschiedlich ist, allerdings ist ja beim kompilieren ständig was mit "mipsel" - was laut Wikipedia eine MIPS-Architektur mit Little Endian bezeichnet...
Naja... warten wir mal deinen Test ab...

 

[Luemmel]

Hab nun die Zeit gefunden, mal ein paar Tests durchzuführen. Das direkte Übertragen funktioniert leider nicht, aber nicht, weil es Architekturprobleme gibt, sondern weil BDB es wohl einfach nicht mag. Nachzulesen hier (unter Important Note): http://artis.imag.fr/~Xavier.Decoret/resources/svn/index.html
Glücklicherweise gibt er auch eine einfache Lösung, falls das Repo tatsächlich mal umziehen muss, nämlich durch einen einfach Dump. Da ich alle Tools mitgeliefert habe, kann man das also auch machen. Habe ich ebenfalls erfolgreich getestet. In der Zwischenzeit habe ich auch eine Version kompiliert, die SVN 1.4.2 und BDB 4.4.20 nutzt, da das wohl die offiziellen Versionen sind, die am liebsten zusammen spielen

 

[Goodbyte]

Das Problem, was dort geschildert wird, ist aber ein anderes als bei mir. Dort geht es darum, dass das Repository auf einem Netzwerk-Laufwerk liegt und der Server übers Netzwerk auf das Repository zugreift. Das ist steht so auch im SVNBook (liegt wohl irgendwie an fehlenden Locking-Möglichkeiten oder so).
Bei mir ist es aber das Szenario, dass das Repository von der Box per Stick auf den PC/Laptop gebracht wird und da direkt drauf zugegriffen werden kann. Also nirgends ein Netzwerk-Laufwerk.

Wollte es grade nochmal mit deiner neuen Version versuchen, aber da fehlt leider (mindestens) die libdb-4.4.so. Kannste die bitte nochmal posten?