QmailAdmin laesst sich nicht kompilieren
Hallo, hallo, ich will QmailAdmin neu kompilieren. webserver:~/000/qmailadmin-1.0.6 # ./configure --enable-htmldir=/srv/www/htdocs/mailadmin.bikealert.de/ --enable-cgibindir=/srv/www/htdocs/mailadmin.bikealert.de/ --enable-vpopmaildir=/home/vpopmail/ --enable-vpopuser=vpopmail --enable-vpopgroup=vchkpw --includedir=/home/vpopmail/ --libdir=/home/vpopmail/ ok. In /home/vpopmail liegen u.a. webserver:~/000/qmailadmin-1.0.6 # ls /home/vpopmail/include/ config.h vauth.h vpopmail.h vpopmail_config.h webserver:~/000/qmailadmin-1.0.6 # ls /home/vpopmail/lib . .. libvpopmail.a Diesw werden aber nicht eingebunden. Beim kompilieren meckert qmailadmins sofort rum und bricht ab. Ich habe daraufhin die INCLUDE files in das /usrc/include Dir kopiert - siehe da, es klappte. Nur scheint die lib nicht erkannt zu werden, denn ich bekomme nun tausend Fehlermeldungen: /root/000/qmailadmin-1.0.6/auth.c:144: undefined reference to `vauth_getpw' template.o: In function `send_template_now': /root/000/qmailadmin-1.0.6/template.c:462: undefined reference to `vauth_getall' /root/000/qmailadmin-1.0.6/template.c:487: undefined reference to `vclose' template.o: In function `check_user_forward_vacation': /root/000/qmailadmin-1.0.6/template.c:502: undefined reference to `vauth_getpw' command.o: In function `process_commands': usw. usw. usw Ich habe auch ldconfig ausgefuehrt usw. usw. Any ideas ? cu stonki -- Deutsche ProFTP Docs: http://www.proftpd.de, EFNET: #proftpd KDE3 Renamer: http://www.krename.net KDE3 Barcode und Label Solution: http://www.kbarcode.net
Hi Stefan, schau doch mal hier nach: http://www.wolfgarten.com/article.php?sid=18&mode=thread&order=0 Ist ein uralter (Mini-) Artikel über die Installation von qmailadmin, den ich 2001 geschrieben habe. Die von Dir benutzten finalen Forwardslashes (z.B. --enable-vpopmaildir=/home/vpopmail/) sind imho nicht nötig. Trag doch einfach /home/vpopmail/lib in /etc/ld.so.conf ein und rufe "ldconfig" bzw. "ldconfig -v" und schau mal, ob der die Libs korrekt einbindet. Viele Grüße, Sebastian
Hallo, am Mittwoch, 14. Mai 2003 um 10:35 schrieb Sebastian Wolfgarten
imho nicht nötig. Trag doch einfach /home/vpopmail/lib in /etc/ld.so.conf ein und rufe "ldconfig" bzw. "ldconfig -v" und schau mal, ob der die Libs korrekt einbindet.
ich dreh hier durch: webserver:~/000/qmailadmin-1.0.6 # cat /etc/ld.so.conf [...] /home/vpopmail/lib webserver:~/000/qmailadmin-1.0.6 # ls /home/vpopmail/lib/ . .. libvpopmail.a webserver:~/000/qmailadmin-1.0.6 # ldconfig -v /home/vpopmail/lib: [...] webserver:~/000/qmailadmin-1.0.6 # WIESO NICHT ? Ich habe ein wenig Angst, den ganzen vpopmail Kram auch neu zu kompilieren, da das System ja im produktiven Einsatz ist. cu stoki cu stonki -- Deutsche ProFTP Docs: http://www.proftpd.de, EFNET: #proftpd KDE3 Renamer: http://www.krename.net KDE3 Barcode und Label Solution: http://www.kbarcode.net
Hallo, am Mittwoch, 14. Mai 2003 um 12:49 schrieb Peter Wiersig
.a ist statisch. ld.so ist dynamisch.
ok, und wie kann ich es dennoch kompilieren? ist das erste mal, dass ich bei Qmail solche probs habe. cu stonki -- Deutsche ProFTP Docs: http://www.proftpd.de, EFNET: #proftpd KDE3 Renamer: http://www.krename.net KDE3 Barcode und Label Solution: http://www.kbarcode.net
Stefan Onken schrieb:
ich dreh hier durch:
webserver:~/000/qmailadmin-1.0.6 # cat /etc/ld.so.conf [...] /home/vpopmail/lib
webserver:~/000/qmailadmin-1.0.6 # ls /home/vpopmail/lib/ . .. libvpopmail.a
webserver:~/000/qmailadmin-1.0.6 # ldconfig -v /home/vpopmail/lib: [...] webserver:~/000/qmailadmin-1.0.6 #
WIESO NICHT ?
Die Datei /etc/ld.so.conf ist eine Konfigurationsdatei fuer den dynamischen Linker. ldconfig erzeugt mit Hilfe dieser Datei ein Cache-File, so dass der dynamische Linker bei ent- sprechender Anforderung einer Routine/Bibliothek weiss, wo diese zu finden ist. Wird ein Programm aufgerufen, so wird der dynamische Linker aktiv und bindet "dynamisch" (d.h. beim Programmaufruf bzw. zur Laufzeit) entsprechende Bi- bliotheken ein - daher der Name. Dateien mit der Endung .a sind aber keine dynamischen Bibliotheken, sondern Archive, die vorcompilierten Object-Code enthalten - wird dieser beim Linken verwendet, so ist das im Prinzip so als ob Du das entsprechende Object-File .o selbst direkt an der Kommando- zeile angegeben haettest. Wenn Du also /home/vpopmail/lib in die Konfigurationsdatei /etc/ld.so.conf aufnimmst, so werden in Zukunft (sofern ldconfig danach gelaufen ist) dynamische Bibliotheken in diesem Verzeichnis gefunden werden, nicht aber Archive! Das ist der Unterschied. Entsprechend gibt es beim Erstellen von Programmen die Unterscheidung zwischen "dynamischem Linken" und "statischem Linken". CU, Thomson -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
Hallo, On Wed, 14 May 2003, Thomas Hertweck wrote: [..]
Dateien mit der Endung .a sind aber keine dynamischen Bibliotheken, sondern Archive, die vorcompilierten Object-Code enthalten - wird dieser beim Linken verwendet, so ist das im Prinzip so als ob Du das entsprechende Object-File .o selbst direkt an der Kommando- zeile angegeben haettest.
Apropos: das laesst sich auch nachvollziehen, wenn man das Archiv auspackt (mit 'ar x'), und dann die Object-Dateien einzeln mit angibt bis die Abhaengigkeiten erfuellt sind ;) Aber auch wenn die libc das Standardbeispiel waere, so kann man nicht empfehlen, damit zu experimentieren, da ein "einfaches" .o wie z.B. "printf.o" mehr als nur einen Rattenschwanz an anderen Objekten nachzieht (und man einen Gutteil der glibc einbinden muss) ;) Besser man nimmt sich ne andere lib (u.a. mit weniger Objektdateien)... Und Nochwas: mit dem MC kann man in .a Archive "reinwechseln", per Kommandozeile mit: "mc foo.a#uar"... -dnh -- "A priest is either a PFW on the ultimate support line, or a fraud adept at offering bogus answers to difficult problems while holding lusers at bay with arcane ritual." -- Malcolm Ray
Hallo, am Mittwoch, 14. Mai 2003 um 10:35 schrieb Sebastian Wolfgarten
schau doch mal hier nach: http://www.wolfgarten.com/article.php?sid=18&mode=thread&order=0
link ist leider tot ! cu stonki -- Deutsche ProFTP Docs: http://www.proftpd.de, EFNET: #proftpd KDE3 Renamer: http://www.krename.net KDE3 Barcode und Label Solution: http://www.kbarcode.net
Stefan Onken wrote:
webserver:~/000/qmailadmin-1.0.6 # ls /home/vpopmail/lib . .. libvpopmail.a
/root/000/qmailadmin-1.0.6/auth.c:144: undefined reference to `vauth_getpw' template.o: In function `send_template_now':
Any ideas ?
du musst dafuer sorgen, das "-lvpopmail" mit in die gcc-Zeile aufgenommen wird, die den Teil uebersett, wo du jetzt noch "undefined references" findest. probier mal 'LDFLAGS="-lvpopmail" make' aus. (oder ./configure, je nachdem was abbricht) Peter
Peter Wiersig wrote:
Stefan Onken wrote:
webserver:~/000/qmailadmin-1.0.6 # ls /home/vpopmail/lib . .. libvpopmail.a
/root/000/qmailadmin-1.0.6/auth.c:144: undefined reference to `vauth_getpw' template.o: In function `send_template_now':
Any ideas ?
du musst dafuer sorgen, das "-lvpopmail" mit in die gcc-Zeile aufgenommen wird, die den Teil uebersett, wo du jetzt noch "undefined references" findest. probier mal 'LDFLAGS="-lvpopmail" make' aus. (oder ./configure, je nachdem was abbricht)
Wenn ich mir das noch mal anschaue, glaube ich, du beim Uebersetzen auch noch den Pfad zur Lib angeben musst. LDFLAGS="-L/home/vpopmail/lib -lvpopmail" Peter
Hallo Peter,
Wenn ich mir das noch mal anschaue, glaube ich, du beim Uebersetzen auch noch den Pfad zur Lib angeben musst.
webserver:~/000/qmailadmin-1.0.6 # export | grep LD declare -x LDFLAGS="-L/home/vpopmail/lib -lvpopmail" declare -x OLDPWD="/root/000/qmailadmin-1.0.6" webserver:~/000/qmailadmin-1.0.6 # ./configure --enable-htmldir=/srv/www/htdocsmailadmin.bikealert.de --enable-cgibindir=/srv/www/htdocs/mailadmin.bikealert.de --enable-vpopmaildir=/home/vpopmail --enable-vpopuser=vpopmail --enable-vpopgroup=vchkpw [...] updating cache ./config.cache creating ./config.status creating Makefile creating config.h webserver:~/000/qmailadmin-1.0.6 # make [...] gcc -g -O2 -L/home/vpopmail/lib -lvpopmail -o qmailadmin qmailadmin.o alias.o autorespond.o forward.o mailinglist.o user.o util.o auth.o template.o command.o show.o cgi.o limits.o dotqmail.o -lnsl -lm -lcrypt qmailadmin.o: In function `main': /root/000/qmailadmin-1.0.6/qmailadmin.c:240: undefined reference to `vclose' /root/000/qmailadmin-1.0.6/qmailadmin.c:199: undefined reference to `vget_assign' /root/000/qmailadmin-1.0.6/qmailadmin.c:210: undefined reference to `vauth_user' /root/000/qmailadmin-1.0.6/qmailadmin.c:231: undefined reference to `vget_assign' /root/000/qmailadmin-1.0.6/qmailadmin.c:234: undefined reference to `vclose' /root/000/qmailadmin-1.0.6/qmailadmin.c:175: undefined reference to `vget_assign' /root/000/qmailadmin-1.0.6/qmailadmin.c:180: undefined reference to `vclose' /root/000/qmailadmin-1.0.6/qmailadmin.c:133: undefined reference to `vauth_getpw' /root/000/qmailadmin-1.0.6/qmailadmin.c:136: undefined reference to `vget_assign' [usw usw] collect2: ld returned 1 exit status make[2]: *** [qmailadmin] Error 1 make[2]: Leaving directory `/root/000/qmailadmin-1.0.6' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/000/qmailadmin-1.0.6' make: *** [all-recursive-am] Error 2 webserver:~/000/qmailadmin-1.0.6 # make Wieso ? Das klappte sonst immer :( cu stonki -- Deutsche ProFTP Docs: http://www.proftpd.de, EFNET: #proftpd KDE3 Renamer: http://www.krename.net KDE3 Barcode und Label Solution: http://www.kbarcode.net
Stefan Onken wrote:
gcc -g -O2 -L/home/vpopmail/lib -lvpopmail -o qmailadmin qmailadmin.o alias.o autorespond.o forward.o mailinglist.o user.o util.o auth.o template.o command.o show.o cgi.o limits.o dotqmail.o -lnsl -lm -lcrypt qmailadmin.o: In function `main': /root/000/qmailadmin-1.0.6/qmailadmin.c:240: undefined reference to `vclose'
Wieso ? Das klappte sonst immer :(
in suse-programming hab ich mitgelesen, das der "-lvpopmail" hinter den ".o" Argumenten auftauchen muss. Falls ich bei sowas aus dem Make geworfen werde, rufe ich den gcc meist von Hand fuer die fehlerhaften Module auf. Danach dann weiter mit make. Peter
Peter Wiersig schrieb:
in suse-programming hab ich mitgelesen, das der "-lvpopmail" hinter den ".o" Argumenten auftauchen muss.
Die Reihenfolge kann entscheidend sein. Es ist sogar moeg- lich, dass man die Option -l<name> mehrmals angeben muss, einmal vor einem Object-File, einmal nach allen Object- Files, aber das sind die richtig exotischen Faelle :-) Ha- be ich auch nur gelesen und noch nicht selbst (bewusst) er- lebt. Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
Thomas Hertweck
Die Reihenfolge kann entscheidend sein.
Sie kann nicht nur, sie *ist* es, zumindest was statische Bibliotheken betrifft :) Der statische Linker arbeitet in einem Durchgang, daher müssen Objekte/Bibliotheken genau in der Reihenfolge der Abhängigkeiten angegeben werden. Mit anderen Worten, zuerst muss der Linker wissen, was benötigt wird und dann woraus er den Bedarf befriedigen kann. Aus diesem Grunde sollte man statische Bibliotheken immer zum Schluss angeben. Und am allerbesten macht man keine Unterscheidung zu dynamischen Bibliotheken und schreibt die -l<lib> Optionen immer am Ende. Philipp
Hallo, am Mittwoch, 14. Mai 2003 um 09:42 schrieb Stefan Onken
hallo, ich will QmailAdmin neu kompilieren.
ok, ich glaube ich weiss wo das Problem ist. Ich brauche mal Eure Hilfe: Da die Platte vom Server schrott war, habe ich am 15.03. einige Teile des Systems neu installiert und alle Teile aus alten Backups hervorgeholt. Ich habe u.a. qmail und vpopmail neu Installiert, dann jedoch das gesamte /home/vpopmail verzeichnis aus dem backup genommen. Daher gehe ich im Moment davon aus, dass die Header und Libs nicht mehr zusammen passen. Nun moechte ich folgendes wissen: Wann werden die Libs und Header gebraucht ? Die Groessen von den alten (jetzt installierten) und nen neuen (von mir am 15.03. kompilierten, jedoch aktuell nicht installieren) weichen ab. Wie kann ich die nun austauschen, ohne das System zu vernichten. Wie gesagt: es ist der Firmenserver :( Kann ich ggf. ALLES in /home/vpopmail ausser DOMAIN umkopieren ? cu stonki -- Deutsche ProFTP Docs: http://www.proftpd.de, EFNET: #proftpd KDE3 Renamer: http://www.krename.net KDE3 Barcode und Label Solution: http://www.kbarcode.net
Hi, ja das sollte gehen, aber die Benutzer (inkl. IDs) musst Du auf dem neuen System entsprechend anpassen. Benutzt Du vpopmail mit MySQL-DB oder ohne? Viele Grüße, Sebastian
Hallo, On Wed, 14 May 2003, Stefan Onken wrote:
webserver:~/000/qmailadmin-1.0.6 # ./configure [..] --includedir=/home/vpopmail/ --libdir=/home/vpopmail/
--libdir=DIR object code libraries in DIR [EPREFIX/lib] --includedir=DIR C header files in DIR [PREFIX/include] Du solltest also --includedir=/home/vpopmail/include --libdir=/home/vpopmail/lib verwenden, oder einfach --prefix=/home/vpopmail. Was das kompilieren angeht: Versuch mal: make LIBS="-L/home/vpopmail/lib -lvpopmail" oder make LDADD="-L/home/vpopmail/lib -lvpopmail" bzw. such im Makefile raus, wie der linker aufgerufen wird (bei automake/-conf (+libtool) Makefiles: grep -i link Makefile -dnh -- 182: Undeterministische Fehler Heisenbugs (Jens Benecke
Hallo, am Mittwoch, 14. Mai 2003 um 17:10 schrieb David Haller
webserver:~/000/qmailadmin-1.0.6 # ./configure [..] --includedir=/home/vpopmail/ --libdir=/home/vpopmail/
--libdir=DIR object code libraries in DIR [EPREFIX/lib] --includedir=DIR C header files in DIR [PREFIX/include]
Du solltest also
--includedir=/home/vpopmail/include --libdir=/home/vpopmail/lib
das ist nun interessant, da ich das GENAU anders verstanden habe. Ich dachte ich geben den PREFIX ein, und /lib und /include haengt er selber an.
Was das kompilieren angeht: Versuch mal: make LIBS="-L/home/vpopmail/lib -lvpopmail" make LDADD="-L/home/vpopmail/lib -lvpopmail"
bzw. such im Makefile raus, wie der linker aufgerufen wird (bei automake/-conf (+libtool) Makefiles: grep -i link Makefile
ok, Sebastian Wolfgarten hat mir ein wenig geholfen, kompiliert ist es nun einmal, laufen will es zwar noch immer nicht, aber wir kommen weiter .... cu stonki -- Deutsche ProFTP Docs: http://www.proftpd.de, EFNET: #proftpd KDE3 Renamer: http://www.krename.net KDE3 Barcode und Label Solution: http://www.kbarcode.net
Hallo, On Wed, 14 May 2003, Stefan Onken wrote:
am Mittwoch, 14. Mai 2003 um 17:10 schrieb David Haller [..]
webserver:~/000/qmailadmin-1.0.6 # ./configure [..] --includedir=/home/vpopmail/ --libdir=/home/vpopmail/
--libdir=DIR object code libraries in DIR [EPREFIX/lib] --includedir=DIR C header files in DIR [PREFIX/include]
Du solltest also
--includedir=/home/vpopmail/include --libdir=/home/vpopmail/lib
das ist nun interessant, da ich das GENAU anders verstanden habe. Ich dachte ich geben den PREFIX ein, und /lib und /include haengt er selber an.
Nein. Das "PREFIX" in den Angaben der Defaults fuer die Optionen ist ein Platzhalter fuer die jew. gueltige prefix, die man evtl. angegeben hat oder die eben per default (meist /usr/local) gesetzt wurde. Wenn man sich mal so ein configure-(shell!)-script anschaut, dann sieht man auch warum, denn (die script-internen shell-variablen) libdir bzw. includedir werden auf libdir='${prefix}/lib' bzw. includedir='${prefix}/include' gesetzt. Man bemerke, dass '' verwendet werden, d.h. dort wird '$prefix' _nicht_ expandiert! Die Expandierung findet dann erst im generierten Makefile statt bzw. u.U. (in seltenen Faellen) sogar erst von der von make aufgerufenen shell... Das ganze fuehrt dann zu: ./configure => prefix=/usr/local, libdir='${prefix}/lib', includedir='${prefix}/include' ./configure --prefix=/blubb => prefix=/blubb, libdir='${prefix}/lib', includedir='${prefix}/include' ./configure --prefix=/blubb --libdir=/bla => prefix=/blubb, libdir='/bla', includedir='${prefix}/include' ./configure --prefix=/blubb --libdir=/blubb/lib --includedir=/blubb/include => prefix=/blubb, libdir='/blubb/lib', includedir='/blubb/include' Man achte auf den Unterschied zwischen dem ersetn und dem letzten Beispiel! libdir='${prefix}/lib' != libdir='/blubb/lib' auch wenn ${prefix} irgendwann zu '/blubb' expandiert. Der Unterschied kann einen z.B. beim Installieren mit make prefix='/bla/blubb' install boese auffallen, da im letzten Beispiel libdir nach wie vor '/blubb/lib' ist!. Besser ist, wenn man in dem Falle ggfs: ./configure --prefix='/blubb' --libdir='${prefix}/lib' usw. verwendet, da dann auch im Makefile die (make-) Variable '${prefix}' verwendet wird. Aber das ist dann wiederum ja der default. Also: '--libdir' sollte man nur verwenden, wenn es von '/lib' abweicht: ./configure --prefix='/blubb' --libdir='${prefix}/libraries' Falls man bei --libdir nicht '${prefix}/*' verwendet, dann muss man ggfs. auch beim 'make install' das libdir explizit anpassen: ./configure --prefix='/blubb' --libdir='/blubb/libraries' make make prefix='/tmp/blubb' libdir='/tmp/blubb/libraries' Achso, die von configure erzeugten Makefiles sollte man sich diesbezueglich auch anschauen, da wird einem obiges dann klarer... Also, eigentlich haette ich in meiner letzten Mail folgendes schreiben sollen: ==== Du solltest also --prefix='/home/vpopmail' --includedir='${prefix}/include' --libdir='${prefix}/lib' verwenden. ==== Ob dir das aber beim konkreten Problem bzgl. des kompilierens von QmailAdmin geholfen haette weiss ich nicht -- dazu muesste ich mir das Makefile(.am) von QmailAdmin anschauen... Wie gesagt: includedir und libdir beziehen sich auf die Orte, an die hininstalliert werden soll -- nicht auf die evtl. einzubindenden Libs... Dafuer gibt's ggfs. die Optionen '--cflags=' bzw. '--libs' (IIRC) bzw. Umgebungsvariablen (CFLAGS/CPPFLAGS/LDFLAGS/LIBS/LDADD u.a., naeheres muss man ggfs. im Makefile nachschauen).
ok, Sebastian Wolfgarten hat mir ein wenig geholfen, kompiliert ist es nun einmal, laufen will es zwar noch immer nicht, aber wir kommen weiter ....
Schoen ;) -dnh -- 153: höflich Abwesenheit von absichtlichen Beleidigungen. (Lars Marowsky-Brée)
Am Mit, 2003-05-14 um 23.12 schrieb David Haller:
Hallo,
On Wed, 14 May 2003, Stefan Onken wrote:
am Mittwoch, 14. Mai 2003 um 17:10 schrieb David Haller [..]
webserver:~/000/qmailadmin-1.0.6 # ./configure [..] --includedir=/home/vpopmail/ --libdir=/home/vpopmail/
--libdir=DIR object code libraries in DIR [EPREFIX/lib] --includedir=DIR C header files in DIR [PREFIX/include]
Du solltest also
--includedir=/home/vpopmail/include --libdir=/home/vpopmail/lib
das ist nun interessant, da ich das GENAU anders verstanden habe. Ich dachte ich geben den PREFIX ein, und /lib und /include haengt er selber an.
Nein. Doch.
Das "PREFIX" in den Angaben der Defaults fuer die Optionen ist ein Platzhalter fuer die jew. gueltige prefix, die man evtl. angegeben hat oder die eben per default (meist /usr/local) gesetzt wurde. Nein, mit PREFIX ist hier der Wert der mittels --prefix=PREFIX übergeben wird, gemeint.
Wenn man sich mal so ein configure-(shell!)-script anschaut, dann sieht man auch warum, denn (die script-internen shell-variablen) libdir bzw. includedir werden auf
libdir='${prefix}/lib' bzw. includedir='${prefix}/include'
gesetzt. Man bemerke, dass '' verwendet werden, d.h. dort wird '$prefix' _nicht_ expandiert!
Ja.
Die Expandierung findet dann erst im generierten Makefile statt Ja.
bzw. u.U. (in seltenen Faellen) sogar erst von der von make aufgerufenen shell... Das wäre ein Bug.
Das ganze fuehrt dann zu:
./configure
=> prefix=/usr/local, libdir='${prefix}/lib', includedir='${prefix}/include'
./configure --prefix=/blubb
=> prefix=/blubb, libdir='${prefix}/lib', includedir='${prefix}/include'
./configure --prefix=/blubb --libdir=/bla
=> prefix=/blubb, libdir='/bla', includedir='${prefix}/include'
./configure --prefix=/blubb --libdir=/blubb/lib --includedir=/blubb/include => prefix=/blubb, libdir='/blubb/lib', includedir='/blubb/include'
Man achte auf den Unterschied zwischen dem ersetn und dem letzten Beispiel! So soll es auch sein.
libdir='${prefix}/lib' != libdir='/blubb/lib' auch wenn ${prefix} irgendwann zu '/blubb' expandiert. Der Unterschied kann einen z.B. beim Installieren mit
make prefix='/bla/blubb' install
boese auffallen, da im letzten Beispiel libdir nach wie vor '/blubb/lib' ist!. Ja. Faustregel:
Alle --*dir Optionen die beim Aufruf von configure übergeben werden, müssen auch beim "make *dir=.... install" wenn man "make *dir=.... install" verwendet. Ausser in rpm.specs und in komplizierten Netzwerk-Installationen wird man dies in der Regel nicht machen.
Besser ist, wenn man in dem Falle ggfs:
./configure --prefix='/blubb' --libdir='${prefix}/lib'
usw. verwendet, Hmm, es macht in sauberen Konfigurationen keinen Unterschied.
da dann auch im Makefile die (make-) Variable '${prefix}' verwendet wird. Aber das ist dann wiederum ja der default.
Also: '--libdir' sollte man nur verwenden, wenn es von '/lib' abweicht:
Nein: --libdir muss man dann verwenden, wenn es von ${prefix}/lib abweicht.
./configure --prefix='/blubb' --libdir='/blubb/libraries' make make prefix='/tmp/blubb' libdir='/tmp/blubb/libraries'
Achso, die von configure erzeugten Makefiles sollte man sich diesbezueglich auch anschauen, da wird einem obiges dann klarer...
Also, eigentlich haette ich in meiner letzten Mail folgendes schreiben sollen:
==== Du solltest also --prefix='/home/vpopmail' --includedir='${prefix}/include' --libdir='${prefix}/lib' verwenden. ====
Ob dir das aber beim konkreten Problem bzgl. des kompilierens von QmailAdmin geholfen haette weiss ich nicht
Mit sehr grosser Wahrscheinlichkeit nicht.
-- dazu muesste ich mir das Makefile(.am) von QmailAdmin anschauen...
Wie gesagt: includedir und libdir beziehen sich auf die Orte, an die hininstalliert werden soll -- nicht auf die evtl. einzubindenden Libs... Genau.
Dafuer gibt's ggfs. die Optionen '--cflags=' bzw. '--libs' Nein.
Derartige Flags werden von configure-Scripten normalerweise nicht angeboten. Wenn doch, hat entweder der Autor der Scripte nicht verstanden, wie configure-Scripte funktionieren, oder aber es handelt sich um "Convenience-Optionen" zur Behandlung von Sonderfällen (--enable-<xxx>-[cflags|libs]=...).
(IIRC) bzw. Umgebungsvariablen (CFLAGS/CPPFLAGS/LDFLAGS/LIBS/LDADD u.a., naeheres muss man ggfs. im Makefile nachschauen). ./configure --help sollte sagen welche Umgebungsvariablen verwendet werden (Ist bei autoconf-2.5x generierten configure-Scripten der Standard, bei autoconf-2.1x generierten configure-Scripten nicht)
Im Regelfall sind dies CFLAGS, CPPFLAGS, LDFLAGS. LIBS und LDADD kommen normalerweise nicht aus der Umgebung. Ralf
Hallo, On Thu, 15 May 2003, Ralf Corsepius wrote:
Am Mit, 2003-05-14 um 23.12 schrieb David Haller:
On Wed, 14 May 2003, Stefan Onken wrote:
am Mittwoch, 14. Mai 2003 um 17:10 schrieb David Haller [..]
webserver:~/000/qmailadmin-1.0.6 # ./configure [..] --includedir=/home/vpopmail/ --libdir=/home/vpopmail/
--libdir=DIR object code libraries in DIR [EPREFIX/lib] --includedir=DIR C header files in DIR [PREFIX/include]
Du solltest also
--includedir=/home/vpopmail/include --libdir=/home/vpopmail/lib
das ist nun interessant, da ich das GENAU anders verstanden habe. Ich dachte ich geben den PREFIX ein, und /lib und /include haengt er selber an.
Nein. Doch.
Nein. Wie du unten selbst schreibst. Das PREFIX in der Frage von Stonki oben bezog sich auf das "PREFIX" in der Defaultangabe von --libdir=. Und er dachte, es reicht, wenn man den "PREFIX"-Teil von --libdir, z.B. "--libdir=/blubb" angibt und dies dann automatisch noch um "/lib" zu "/blubb/lib" ergaenzt wird. Du hast dich aber natuerlich auf das PREFIX von --prefix=/blubb bezogen und das wird ja dann automatisch zu libdir='${prefix}/lib' -- es sei denn, man setzt libdir explizit mit --libdir=...
Das "PREFIX" in den Angaben der Defaults fuer die Optionen ist ein Platzhalter fuer die jew. gueltige prefix, die man evtl. angegeben hat oder die eben per default (meist /usr/local) gesetzt wurde. Nein, mit PREFIX ist hier der Wert der mittels --prefix=PREFIX übergeben wird, gemeint.
Das meinte ich. War bloed formuliert. Das PREFIX bei den --*dir Optionen steht fuer das PREFIX das (evtl.) durch --prefix=PREFIX uebergeben wird oder eben (ohne --prefix) fuer die default-prefix. [..]
Die Expandierung findet dann erst im generierten Makefile statt Ja.
bzw. u.U. (in seltenen Faellen) sogar erst von der von make aufgerufenen shell... Das wäre ein Bug.
Wieso? *g* Und u. bes. U. kann das sogar sinnvoll sein *eg*. z.B. um einen Shell-Befehl zu definieren, der dann erst in der shell in einer Regel expandiert werden soll. Schliesslich kann man mit make auch mehr als nur kompilieren, und bei anderen Sachen braucht man sowas eventuell. [..]
Besser ist, wenn man in dem Falle ggfs:
./configure --prefix='/blubb' --libdir='${prefix}/lib'
usw. verwendet, Hmm, es macht in sauberen Konfigurationen keinen Unterschied.
Genau. Das emuliert ja den Default, wo dann im Makefile landet: prefix = /blubb libdir = ${prefix}/lib Dann reicht es, ein make prefix="/bla/blubb" install zu verwenden und die make-Variable 'libdir' expandiert unter "Verwendung" von ${prefix} zu '/bla/blubb/lib' ;)
Also: '--libdir' sollte man nur verwenden, wenn es von '/lib' abweicht: Nein: --libdir muss man dann verwenden, wenn es von ${prefix}/lib abweicht.
Stimmt. [..]
Wie gesagt: includedir und libdir beziehen sich auf die Orte, an die hininstalliert werden soll -- nicht auf die evtl. einzubindenden Libs... Genau.
Dafuer gibt's ggfs. die Optionen '--cflags=' bzw. '--libs' Nein.
Derartige Flags werden von configure-Scripten normalerweise nicht angeboten.
Hab ich schon oefters gesehen...
Wenn doch, hat entweder der Autor der Scripte nicht verstanden, wie configure-Scripte funktionieren, oder aber es handelt sich um "Convenience-Optionen" zur Behandlung von Sonderfällen (--enable-<xxx>-[cflags|libs]=...).
Nein.
(IIRC) bzw. Umgebungsvariablen (CFLAGS/CPPFLAGS/LDFLAGS/LIBS/LDADD u.a., naeheres muss man ggfs. im Makefile nachschauen). ./configure --help sollte sagen welche Umgebungsvariablen verwendet werden (Ist bei autoconf-2.5x generierten configure-Scripten der Standard, bei autoconf-2.1x generierten configure-Scripten nicht)
Im Regelfall sind dies CFLAGS, CPPFLAGS, LDFLAGS.
Ja. Die o.g. Optionen dienen in den Faellen als _Alternative_ zu diesen Umgebungsvariablen. Es sind dann aequivalent: $ export CPPFLAGS="-I/blubb"; ./configure $ CPPFLAGS="-I/blubb" ./configure $ ./configure --cppflags="-I/blubb" Die letztere Variante halte ich eigentlich fuer prinzipiell auch sinnvoll. Welche "Variante" "gewinnt" wenn man beides gleichzeitig verwendet habe ich nicht getestet, vermutlich aber die Option.
LIBS und LDADD kommen normalerweise nicht aus der Umgebung.
Ja. -dnh -- == Re: Exchange's mailbox format == I hope that's not UI -- but the proper term is a "Jet database", accessed through the "Jet engine". A fitting name, considering that it sucks and blows. -- Felix
Am Don, 2003-05-15 um 13.11 schrieb David Haller:
Hallo,
On Thu, 15 May 2003, Ralf Corsepius wrote:
Am Mit, 2003-05-14 um 23.12 schrieb David Haller:
On Wed, 14 May 2003, Stefan Onken wrote:
am Mittwoch, 14. Mai 2003 um 17:10 schrieb David Haller [..]
webserver:~/000/qmailadmin-1.0.6 # ./configure [..] --includedir=/home/vpopmail/ --libdir=/home/vpopmail/
--libdir=DIR object code libraries in DIR [EPREFIX/lib] --includedir=DIR C header files in DIR [PREFIX/include]
Du solltest also
--includedir=/home/vpopmail/include --libdir=/home/vpopmail/lib
das ist nun interessant, da ich das GENAU anders verstanden habe. Ich dachte ich geben den PREFIX ein, und /lib und /include haengt er selber an.
Nein. Doch.
Nein. Wie du unten selbst schreibst. Das PREFIX in der Frage von Stonki oben bezog sich auf das "PREFIX" in der Defaultangabe von --libdir=. Und er dachte, es reicht, wenn man den "PREFIX"-Teil von --libdir, z.B. "--libdir=/blubb" angibt und dies dann automatisch noch um "/lib" zu "/blubb/lib" ergaenzt wird.
OK, das ist etwas anderes und ich verstand miss.
Du hast dich aber natuerlich auf das PREFIX von --prefix=/blubb bezogen und das wird ja dann automatisch zu libdir='${prefix}/lib' -- es sei denn, man setzt libdir explizit mit --libdir=...
Das "PREFIX" in den Angaben der Defaults fuer die Optionen ist ein Platzhalter fuer die jew. gueltige prefix, die man evtl. angegeben hat oder die eben per default (meist /usr/local) gesetzt wurde. Nein, mit PREFIX ist hier der Wert der mittels --prefix=PREFIX übergeben wird, gemeint.
Das meinte ich. War bloed formuliert. Das PREFIX bei den --*dir Optionen steht fuer das PREFIX das (evtl.) durch --prefix=PREFIX uebergeben wird oder eben (ohne --prefix) fuer die default-prefix.
[..]
Die Expandierung findet dann erst im generierten Makefile statt Ja.
bzw. u.U. (in seltenen Faellen) sogar erst von der von make aufgerufenen shell... Das wäre ein Bug.
Wieso? *g* Und u. bes. U. kann das sogar sinnvoll sein *eg*. z.B. um einen Shell-Befehl zu definieren, der dann erst in der shell in einer Regel expandiert werden soll. Weil diese Variablen von make expandiert werden sollen ;)
Ein Klassiker in diesem Zusammenhang ist die Behandlung von LOCALEDIR: [Aus info://gettext] To make LOCALEDIR known to the program, add the following lines to Makefile.in: datadir = @datadir@ localedir = $(datadir)/locale DEFS = -DLOCALEDIR=\"$(localedir)\" @DEFS@ Note that `@datadir@' defaults to `$(prefix)/share', thus `$(localedir)' defaults to `$(prefix)/share/locale'. Beachte: localedir wird von make expandiert!
Dafuer gibt's ggfs. die Optionen '--cflags=' bzw. '--libs' Nein.
Derartige Flags werden von configure-Scripten normalerweise nicht angeboten.
Hab ich schon oefters gesehen...
Nun, IIRC hat Lyx z.B. derartige Optionen - Wenn sie meinen. Es steht jedem Autor frei zu tun und zu lassen was er will. Doch glaube mir, so etwas ist gröbster Unfug und lediglich ein Beweis dafür, dass die Autoren nicht verstanden haben, wie die Dinge funktionieren oder aber das die Konfiguration eine Paketes schlecht designed ist. Ralf
participants (7)
-
David Haller -
Peter Wiersig -
Philipp Thomas -
Ralf Corsepius -
Sebastian Wolfgarten -
Stefan Onken -
Thomas Hertweck