Am Son, 2002-07-14 um 13.43 schrieb David Haller:
Hallo,
On Sun, 14 Jul 2002, Ralf Corsepius wrote:
Am Sam, 2002-07-13 um 22.57 schrieb David Haller:
Naja, dann eben etwas aufwendiger und unkomprimiert "inline"...
,----[ ~/src/libdemo/Makefile.am ] | lib_LTLIBRARIES = libdemo.la | | libdemo_la_SOURCES = demo.c | include_HEADERS = demo.h | | bin_PROGRAMS = demo_prog | | demo_prog_SOURCES = demo_prog.c | demo_prog_LDADD = -L./.libs -ldemo Falsch: Nie .libs verwenden. Ist ein internes Implementierungsdetail, und kann abhängig vom Build-OS seinen Namen ändern.
Richtig wäre: demo_prog_LDADD = ./libdemo.la
Ups. Das stimmt. Hatte ich uebersehen ;)
| | test check: | LD_LIBRARY_PATH="./.libs" ./demo_prog `---- Siehe oben, ausserdem überflüssig. Libtool kümmert sich darum.
Naja, normal baut man (normale) Programme ja nicht mit libtool... Oh, doch!
Wenn ein Paket libtool zum Bauen von libs verwendet und gleichzeitig Programme beinhaltet, sorgt automake dafür, dass libtool auch für Programme verwendet wird. libtool erzeugt dann ein Script, dass genauso heisst wie das eigentliche Executable, welches sich dann aber um LD_LIBRARY_PATH usw. kümmert, um die LIBS aus dem BUILD-Verzeichnis aufzugreifen. Bei der Installation (make install) wird anschliessed nicht dieses Script installiert, sondern das eigentliche Binary.
$ make CFLAGS="$CFLAGS -I../libdemo" \ LDFLAGS="$LDFLAGS -L../libdemo/test_installed/lib -ldemo" demo_prog cc -O2 -I../libdemo -L../libdemo/test_installed/lib -ldemo demo_prog.c -o demo_prog $ ldd ./demo_prog libdemo.so.0 => not found libc.so.6 => /lib/libc.so.6 (0x40026000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Hier liegt's schlicht daran, dass ld/ldd nix von dem test_installed weiss (und soll!). Ja, wenn Du Libtool nicht verwendest.
Der Gag an libtool ist ja genau das es die Komplexität und Nicht-Portabilität derartiger Dinge zu verstecken und zu abstrahieren versucht (LD_LIBRARY_PATH ist hochgradig OS-abhängig und unportabel.)
$ LD_LIBRARY_PATH="../libdemo/test_installed/lib" ldd ./demo_prog libdemo.so.0 => ../libdemo/test_installed/lib/libdemo.so.0
Es geht hier ja nur um's ausfueheren zur Demo, dass man gegen die lib linken kann ;)
So gehts: lib_LTLIBRARIES = libhello.la libhello_la_SOURCES = dohello.c dohello.h libhellodir = $(includedir)/libhello libhello_INCLUDES = dohello.h bin_PROGRAMS = hello hello_SOURCES = hello.c hello_LDADD = ./libhello.la check: ./hello
Die, die nicht automatisch generiert werden sollten von Hand geschrieben werden oder durch geeignete AUTOMAKE_OPTIONS umgangen werden (z.B. AUTOMAKE_OPTIONS = foreign in Makefile.ams, oder AM_INIT_AUTOMAKE([foreign]) in configure.acs mit automake >= 1.6)
Ahso. Ich muss gestehen, das hab ich noch gar nicht gekannt, habe aber auch nicht danach gesucht, da ich's normalerweise ja fuer sinnvoll halte ;) Sind sie auch. Automake ohne AUTOMAKE_OPTIONS verfolgt die gnu-Standards nach denen gewisse informative Dateien vorgeschrieben sind.
Will man diese nicht, dann entweder AUTOMAKE_OPTIONS = foreign in jedes Makefile.am einfügen oder (Ab automake-1.6) AM_INIT_AUTOMAKE([foreign]) im configure.ac verwenden.
-dnh, oh, good Sigmonster!
ObSCNR: "So liebe Mitlisties, ab morgen macht Onkel Ralf einen Kurs fuer autoconf/automake/libtool und Konsorten, bitte Material fuer Notizen mitbringen sowie genuegend Kaffee/Tee etc." ;)
PS: Kennst du "Recursive Make Considered Harmful" von Peter Miller? s. http://www.canb.auug.org.au/~millerp/ Kenn, ich - IMHO, einer der meist überschätzten Artikel ;).
Der Autor hat zwar in weiten Bereichen recht, doch eines wird dabei übersehen: Non-recursive Makefiles geraten für "nicht-triviale" Projekte sehr schnell "unmaintainable". Auch gibt es Fälle, in non-recursive Makefiles nicht anwendbar sind (z.B. Canadian Crosses; vgl. http://www.airs.com/ian/configure.) Ralf