samba 3.6 und Fritz!OS 05.50

hermann72pb

IPPF-Promi
Mitglied seit
6 Nov 2005
Beiträge
3,726
Punkte für Reaktionen
16
Punkte
38
Gibt es jemand, bei dem der aktuelle Trunk mit SAMBA 3.6 und 05.50 (oder Labor) läuft? Bei mir scheitert es beim kompilieren.
Darf man denn so einfach auf dem build-System von SAMBA 3.0.37 zu 3.6 wechseln? Oder läuft da etwas durcheinander. Ich hatte schon mal mit samba distclean und dirclean probiert. Ohne Erfolg.
Wenn Interesse besteht, kann ich die Meldung posten. Dafür muss ich allerdings make nochmal laufen lassen (momentan läuft es mit 3.0.37 durch).

MfG
 
Poste mal die Fehlermeldung. Lässt sich hier problemlos übersetzen.
 
Code:
Compiling ../librpc/rpc/dcerpc_util.c
Compiling ../lib/replace/getaddrinfo.c
Compiling ../lib/replace/getifaddrs.c
Compiling ../lib/replace/getpass.c
../lib/replace/getifaddrs.c:45:29: warning: 'struct ifaddrs' declared inside parameter list [enabled by default]
../lib/replace/getifaddrs.c:45:29: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
../lib/replace/getifaddrs.c: In function 'rep_freeifaddrs':
../lib/replace/getifaddrs.c:48:11: error: dereferencing pointer to incomplete type
../lib/replace/getifaddrs.c:49:11: error: dereferencing pointer to incomplete type
../lib/replace/getifaddrs.c:50:11: error: dereferencing pointer to incomplete type
../lib/replace/getifaddrs.c:51:11: error: dereferencing pointer to incomplete type
../lib/replace/getifaddrs.c:52:18: error: dereferencing pointer to incomplete type
../lib/replace/getifaddrs.c: At top level:
../lib/replace/getifaddrs.c:81:27: warning: 'struct ifaddrs' declared inside parameter list [enabled by default]
../lib/replace/getifaddrs.c: In function 'rep_getifaddrs':
../lib/replace/getifaddrs.c:115:28: error: invalid application of 'sizeof' to incomplete type 'struct ifaddrs'
../lib/replace/getifaddrs.c:116:8: error: dereferencing pointer to incomplete type
../lib/replace/getifaddrs.c:117:8: error: dereferencing pointer to incomplete type
../lib/replace/getifaddrs.c:118:8: error: dereferencing pointer to incomplete type
../lib/replace/getifaddrs.c:119:8: error: dereferencing pointer to incomplete type
../lib/replace/getifaddrs.c:120:8: error: dereferencing pointer to incomplete type
../lib/replace/getifaddrs.c:122:8: error: dereferencing pointer to incomplete type
../lib/replace/getifaddrs.c:124:9: error: dereferencing pointer to incomplete type
../lib/replace/getifaddrs.c:127:8: error: dereferencing pointer to incomplete type
../lib/replace/getifaddrs.c:129:9: error: dereferencing pointer to incomplete type
../lib/replace/getifaddrs.c:135:10: error: dereferencing pointer to incomplete type
The following command failed:
/home/freetz/7390/toolchain/build/mips_gcc-4.6.3_uClibc-0.9.32.1/mips-linux-uclibc/bin/mips-linux-uclibc-gcc -march=24kc -Os -pipe -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I/home/freetz/7390/source/target-mips_uClibc-0.9.32.1/samba-3.6.10/source3 -I/home/freetz/7390/source/target-mips_uClibc-0.9.32.1/samba-3.6.10/source3/../lib/iniparser/src -Iinclude -I./include  -I. -I. -I./../lib/replace -I./../lib/tevent -I./librpc -I./.. -I./../lib/talloc -I../lib/tdb/include -DHAVE_CONFIG_H  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DMAX_DEBUG_LEVEL=-1 -D__location__=\  -I/home/freetz/7390/source/target-mips_uClibc-0.9.32.1/samba-3.6.10/source3/lib -I.. -D_SAMBA_BUILD_=3 -D_SAMBA_BUILD_=3 -ffunction-sections -fdata-sections  -c ../lib/replace/getifaddrs.c -o ../lib/replace/getifaddrs.o
make[1]: *** [../lib/replace/getifaddrs.o] Fehler 1
make[1]: *** Warte auf noch nicht beendete Prozesse...
make[1]: Verlasse Verzeichnis '/home/freetz/7390/source/target-mips_uClibc-0.9.32.1/samba-3.6.10/source3'

ERROR: Build failed.
make: *** [source/target-mips_uClibc-0.9.32.1/samba-3.6.10/source3/bin/samba_multicall] Fehler 1
 
@Ralf: Und nun? Vor allem, warum funktioniert es bei anderen und bei mir nicht? "make samba-clean" hilft nicht. Was kann ich sonst tun, außer das komplette Verzeichnis schon zum tausenden Mal ins "7390-bad" umbenennen und komplett neu auschecken?

MfG
 
Laut man getifaddrs braucht man
Code:
#include <sys/types.h>
#include <ifaddrs.h>
Ist das in der Datei vorhanden, speziell ifaddrs.h? Und wenn ja, ist diese Datei Teil der Build-Umgebung? Vielleicht ist die Datei bei anderen im Host-System installiert.
 
sys/types.h wird in lib/replace/replace.h inkludiert und ifaddrs.h in lib/replace/system/network.h

Welchen Wert habe die folgenden Variablen in source3/include/config.h
Code:
#define HAVE_FREEIFADDRS 1
#define HAVE_GETIFADDRS 1
/* #undef HAVE_IFACE_GETIFADDRS */
#define HAVE_IFADDRS_H 1
#define HAVE_STRUCT_IFADDRS 1

Verwendest Du selbstgebaute oder download-toolchain? Hast Du uClibc-header-Dateien irgendwie angepasst (mache ich manchmal für irgendwelche Tests)?
 
@er13: Du hättest mir deine grep-Filtereinstellung auch verraten können... Aber egal, habe ich erraten:
Code:
freetz@freetz-linux:~/7390$ grep IFADDRS source/target-mips_uClibc-0.9.32.1/samba-3.6.10/source3/include/config.h
#define HAVE_FREEIFADDRS 1
#define HAVE_GETIFADDRS 1
/* #undef HAVE_IFACE_GETIFADDRS */
/* #undef HAVE_IFADDRS_H */
#define HAVE_STRUCT_IFADDRS 1
Wie du siehst, gibt es da schon einen Unterschied. Antworten auf deine weiteren Fragen:
1. Ich baue keine Toolchain selbst, sondern verwende die download-toolchain
2. Ich habe keine uClibc-header angepasst (zumindest nicht bewusst)

Und nun? Einfach in der Datei den fehlenden define definieren?
Wird diese config.h eigentlich selbst generiert? Von wem und wann?

Edit: Ich habe bei SAMBA noch nmbd und client mitausgewählt. Vielleicht hängt es damit zusammen... Bei 3.0.37 läuft es aber so durch.

Edit2:Nach dem aktivieren von
Code:
#define HAVE_IFADDRS_H 1
läuft es jetzt durch...
Die Frage ist: Was ist bei mir schief gelaufen und wie hoch ist die Wahrscheinlichkeit, dass es bei den anderen auch schief läuft?

MfG
 
Zuletzt bearbeitet:
config.h wird von configure erzeugt.

Welchen Wert hat die Variable ac_cv_header_ifaddrs_h in config.cache? no? Wie lautet die Ausgabe von Samba's configure mit config.cache und mit gelöschter config.cache? Relevant ist nur der Teil
Code:
checking for ifaddrs.h...yes

Vermutung: irgendein Paket schreibt in config.cache ac_cv_header_ifaddrs_h=no, ab dem Moment ist der falsche Wert gecached und wird für alle anderen Pakete verwendet.

Sofern Du die Option FREETZ_BACKUP_CONFIG_CACHE aktiviert hast, kannst Du unter source/target-mips*_uClibc-*/_config.cache-backup/ nachschauen, welches Paket es war. Nachträglich die Option zu aktivieren reicht leider nicht, diese muss von Anfang an aktiviert gewesen sein.
 
Zuletzt bearbeitet:
Hallo Hermann.

Suche doch mal bitte in deinem Source Verzeichnis alle "configure"s in denen ac_cv_header_ifaddrs_h vorkommt. Das fragliche Paket könnte evtl. darunter sein. (Ich habe nur libpcap damit gefunden)

Gruß
Oliver
 
Die Frage ist: Was ist bei mir schief gelaufen und wie hoch ist die Wahrscheinlichkeit, dass es bei den anderen auch schief läuft?
Bei mir tritt der ähnliche/gleiche Fehler auf, allerdings für AVM-FW 05.22 (für eine 7270v3). Siehe hier.
 
Code:
freetz@freetz-linux:~/7390$ grep -RE "ac_cv_header_ifaddrs_h" source/*
source/target-mips_uClibc-0.9.32.1/strace-4.6/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/glib-2.32.3/config.log:ac_cv_header_ifaddrs_h=no
grep: source/target-mips_uClibc-0.9.32.1/callmonitor-1.20.3/root/usr/lib/callmonitor/actions.local.d: Datei oder Verzeichnis nicht gefunden
source/target-mips_uClibc-0.9.32.1/bridge-utils-1.4/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/e2fsprogs-1.42.4/config.log:ac_cv_header_ifaddrs_h=no
grep: source/target-mips_uClibc-0.9.32.1/callmonitor-1.20.2/root/usr/lib/callmonitor/actions.local.d: Datei oder Verzeichnis nicht gefunden
source/target-mips_uClibc-0.9.32.1/openvpn-2.3.0/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/dropbear-2012.55/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/curl-7.25.0/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/mc-4.8.6/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/pcre-8.30/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/fstyp-0.1/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/ntfs-3g_ntfsprogs-2012.1.15/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/mc-4.8.3/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/curl-7.27.0/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/matrixtunnel/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/samba-3.0.37/source/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/glib-2.32.4/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/ntfs-3g_ntfsprogs-2013.1.13/config.log:ac_cv_header_ifaddrs_h=no
grep: source/target-mips_uClibc-0.9.32.1/callmonitor-1.20.1/root/usr/lib/callmonitor/actions.local.d: Datei oder Verzeichnis nicht gefunden
source/target-mips_uClibc-0.9.32.1/readline-6.2/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/mc-4.8.7/config.log:ac_cv_header_ifaddrs_h=no
grep: source/target-mips_uClibc-0.9.32.1/callmonitor-1.20.4/root/usr/lib/callmonitor/actions.local.d: Datei oder Verzeichnis nicht gefunden
source/target-mips_uClibc-0.9.32.1/sispmctl-3.1/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/openvpn-2.2.2/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/haserl-0.9.29/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/pcre-8.31/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/samba-3.6.10/source3/configure:  ac_fn_c_check_header_mongrel "$LINENO" "ifaddrs.h" "ac_cv_header_ifaddrs_h" "$ac_includes_default"
[B][COLOR="#FF0000"]source/target-mips_uClibc-0.9.32.1/samba-3.6.10/source3/configure:if test "x$ac_cv_header_ifaddrs_h" = xyes; then :
source/target-mips_uClibc-0.9.32.1/samba-3.6.10/source3/config.log:ac_cv_header_ifaddrs_h=no[/COLOR]
[/B]source/target-mips_uClibc-0.9.32.1/mc-4.8.4/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/curl-7.28.1/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/config.cache:ac_cv_header_ifaddrs_h=${ac_cv_header_ifaddrs_h=no}
source/target-mips_uClibc-0.9.32.1/pcre-8.32/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/e2fsprogs-1.42.5/config.log:ac_cv_header_ifaddrs_h=no
source/target-mips_uClibc-0.9.32.1/e2fsprogs-1.42.6/config.log:ac_cv_header_ifaddrs_h=no

Und nun? Ich sehe da nur die Logs mit "no"...

Edit:Der markierte Abschnitt macht mir bisschen Sorgen... Im gleichen Verzeichnis liegen auch sourcen von SAMBA 3.0.37. grep findet dort aber gar nichts... Und das checken auf "yes" ist auch etwas komisch, weil es nur hier bei SAMBA vorkommt.

Edit2 @er13:
Code:
config.cache:

ac_cv_header_ifaddrs_h=${ac_cv_header_ifaddrs_h=no}

MfG
 
Zuletzt bearbeitet:
Lösche mal die Zeile ac_cv_header_ifaddrs_h aus Deiner config.cache und versuch' samba erneut zu übersetzen (samba-dirclean davor nicht vergessen).

Wenn es jetzt geht, dann liegt es wie vermutet allein an diesem Eintrag, welcher jedoch von einem anderen Paket stammt. Ich würde die ältere curl-Version verdächtigen (es kann sogar sein, dass dieser in der neuen behoben ist). Versuch mal unter allen config.log Dateien, in denen ac_cv_header_ifaddrs_h enthalten ist, die mit dem kleinsten Zeitstempel zu finden (d.h. die älterste Datei).
 
Und? Dass Ihr das gleiche Problem habt, heißt noch lange nicht, dass Ihr auch dieselbe Ursache habt. Ähnliche ja, dieselbe nicht unbedingt. Habe ich in #9 nicht gesagt, was zu tun ist oder worauf wartet Ihr? Dass wir es erraten?

Edit: wenn ich jetzt Deine .config aus dem von Dir verlinkten Thread nehme, lässt sich bei mir alles problemlos bauen. Die einzige Erklärung, die ich momentan habe, ist, dass der Fehler im aktuellen trunk mittlerweile durch irgendein Version-Bump behoben wurde oder alternativ das Paket, welches das Problem verursacht hat, mittlerweile von Dir abgewählt wurde.
 
Zuletzt bearbeitet:
Lösche mal die Zeile ac_cv_header_ifaddrs_h aus Deiner config.cache und versuch' samba erneut zu übersetzen (samba-dirclean davor nicht vergessen).
So hat's bei mir nun geklappt.
Edit: wenn ich jetzt Deine .config aus dem von Dir verlinkten Thread nehme, lässt sich bei mir alles problemlos bauen. Die einzige Erklärung, die ich momentan habe, ist, dass der Fehler im aktuellen trunk mittlerweile durch irgendein Version-Bump behoben wurde oder alternativ das Paket, welches das Problem verursacht hat, mittlerweile von Dir abgewählt wurde.
Ich hatte gegenüber meiner alten .config keine Pakete abgewählt, sondern noch wget und unrar hinzugewählt ...
Und wie ich schrieb, habe ich versucht, die .config mit der Trunk Revision 10006 zu kompilieren...
Grüße,

JD.
 
Zuletzt bearbeitet:
@er13: Ich hatte das Problem für mich anders gelöst (s. #8). Zwar schmutzig und nicht am Kern der Ursache, aber so, dass es bei mir durchlief. Von daher interessiert mich persönlich das Problem jetzt nicht mehr. Für die Allgemeinheit könnte ich die weiteren Experimente noch mal durchführen, wenn ich die Zeit dafür finde.
Was ich mit meinen roten Zeilen in #12 wiedergeben wollte: SAMBA 3.6 reagiert auf diesen header eindeutig viel empfindlicher, als die alte SAMBA 3.0.17 und vermutlich empfindlicher als alle anderen Pakete.
Die Ursache wird vermutlich in irgendeinem der anderen Paketen liegen. CURL nutze ich, daher könnte es tatsächlich bei mir als Ursache in Betracht kommen.

MfG
 
Hallo,

hoffentlich darf ich an dieser Stelle antworten, ohne dass mir jemand den Kopf abreißt, aber ich finde, dass es inhaltlich dazu passt.
Samba 3.6 läuft bei mir unter devel-10019 (Fritz!OS 05.50) auf der 7390 an sich prima, nur klappt die Benutzerverwaltung nach dem bisherigen Verfahren nicht.
Außerdem ist mir unklar, inwiefern die im AVM Webinterface unter Fritz!Box-Kennwort eingetragenen Benutzer mit Samba wechselwirken.

Gibt es dazu schon Erfahrungen?

Gruß und danke,
M!chel
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.