Hallo Dennis, On Sat, 29 Jun 2002 at 17:44 (+0200), Dennis Stosberg wrote:

Am 29.06.2002 um 15:41 schrieb Bernhard Walle:

...

mich würde mal interessieren, wie man mit den GNU-Entwicklertools in C eine einfache Bibliothek (.so, also dynamisch linkbar) erstellt und v. a. kompiliert. Gibt's dazu irgendwie Literatur im Netz?

Normalerweise sollte es sich doch einfach um ein 'normales' C-Programm ohne Main-Funktion und um eine Header-Datei handeln, oder irre ich da?

Vielleicht hilft dir

http://www.tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

weiter.

Vielen Dank! Genau sowas habe ich gesucht. Gruß, Bernhard PS: Heute habe ich ausnahmsweise genug "n" auf Vorrat. :-) -- lp1 on fire -- One of the more obfuscated kernel messages

Am Sam, 2002-07-13 um 09.27 schrieb Bernhard Walle:

On Sat, 13 Jul 2002 at 06:44 (+0200), David Haller wrote:

...

On Sat, 29 Jun 2002, Bernhard Walle wrote:

...

mich würde mal interessieren, wie man mit den GNU-Entwicklertools in C eine einfache Bibliothek (.so, also dynamisch linkbar) erstellt und v. a. kompiliert. Gibt's dazu irgendwie Literatur im Netz?

Ein wenig steht auch in den infopages der Tools. Am einfachsten ist wohl libtool zu verwenden (siehe z.B. info automake und info libtool).

Ich hab's befürchtet, dass da was dazu steht. Nur leider sucht man sich in solchen Infopages immer dumm und dämlich. Außerdem wollte ich nur einen kurzen Überblick; dafür war das HOWTO wesentlich besser geeignet.

http://sources.redhat.com/autobook Ralf

Hallo, On Sat, 13 Jul 2002, David Haller wrote:

Ok, da auch noch ne PM kam und bei < 1kb, da haeng ich's einfach mal an...

*grummel* Wurde entfernt. Vorschlag an den Listowner: 5-10 KB Limit fuer Attachments ;) 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 | | test check: | LD_LIBRARY_PATH="./.libs" ./demo_prog `---- *hehe* jetzt kann ich das Makefile.am sogar noch kommentieren: Wenn das ganze groesser wird, so wird das evtl. in Subdirs aufgespalten. s.u. ,----[ ~/src/libdemo/autogen.sh ] | #!/bin/sh | INST_PREFIX="${PWD}/test_installed" | | touch AUTHORS COPYING ChangeLog INSTALL NEWS README | aclocal | automake -a -v | autoconf | ./configure --prefix="${INST_PREFIX}" | set -x | make | make check | make install | if test -z "$LD_LIBRARY_PATH"; then | LD_LIBRARY_PATH="${INST_PREFIX}/lib" | else | LD_LIBRARY_PATH="${INST_PREFIX}/lib:$LD_LIBRARY_PATH" | fi | ${INST_PREFIX}/bin/demo_prog | set +x `---- ,----[ ~/src/libdemo/configure.in ] | AC_INIT(demo.h) | AM_INIT_AUTOMAKE(libdemo, 0.0.1) | AC_PROG_CC | AM_PROG_LIBTOOL | AC_OUTPUT(Makefile) `---- ,----[ ~/src/libdemo/demo.c ] | #include | | void demo_function(void) { | printf("Demo Library\n"); | return; | }; `---- ,----[ ~/src/libdemo/demo.h ] | #ifndef LIBDEMO_DEMO_H | #define LIBDEMO_DEMO_H | | #include | | extern void demo_function(void); | | #endif `---- ,----[ ~/src/libdemo/demo_prog.c ] | #include | | int main(void) { | demo_function(); | return 0; | } `---- Beispiel mit subdirs (ungetestet -- nur hier in der Mail "mal eben" hingetippt um die Grundidee zu illustrieren): ,----[ ~/src/libdemo/Makefile.am ] | SUBDIRS = include src test `---- ,----[ ~/src/libdemo/include/Makefile.am ] | include_HEADERS = demo.h `---- ,----[ ~/src/libdemo/src/Makefile.am ] | lib_LTLIBRARIES = libdemo.la | | INCLUDES = -I$(top_srcdir)/include | libdemo_la_SOURCES = demo.c private.c | include_HEADERS = private.h `---- ,----[ ~/src/libdemo/test/Makefile.am ] | bin_PROGRAMS = demo_prog | | INCLUDES = -I$(top_srcdir)/include | demo_prog_SOURCES = demo_prog.c | demo_prog_LDADD = -L$(top_srcdir)/src/.libs -ldemo | | test check: | LD_LIBRARY_PATH="$(top_srcdir)/src/.libs" ./demo_prog `---- -dnh -- "But you've got to hand it to IBM, they know how to design hardware. The servers all had handles to pick them up and throw them out of the window...." --Juergen Nieveler in the Monastery

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... $ 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!). $ 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 ;)

...

,----[ ~/src/libdemo/autogen.sh ] | #!/bin/sh | INST_PREFIX="${PWD}/test_installed" | | touch AUTHORS COPYING ChangeLog INSTALL NEWS README Wozu?

Wozu bei sowas die "normalen" fetten COPYING und INSTALL? Und Fehlermeldungen will man auch nicht unbedingt.

automake -a sorgt für die automatisch generierten Dateien.

Eben. Und obige brauchte ich hier nu wirklich nicht.

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 ;)

...

| AC_PROG_CC | AM_PROG_LIBTOOL Hier wäre ein AC_[ENABLE|DISABLE]_SHARED sinnvoll

Ack. Aber ich wollte ja keine Automake/-conf Einfuehrung geben ;)

BTW: Ab automake-1.6 AM_CPPFLAGS statt INCLUDES in Makefile.am verwenden (Wird auch von automake-1.6 schon unterstützt, INCLUDES ist ab automake-1.7 (Noch nicht veröffentlicht) "obsolete").

Ok. Auch fuer die restlichen Hinweise/Korrekturen vielen Dank :) Insgesamt "Quick & Dirty" eben :) Wie man schon an deinen Kommentaren zu den neueren auto-Tools sieht kommt man dann eben sehr schnell vom hundertsten ins tausendste und das will und kann ich nicht erklaeren, dazu bin ich selbst noch zu sehr Anfaenger ;) Wuerde mich freuen, wenn wir das Thema aber noch fortsetzen koennen, ich lerne da gerne mehr :) -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/ -- 1. Every good work of software starts by scratching a developer's personal itch. --- Eric S. Raymond, "The Cathedral and the Bazaar"

Hallo Ralf, On Mon, 15 Jul 2002, Ralf Corsepius wrote:

Am Son, 2002-07-14 um 13.43 schrieb David Haller:

...

On Sun, 14 Jul 2002, Ralf Corsepius wrote:

...

Am Sam, 2002-07-13 um 22.57 schrieb David Haller: [..] 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.

Ja, wie gesagt, das war mir neu, ich meinte (in der letzten Mail) aber explizit ein nicht zum Paket gehoeriges Programm. Sagen wir: libmysql und mein eigenes Programm, das die libmysql verwendet... Dann erstelle ich mein Proggi ja nicht mit libtool, sondern eben mit den ueblichen Mechanismen (z.B. via mysql-config --cflags etc. pp.)... Dann, wenn die lib installiert ist, dann nimmt man ja z.B. (indirekt) explizit "-L/usr/lib/myslq" usw. [..]

...

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.)

Ah, ok, die Portabilitaet wg. LD_LIBRARY_PATH hab ich ignoriert -- schon wieder was gelernt :))

...

Es geht hier ja nur um's ausfueheren zur Demo, dass man gegen die lib linken kann ;)

So gehts: [..]

Merci vielmals! Aber wie gesagt: _mir_ ging's hier (erstmal! -- weiteres hast du ja inzwischen beigesteuert :) nur darum, dass sich generell irgendein(!) (also eben auch nicht zum Paket gehoeriges) gegen so eine lib linken laesst. Ich hab das Prog auch wirklich nur dazu hingeschludert (und "irgendwie" kompiliert/gelinkt ;) um zu demonstrieren, dass sich "so simpel" diesem Grundansatz (libtool/automake/autoconf) (von dir nun verbessert) eine lib erstellen laesst. Ausserdem bin ich (aus eigener Erfahrung) der Ansicht, dass man, gerade wenn man erst anfaengt mit C/C++ usw., sich nicht gleich in allzu grosser Portabilitaet verzetteln sollte; d.h. "erstmal" reicht z.B. das von mir hier gemailte, um erste Erfahrungen zu sammeln, ohne gleich (im Vergleich zum eigentlichen Programm/library) zu viel Aufwand in die Portabilitaet zu stecken. Wichtig ist bei diesem Ansatz IMO nur eins: Dass man _weiss_, dass man potentiell/teilweise unportabel ist! Ich versuche hier z.B. v.a. erstmal fuer Linux (genauer: erstmal nur fuer das "komische System" auf (nur!) meiner Kiste!) zu programmieren... Ohne Grundlagenwissen werde ich nie portabel programmieren koennen, und mir fehlt z.B. v.a. das Wissen, _was_ nicht portabel ist. Manches findet man z.B. in den manpages ("conforms to POSIX vFOO", von welchen OS aber POSIX vFOO eingehalten wird weiss ich aber auch nicht ;). Und dennoch, wenn's wie jetzt hier, zum Thema wird, dann bin ich dir sehr dankbar, wenn du auf Probleme/Konflikte usw. hinweist. Das macht mir das Problem wieder einmal mehr bewusst -- auch wenn ich mich dann meist (nun eben bewusst und explizit) dafuer entscheide, doch (erstmal) evtl. unportabel nur fuer (mein) Linux zu programmieren... Die Probleme, die ich kenne (sind aber eben erst wenige), die versuche ich aber zu beruecksichtigen, z.B. in dem ich statt #define FOO bar folgendes schreibe: #if defined(__GNUC__) && defined(__linux__) #define FOO bar #else #error not implemented #endif oder: #ifdef HAVE_CONFIG_H #include #endif #ifndef PATHSEP # ifdef __unix__ # define PATHSEP '/' # elif __WIN32__ # define PATHSEP '\\' # else # error ...irgendwas passendes ;)... # endif #endif (wobei man PATHSEP via automake/-conf/-header oder so definieren lassen koennte/sollte *g* Und nein, ich weiss nicht, ob __unix__ ein passendes "define" ist... ist jetzt von mir nur geraten, ob das vom cc auf HPUX, AIX oder sonstwo auch gesetzt wird weiss ich nicht, aber(!): dank des defines habe ich eine (einfache) Moeglichkeit mich ggfs. um sowas zu kuemmern ;) Oder sonstwas in der Art -- wenn ich um moegliche Konflikte weiss, versuche ich eine einfache Moeglichkeit diese zu umgehen einzubauen ;) _Wie_ das dann geschehen koennte, muss ich dabei ja gar nicht wissen ;) Aber wie gesagt, zu Anfang halte ich sowas mehr oder weniger fuer overkill... genauso wie fuer ein "Hello World" der auto* usw. -Kram overkill ist -- es sei denn, man will ein Beispiel fuer eben diesen Kram liefern ;)

...

...

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.

*g*

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.

Ok. Danke als nochmal fuer den Hinweis. Ich seh schon, ich will mich noch naeher mit den Tools beschaeftigen :) Mangels Interesse daran hab ich halt bisher einfach nicht danach geschaut -- ich will den GNU-Kram ja normalerweise :) Und ja, auch jetzt nach deinem Tip wuerde ich's wohl wieder so machen, so als ("hinterhaeltiger") Hinweis, dass man das doch bitte verwenden moege ;))

...

-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".

*g* Ack, denke ich. Was mich aber selbst bei meinen bisher eher winzigen Sachen nervt, ist dass der ganze redundante Kram in jedem Makefile auftaucht -- denn ich sehe, dass top_srcdir gesetzt wird, und somit liegt ein 'include $(top_srcdir)/generic.rules' (oder so) nahe, in dem die Rules sind, die sowieso in allen Makefiles auftauchen... Ansonsten versuche ich z.Z. beides unter einen Hut zu bekommen... Das "schwelt" grad bei mir... ;) Was Miller aber gerade ueber das Thema der Abhaengigkeiten schreibt, dem bin ich selbst bei meinen "test-libraries", die ich zum lernen des Themas gebastelt habe, schon begegnet... Schon da hab ich -- evtl. (oder sogar vermutlich) wg. meines mangelden Wissens ueber die auto*-Tools und make) "rumtricksen" muessen und irgendwelche bloede Abhaengigkeiten haendisch einfuegen muessen usw., die dann sowieso nie auf Anhieb klappten... Den Punkt von Miller, also der _einzige_ "Baum" (IIRC) der Abhaengigkeiten, der hat mir unmittelbar eingeleuchtet :) Und ja, ich behaupte nicht, ich haette make wirklich "richtig" verwendet, aber das tun (leider) die wenigsten, wenn ich das was mir so in Makefiles begegnet anschaue...

Auch gibt es Fälle, in non-recursive Makefiles nicht anwendbar sind (z.B. Canadian Crosses; vgl. http://www.airs.com/ian/configure.)

Das kann ich leider nicht beurteilen, da ich's nicht kenne, und heut bin ich schon zu muede... Das Thema interessiert mich aber doch ziemlich! Leider hab ich mir auch "cook" von Miller noch nicht angeschaut -- hast du? -dnh PS: Ein Projekt in der Richtung, das wuerde mich doch ziemlich interessieren ;)) PPS: Ansonsten: ich bin ein Fan von 'make' -- fuer alles moegliche ;) von der sendmail-config ueber alles was mit TeX zu tun hat bis sonstwas :) PPPS: in der Beziehung wird einem mal wieder klar, wie schoen OpenSource ist :) file `which FOO`: -> 'perl'? Oh, geil, da kann ich dann ja sofort drin rumhacken *eg* (gut dass man sich das "Orijinoool" jederzeit wieder saugen kann ;) /me verunstaltet z.Z. grepmail *eg* -> ELF? ok, 'locate'... *mift* *ok, Quellen saug* Ah, C/C++? Dann schau' ich mal ob ich die mich interessierenden Stellen finde... *grep grep grep* *auf gut Glueck mal rumhack* *make* *flatsch auf die Nase fall* *macht nix* *gruendlicher such* ( while(!ok) { *weiterhack && make* } ) *JIPPIAYEAH - Schweinebacke!* *LOL* Bloed nur (fuer das Ego), wenn und meist sogar dass, bis man fertig is, die Autoren des Originals das gleiche -- und besser -- gemacht haben ;) -- "Ich mach mal den Vollquottel Wegen verglkeich!" [Woko° in dag°]