make: Fehler 1 u. 2 / error 1 u. 2 - grundsätzliche Fragen

[Systemcrasher]

Hallo Leute,

ich habe ein einigermaßen ärgerliches Problem mit "make".

Beim Kompilieren von Quellcodes ist die übliche Vorgehensweise ja diese (nach dem Entpacken in ein temporäres Verzeichnis):

Wechsel ins betreffende Verzeichnis

./configure

(hier sind meist erst mal ein paar Abhängigkeiten zu lösen)

make

make install.

Leider tritt bei einer ganzen Reihe von Paketen der o.g. Fehler bereits beim Aufruf von make auf.

Zwar gibt es alleine zu "make" und "error" bisher 104 Beiträge alleine hier, aber die beziehen sich alle auf spezielle Paketprobleme, die meist dadurch gelöst wurden, daß die Pakete mit Yast u.ä. installiert wurden.

Das hilft mir jedoch nicht wirklich weiter, da die Probleme v.A. beim Kompilieren unter Deli auftreten.

Vor kurzem habe ich auch dort mal nachgefragt: http://www.delilinux.org/forum/topic.php?id=1154, bisher konnte jedoch keiner helfen.

Ich möchte hier keine Diskussionslawine lostreten und für jedes Paket extra fragen, sondern einfach nur eine grundsätzliche Hilfe dazu, um dann eigenständig derartige Probleme zu lösen.

Was sind die grundsätzlichen Ursachen für derartige Fehlermeldungen und wie kann man sie beheben?

Fehlende Abhängigkeiten können es ja keine sein, denn dann hätte./configure ja bereits gemeckert.

Leider habe ich dazu bisher nichts für mich Verständliches "ergoogeln" können.

Vielen Dank schon für Eure Hilfe...

 

[Anonymous]

Leider ist nicht ganz ersichtlich was du genau für Fehler meinst. Währe nett wenn du mal ein paar solcher Fehler hier rein setzt.

Prinzipiell ist es so. Normalerweise laufen mehr als ein make.
make[1] Das ist der make-Prozess der direkt vom User angestartet wird und im Ausgangsverzeichnis die Makefile dort abarbeitet. Von dort aus startet dieser make-Prozess weitere selbständig laufenden make-Prozesse in den Unterverzeichnissen die die dort befindliche Makefile abarbeiten und wartet darauf das sie fertig sind. Diese laufen dann als make[2]. Sind dort auch noch Unterprojekte oder Unterverzeichnisse mit eigenen Makefile, dann wird auch noch make[3] ...... gestartet. Kommt ein make[2] als "ok" wieder zurück, dann macht make[1] in seiner Makefile weiter und startet eventuell einen weiteren make[2] in einem anderem Unterverzeichnis. usw.

Läuft irgend ein make beim kompilieren einer Datei, beim Linken oder wie auch immer auf einen Fehler. (Sagen wir mal make[2]) , dann entstehen dort erstmal ein paar Meldungen die den Fehler einigermaßen gut oder schlecht beschreiben. Wie gut und ausführlich die Meldungen jetzt ausfallen, ist vom Fehler selbst abhängig und von den Einstellungen mit denen die einzelnen Stufen von gcc und zT. auch noch dort gestartete andere Befehle aufgerufen wird. Normalerweise werden bei Warnungen diese auch nur als Warung ausgegeben, der Prozess läuft aber weiter, und bei einem Fehler bricht make dann mit Fehler ab. (in diesem Fall ist es make[2]) Darauf hin meldet sich make[1] auch noch mit Fehler, da er ja make[2] gestartet hat und dieser einen Fehler gemeldet hat.

( Normalerweise desshalb, da auch das theoretisch auch überschrieben sein könnte, und zB erst nach mehreren Fehler der entgülte Abbruch konfiguriert sein könnte, oder Warungen könnten auch schon zum Abbruch führen, oder es kann auch mit mehreren make-Prozessen paralell gearbeitet werden, was dann zB. einen Sinn macht, wenn man mehrere Prozessorkerne hat. In diesem Fall ist der urspüngliche Fehler der das kompilieren des gesammten Programmes verhindert, erstmal gar nicht so schnell zu finden, da die anderen Prozesse erst noch weiterlaufen bis sie auch auf Fehler laufen oder fertig sind.)

Ein Fehler in make[3] erzeugt also anschließen zwangsläufig immer erst noch einen Fehler make[2] und dieser denn einen Fehler make[1] eh der gesamte Prozess angehalten wird. Die eigentliche Fehlermeldung mit der das Problem losgeht, steht also nie am Ende sondern immer weiter oben.

robi

 

[Systemcrasher]

Leider ist nicht ganz ersichtlich was du genau für Fehler meinst. Währe nett wenn du mal ein paar solcher Fehler hier rein setzt.

Prinzipiell ist es so. Normalerweise laufen mehr als ein make.
make[1] Das ist der make-Prozess der direkt vom User angestartet wird und im Ausgangsverzeichnis die Makefile dort abarbeitet. Von dort aus startet dieser make-Prozess weitere selbständig laufenden make-Prozesse in den Unterverzeichnissen ....
Läuft irgend ein make beim kompilieren einer Datei, beim Linken oder wie auch immer auf einen Fehler. (Sagen wir mal make[2]) , dann entstehen dort erstmal ein paar Meldungen die den Fehler einigermaßen gut oder schlecht beschreiben. ... ...
Ein Fehler in make[3] erzeugt also anschließen zwangsläufig immer erst noch einen Fehler make[2] und dieser denn einen Fehler make[1] eh der gesamte Prozess angehalten wird. Die eigentliche Fehlermeldung mit der das Problem losgeht, steht also nie am Ende sondern immer weiter oben.

robi

Hallo robi,

zunächst mal herzlichen Dank für die exzellente und sehr verständliche Erklärung.

Warum ich mir erstmal ein Beispiel verkniffen hat, liegt einfach daran, daß ich zunächst mal eine ganz allgemeine und grundsätzliche Antwort wollte, denn wenn ich das schon nicht verstehe, brauche ich mit dem Rest erst gar nicht anzufangen.

Wenn ich das also richtig verstanden habe, dann läßt die Fehlerziffer Rückschlüsse auf die "make-Ebene" zu, d.h., ein "error 2" z.B. bedeutet, daß ein Fehler bei "make 2" liegt, welches selbst wiederum einen "error 1" ausgibt.
Da "make 2" diesen auch an "make 1" weitergibt, gibt es dann logischerweise auch einen "error 1", der aber nur deshalb entstanden ist, weil "make 1" von "make 2" eine Fehlermeldung bekam und deshalb ebenfalls abgebrochen ist.

Demnach sind diese Fehler kein Hinweis auf die Art des Fehlers, sondern lediglich ein Hinweis auf die Quelle, also ein makefile.

Delix hat hier

http://www.delilinux.org/forum/topic.php?id=964&usebb_sid=a61f20c5e989bd69fa88bd0a3b6e3865

auf ein Problem bei der Paketerstellung unter Deli hingewiesen, welches gelegentlich beim Pakete schnüren auftritt. Man muß bisweilen Verzeichnispfade abändern.
Eine ähnliche Ursache könnte also auch beim Kompilieren für diese Fehlermeldungen verantwortlich sein.

Nun zum konkreten Beispiel (Installation von wdfs):

Making all in src
make[1]: Entering directory `/wdfs-1.4.2/src'
make  all-am
make[2]: Entering directory `/wdfs-1.4.2/src'
gcc  -g -O2 -D_LARGEFILE64_SOURCE -DNE_LFS -D_FILE_OFFSET_BITS=64 -I/usr/local/include/neon -I/usr/include/fuse -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -Wall -D_GNU_SOURCE -D_REENTRANT   -o wdfs  cache.o svn.o wdfs-main.o webdav.o  -pthread /usr/lib/libiconv.so -L/usr/local/lib -lfuse -ldl -lneon -lglib-2.0 -lintl -liconv  
/usr/local/lib/libneon.a(ne_xml.o): In function `ne_xml_currentline':
/neon-0.29.3/src/ne_xml.c:196: undefined reference to `XML_GetCurrentLineNumber'
/usr/local/lib/libneon.a(ne_xml.o): In function `entity_declaration':
/neon-0.29.3/src/ne_xml.c:421: undefined reference to `XML_StopParser'
/usr/local/lib/libneon.a(ne_xml.o): In function `ne_xml_create':
/neon-0.29.3/src/ne_xml.c:476: undefined reference to `XML_ParserCreate'
/neon-0.29.3/src/ne_xml.c:480: undefined reference to `XML_SetElementHandler'
/neon-0.29.3/src/ne_xml.c:481: undefined reference to `XML_SetCharacterDataHandler'
/neon-0.29.3/src/ne_xml.c:482: undefined reference to `XML_SetUserData'
/neon-0.29.3/src/ne_xml.c:483: undefined reference to `XML_SetXmlDeclHandler'
/neon-0.29.3/src/ne_xml.c:493: undefined reference to `XML_SetEntityDeclHandler'
/usr/local/lib/libneon.a(ne_xml.o): In function `ne_xml_parse':
/neon-0.29.3/src/ne_xml.c:588: undefined reference to `XML_Parse'
/neon-0.29.3/src/ne_xml.c:591: undefined reference to `XML_GetErrorCode'
/neon-0.29.3/src/ne_xml.c:591: undefined reference to `XML_ErrorString'
/neon-0.29.3/src/ne_xml.c:591: undefined reference to `XML_GetCurrentLineNumber'
/usr/local/lib/libneon.a(ne_xml.o): In function `ne_xml_destroy':
/neon-0.29.3/src/ne_xml.c:640: undefined reference to `XML_ParserFree'
collect2: ld returned 1 exit status
make[2]: *** [wdfs] Fehler 1
make[2]: Leaving directory `/wdfs-1.4.2/src'
make[1]: *** [all] Fehler 2
make[1]: Leaving directory `/wdfs-1.4.2/src'
make: *** [all-recursive] Fehler 1

Hier liegt der Fehler also in einem make, das vom "Vater-make" aufgerufen wurde, also "make 2".

Anscheinend hat das mit irgendwas vom "neon-Paket" zu tun, irgendwas ist hier nicht (richtig) definiert.

der Aufruf von "make" verändert / erzeugt eine Reihe von Dateien, diese sollten demnach als Fehlerursache ausscheiden. Der Fehler liegt also entweder in den von "./configure" oder (wahrscheinlicher) in jenen Dateien, die nicht verändert wurden.

Das könnte also z.B. "makefile.in" sein, oder "install-sh".

Wie kann ich erkennen, welches das eigentliche "Vater-make" ist?

Dort müßte ja irgendwo auf die "Sohn-Make" verwiesen werden.

 

[Anonymous]

Ich versuche mal den orbrigen Fehler anhand dieser Ausgabe Schritt für Schritt zu analysieren um dir zu zeigen wie man an sowas überhaupt erstmal rangeht um den Fehlern bei make auf die Schliche zu kommen.

im Verzeichnis :"/wdfs-1.4.2/src"
ist bei der Ausführung folgenden Befehls :

gcc  -g -O2 -D_LARGEFILE64_SOURCE -DNE_LFS -D_FILE_OFFSET_BITS=64 -I/usr/local/include/neon -I/usr/include/fuse -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -Wall -D_GNU_SOURCE -D_REENTRANT   -o wdfs  cache.o svn.o wdfs-main.o webdav.o  -pthread /usr/lib/libiconv.so -L/usr/local/lib -lfuse -ldl -lneon -lglib-2.0 -lintl -liconv

beim Erstellen eines binären Programmes wdfs (in diesem Fall speziell während des bindens des Programmes)
durch den Linker (ld)
ein Fehler aufgetreten:

 /neon-0.29.3/src/ne_xml.c:196: undefined reference to `XML_GetCurrentLineNumber'

alle weiteren Fehler sind erst einmal unintessant, da sie eventuell durch den ersten Fehler bedingt erst ausgelöst worden sind. Es wird erst einmal immer nur der aller erste Fehler beseitigt, oftmals verschwinden dadurch weitere Fehler automatisch mit. In diesem Fall sind die weiten Fehler alles ähnliche Fehler die alle die selbe Ursache haben.

Der erste Unregelmäßigkeite die hier als Fehler gewertet wird ist dieser hier:

/usr/local/lib/libneon.a(ne_xml.o): In function `ne_xml_currentline':
/neon-0.29.3/src/ne_xml.c:196: undefined reference to `XML_GetCurrentLineNumber'

Und Bedeutet: In der Datei (in diesem Fall ein statisches Library) /usr/local/lib/libneon.a , in einem Bereich der aus der Objektdatei "ne_xml.o" stammt, wird in der Zeile 196 der Datei "neon-0.29.3/src/ne_xml.c" die Funktion "XML_GetCurrentLineNumber" verwendet. Die eigentliche Funktion (also der binäre Code den diese Funktion ausführen soll) dazu kann aber nicht gefunden werden.
Der Fehler der hier auffschlägt hat also überhaupt nichts mit dem Programm zu tun, das du gerade kompilieren willst, sondern ist eine ungelöste Abhängikeit, in diesem Fall der statischen Library libneon.a

Aufschlagen tut dieser Fehler dann hier:

collect2: ld returned 1 exit status

Das hat soviel zu bedeuten, das ein Teilprozess von "gcc" und zwar der Linker "ld" dadurch seine Arbeit mit Fehler (Rückgabewert 1) beendet.



Ursache ist hier folgende:
Die statische Lib /usr/local/lib/libneon.a meldet beim Binden mit ld undefined reference to `XML_.........
Das bedeutet diese statischen "libneon" greift auf Symbole oder Funktionen zu die nicht in ihr enthalten sind und auch sonst nicht in anderen Objektdateien die mit auf der Befehlszeile angegeben sind , sondern sich scheinbar in einer weiteren Library befinden. Diese innerhalb libneon verwendete Symbole dieser Library werden vom Linker so nicht gefunden und desshalb meldet er "undefinierte Referencen".

Wo liegt das Problem bzw währe ist es zu lösen:
Das eigentliche Problem ist folgendes, beim Aufruf von gcc oder ld müsste diese Library mit angeben werden, und natürlich müsste sie auf dem Rechner auch existieren, dann würde "ld" das sauber verarbeiten können. Oder es müsste explizied dort im gcc Aufruf enthalten sein, das solche undefinierten Symbole nicht als Fehler zu werten sind. Wie diese Library jetzt genau heißt, könnte man anhand der vermissten Symbole herausfinden. dazu könnte man mit ldd , objdump und nm in Verbindung mit grep ein paar Untersuchungen anstellen und diese so finden. Man könnte sie auch notfalls dann selbst in die Makefile.in eintagen, damit das kompilieren des Programmes funktioniert. Existieren würde eine solche Library sicherlich genau dann, wenn die Installation des Paketes "libneon" ordnungsgemäß abgelaufen ist. In diesem Fall müssten entweder mit den Abhängikeiten des Paketes eine solche Library installiert worden sein, oder beim Installieren des Paketes selbst diese Library sauber installiert worden sein. Dann müsste sie aber immer noch von configure gesucht und in Verbindung mit der Makefile.in in die Makefile sauber eingetragen werden. Ist sie aber bei dir nicht- warum?

Die Entwickler dieses "wdfs Paketes" haben sicherlich damit gerechnet, das entweder diese Funktionen in einer "libneon.a" enthalten sind, oder das eine libneon.so.??? auf dem Rechner vorhanden ist. (dort würde es das Problem nicht geben, da diese Lib ihre Abhänigkeiten selbst durch dynamische Libs auflösen würde und es desshalb beim Kompilieren hier keinen Fehler produzieren würde) Aus diesem Grund haben die Entwickler in den Abhängikeiten auch nicht nach einer weiteren Library suchen lassen. Meist ist es so, das man einfach vorraussetzt das es dynamische Library auf dem System gibt, diese würden auch immer vorzugsweise verwendet werden, wenn es nicht explizied angeben wurde, sie nicht zu verwenden. Eine solche Option habe ich jetzt dort im gcc Aufruf nicht gesehen, also stellt sich doch die Frage, warum wurde dann bei dir dort die "libneon.a" verwendet und nicht die dynamische Lib "libneon.so.irgendwas" ?

Das Problem ist also deine entweder nicht existierende "libneon.so.???" , oder das diese wenn vorhanden, dann nicht gefunden wird. Ein Blick in die Befehlszeile zeigt schon an den LocalPath, du hast diese Library selbst kompiliert. Wahrscheinlich dort mit falschen Optionen oder du hast bei der Installation etwas getrickst oder gepfuscht. Such mal gezielt nach allen Varianten dieser lib, und warum hast du überhaupt da nicht ein fertiges Paket für diese libneon genommen? gab es dazu irgendwelche speziellen Notwendigkeiten diese selbst zu kompilieren.

ls -l /usr/lib/libneon.* /usr/local/lib/libneon.*

Ein paar einleitente Worte zu Libraries würdest du auch bei uns im Wiki finden. http://www.linupedia.org/opensuse/Library

robi

 

[abgdf]

Das Problem ist noch viel grundsätzlicher: Wenn "make" immer so durchlaufen würde, bräucht man ja gar keine Paketverwaltungen und "rpm"- oder "deb"-Pakete. Tatsächlich sind diese Abhängigkeiten aber oft nicht so trivial. Deshalb machen sich die Leute ja auch die Mühe, von der freien Software komplexe Distributionen mit genau darauf abgestimmten Paketen zusammenzustellen.
Und das ist dann auch das Problem dieser "kleinen" Distributionen: Sie können nicht alles mitliefern und lassen einen dann ansonsten mit dem Quellcode und "make" allein.
Deshalb setze ich auf meinem alten Rechner (PII-233) auch lieber ein altes SuSE ein, da ich dort wenigstens volle "rpm"-Unterstützung habe.
Ohne das ist es einfach zu schmerzhaft.

Mit anderen Worten: Wenn Du "make" für alle Programme vollständig beherrschst, kannst Du Dir im Prinzip auch gleich Deine eigene Distribution zusammenstellen. Dazu sind aber nur die wenigsten in der Lage (ich gehöre nicht dazu).

Gruß

 

[Systemcrasher]

Ich versuche mal den orbrigen Fehler anhand dieser Ausgabe Schritt für Schritt zu analysieren um dir zu zeigen wie man an sowas überhaupt erstmal rangeht um den Fehlern bei make auf die Schliche zu kommen.

Ohne jetzt auf alles eingehen zu wollen und damit diese "Beitragsreihe" unübersichtlich zu machen, glaube ich - wenn ich Deine äußerst gelungene und ausführliche Erklärung richtig verstanden habe - daß es letzten endes daran lag, daß wdfs die library nicht in der ldconfig fand.

Denn:

-rw-r--r-- 1 root root 362800  6. Aug 19:19 /usr/local/lib/libneon.a
-rwxr-xr-x 1 root root    950  6. Aug 19:19 /usr/local/lib/libneon.la

Da sind sie anscheinend.

Das würde übrigens auch erklären, wieso Dillo 2.2 ständig meckert, FLTK2 sei nicht installiert, obwohl es das ist.

Anscheinend wird bei make / make install nicht immer ein ldconfig ausgeführt.....

Das Problem ist also deine entweder nicht existierende "libneon.so.???" , oder das diese wenn vorhanden, dann nicht gefunden wird. Ein Blick in die Befehlszeile zeigt schon an den LocalPath, du hast diese Library selbst kompiliert. Wahrscheinlich dort mit falschen Optionen oder du hast bei der Installation etwas getrickst oder gepfuscht. robi

Naja, ich habe mir da ein Standardverfahren angeeignet, das bei der Paket-Portierung von Deli 0.7 nach 0.8 leider nur so funktioniert:

1. Paket ins / entpacken.
2 .Dann ins entsprechende Verzeichnis wechseln und ./configure ausführen, wenn in den Anleitungen keine Zusatzparameter angegeben sind.
3. make und dann make install.

Anschließend das Verzeichnis wieder löschen.

Manche Pakete machen keine Schwierigkeiten, manche schon.

Leider kann ich das mit ldconfig im Moment nicht testen, da ich nicht zu Hause bin sondern auf der Arbeit. aber die entsprechenden logs hab ich mir vorher kopiert.


@abgdf:

Da ich mit den Rechnern auch ins internet gehe, macht eine aktuelle Distri schon Sinn.

Außerdem ist da ein gewisser Lerneffekt dabei...

Auch ist es so daß man sich gerade bei alten Rechnern oft nicht aussuchen kann, welche Distri man will, sondern die nehmen muß, die einigermaßen schnell drauf läuft.

 

[Anonymous]

rob@rob-linux:~> ls -l /usr/lib/libneon.* /usr/local/lib/libneon.*
ls: Zugriff auf /usr/local/lib/libneon.* nicht möglich: Datei oder Verzeichnis nicht gefunden
lrwxrwxrwx 1 root root     17  3. Dez 2009  /usr/lib/libneon.so.27 -> libneon.so.27.1.4
-rwxr-xr-x 1 root root 146148 19. Okt 2009  /usr/lib/libneon.so.27.1.4
rob@rob-linux:~>

libneon.so will er haben, das ist die dynamische Lib. Die libneon.a ist nur ein Sammlung der Objektdateinen dieses Paketes, dort sind dann noch Abhänigkeiten drin, die in der statischen Lib nicht aufgelöst sind und die in einer anderen lib stehen, nach der aber nicht gesucht wird.

robi

 

[abgdf]

Außerdem ist da ein gewisser Lerneffekt dabei...

Bitte schön, dann aber von der Pieke auf: Also, erstmal kleine C-Programme kompilieren, dann lernen, wie man mehrere C-Dateien zusammenbindet, und was es mit Objektdateien und Linken auf sich hat, dann statische und dynamische Bibliotheken kompilieren. Bis hierhin bin ich in etwa gekommen, siehe hier.
Dann lernen, wie man Makefiles und configure-Skripte schreibt (und welche Tools es dazu gibt), dann die Besonderheiten beim Kompilieren von großen GUI-Bibliotheken wie Qt lernen. Dann bist Du vielleicht irgendwann soweit, endlich zu verstehen, was bei dem make-Vorgang vor sich geht. Auf dem Weg dahin sollte dann eigentlich auch ein ganz guter C-Programmierer mit vertieften Kenntnissen von C++ und der Qt-API aus Dir geworden sein, der z.B. auch ggf. die Quelldateien eines C-Programms so abändern kann, daß auch seine gcc-Version das Programm kompiliert, obwohl der Code für eine andere (neuere oder ältere) gcc-Version geschrieben wurde usw. .

Viel Spaß!

 

[Systemcrasher]

libneon.so will er haben, das ist die dynamische Lib. Die libneon.a ist nur ein Sammlung der Objektdateinen dieses Paketes, dort sind dann noch Abhänigkeiten drin, die in der statischen Lib nicht aufgelöst sind und die in einer anderen lib stehen, nach der aber nicht gesucht wird.

robi

Also isses doch komplizierter als befürchtet.

Da ich im Moment wieder am betreffenden Rechner sitze (bis nachher mein Dienst anfängt), konnte ich nochmal vertieft nachschauen.
Dummerweise gibt es bei dem Neon-Paket keine Installationsanleitung für Linux, nur die INSTALL.win32.

Daher hatte ich nichts, wonach ich mich richten konnte. Da Neon aber nicht gemeckert hatte, ging ich von einer erfolgreichen Installation aus, was ganz offensichtlich nicht der Fall war.

Spontan fallen mir da nur 3 Möglichkeiten ein:

- erneuter Versuch mit einer tieferen Version (aber mindestens 0.24)
- suchen nach der betreffenden lib im Internet und Installation "von Hand"
- lernen, wie ich das Problem lösen kann auch ohne Programmierkenntnisse

Leider gibt es für Deli kein Paket dazu, ich mußte also auf eine Paketquelle zurückgreifen. Auch ein Arch-Linux-Paket habe ich nicht gefunden, das soll am einfachsten zu portieren sein.


@abgdf: Warum bist Du so demoralisierend? Willst Du mich fertig machen?

Aber dennoch danke für den Link zur Einführung in Script-Programmierung, das wird mir bestimmt an anderer Stelle nützlich sein.


Edit:

Falls das was hilft, die config.log von Neon:

http://pastebin.de/8944

 

[Anonymous]

Spontan fallen mir da nur 3 Möglichkeiten ein:

- erneuter Versuch mit einer tieferen Version (aber mindestens 0.24)
- suchen nach der betreffenden lib im Internet und Installation "von Hand"
- lernen, wie ich das Problem lösen kann auch ohne Programmierkenntnisse

Punkt1 == wird nicht viel bringen, alles andere ist Zufall
Punkt2 == Komplett falscher Weg, da jedem Paketbauer mehr oder weniger viel Spielraum zur Verfügung steht wie er seine Abhängikeiten zusammen gruppiert, ist da viel zu viel Spielraum für Fehler aller Art.
Punkt3 == Gute Idee. Versuch als erstes mal "./configure --help" da kommen meistens schonmal alle möglichen Optionen die von configure angenommen und verstanden werden, auch oft mit kleiner Hilfestellung. Das hilft manchmal weiter wenn die Beschreibung sonst aus NULL,NULL besteht und sonst keine brauchbaren Infos zur Verfügung stehen.

Laut deiner Log ist "NEON_LIBS='-lintl -lz -lexpat'", davon ist die Hälfte nicht in dem gcc Befehl enthalten wo sie dringend benötigt werden würden.

Also würde ich doch mal folgendes versuchen und manuell dort weiter machen, wo make hängen geblieben ist. Ist nur Krückenlösung, aber ,..... Machmal heiligt der Zweck die Mittel.

cd ???????/wdfs-1.4.2/src
gcc  -g -O2 -D_LARGEFILE64_SOURCE -DNE_LFS -D_FILE_OFFSET_BITS=64 -I/usr/local/include/neon -I/usr/include/fuse -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -Wall -D_GNU_SOURCE -D_REENTRANT   -o wdfs  cache.o svn.o wdfs-main.o webdav.o  -pthread /usr/lib/libiconv.so -L/usr/local/lib -lfuse -ldl -lneon -lglib-2.0 -lintl -liconv  -lz -lexpat

(per copy&paste)
Wenn das funktioniert dann ganz normal wieder ein Verzeichnis zurück und dort noch einmal make aufrufen, und schaun was dann als nächstes für Fehler kommt.

robi

 

[abgdf]

@abgdf: Warum bist Du so demoralisierend? Willst Du mich fertig machen?

Nein, bestimmt nicht. Entschuldige bitte, falls das so geklungen hat.
Liegt wahrscheinlich daran, daß ich selbst in bezug auf C und gcc etwas demoralisiert bin: Obwohl ich den Kram auf meiner gcc-Seite schon mal hingekriegt habe, scheitere ich doch öfters beim Kompilieren. Vielleicht schien mir deshalb einfach, daß Du Dir das ein bißchen zu einfach vorstellst (obwohl robi sich ja schon so weit auszukennen scheint, daß er so ziemlich alles kompiliert kriegt; es ist also möglich).

Also, nichts für ungut, vielleicht kommst Du ja weiter als ich. Würde mich in dem Fall übrigens freuen, wenn Du Deine weitergehenden Erfahrungen mit Libs und make dann auch mal auf einer Web- oder Wiki-Seite darstellen würdest. Denn eigentlich würde ich das auch immer gern noch mal ganz lernen, und wirklich gute Seiten hab' ich dazu bislang noch nicht gefunden ("aclocal" ist da auch noch so ein merkwürdiges Tool, von dem ich irgendwie nicht genau weiß, wozu es gut ist, obwohl ich es schon einmal - zufälligerweise erfolgreich - beim Kompilieren eingesetzt habe).

 

[Systemcrasher]

@abgdf: Warum bist Du so demoralisierend? Willst Du mich fertig machen?

Nein, bestimmt nicht. Entschuldige bitte, falls das so geklungen hat.
Liegt wahrscheinlich daran, daß ich selbst in bezug auf C und gcc etwas demoralisiert bin:

Ich war auch nicht beleidigt, Dein Frust war deutlich zu lesen. Deshalb war die Bemerkung eher spöttisch gemeint.

Aber das mit dem "make" MUSS ich gebacken kriegen, weil: http://www.delilinux.de/forum/topic.php?id=1168 ich da beim Testen der neuen Distri usw. mithelfen werde.

Zumindest in der ersten Testphase erwarte ich eher keine fertig geschnürten Pakete.

Werbe-

-rühr: Es werden noch Leute gesucht, die da mitmachen.

PS: Zu Robis Tipps melde ich mich, sobald ich die abgearbeitet habe.

 

[Systemcrasher]

Punkt3 == Gute Idee. Versuch als erstes mal "./configure --help" da kommen meistens schonmal alle möglichen Optionen die von configure angenommen und verstanden werden, auch oft mit kleiner Hilfestellung. Das hilft manchmal weiter wenn die Beschreibung sonst aus NULL,NULL besteht und sonst keine brauchbaren Infos zur Verfügung stehen.

Laut deiner Log ist "NEON_LIBS='-lintl -lz -lexpat'", davon ist die Hälfte nicht in dem gcc Befehl enthalten wo sie dringend benötigt werden würden.

Also würde ich doch mal folgendes versuchen und manuell dort weiter machen, wo make hängen geblieben ist. Ist nur Krückenlösung, aber ,..... Machmal heiligt der Zweck die Mittel.

Krückenlösung hat leider nicht funktioniert. Ich habe noch ein paar Optionen bei ./configure (bei wdfs) probiert, was leider auch nichts gebracht hat.

Aber anscheinend ist der Bösewicht ja auch Neon, das sich allem Anschein nach nicht wie vorgesehen installiert.
Im Moment lese ich mich etwas tiefer in das Thema make&co ein (Linux-Grundlagenbuch v. Data Becker, sowie Kofler und Linux in a Nutshell. Alles sehr empfehlenswerte Bücher, immerhin verstehe sogar ich vieles davon.).

Ich muß also jetzt erst mal rausfinden, warum sich Neon nicht richtig installiert, richtig?