Moin,
in proftp in Debian haben wir folgenden Patch:
Index: proftpd-dfsg/contrib/mod_sql_odbc.c =================================================================== --- proftpd-dfsg.orig/contrib/mod_sql_odbc.c 2018-01-14 23:24:03.000000000 +0100 +++ proftpd-dfsg/contrib/mod_sql_odbc.c 2018-01-15 20:49:02.000000000 +0100 @@ -19,6 +19,7 @@ * As a special exemption, TJ Saunders gives permission to link this program * with OpenSSL, and distribute the resulting executable, without including * the source code for OpenSSL in the source distribution. + * $Libraries: -lodbc $ */
#include "conf.h"
i.e. im Kommentar wird etwas eingefügt. Da ich nicht so recht weiß, wonach ich googeln soll: wozu ist der Kommentar gut?
Hilmar
Hallo,
On Sun, Mar 29, 2020 at 09:47:33PM +0200, Hilmar Preuße wrote:
Index: proftpd-dfsg/contrib/mod_sql_odbc.c
--- proftpd-dfsg.orig/contrib/mod_sql_odbc.c 2018-01-14 23:24:03.000000000 +0100 +++ proftpd-dfsg/contrib/mod_sql_odbc.c 2018-01-15 20:49:02.000000000 +0100 @@ -19,6 +19,7 @@
- As a special exemption, TJ Saunders gives permission to link this
program
- with OpenSSL, and distribute the resulting executable, without including
- the source code for OpenSSL in the source distribution.
*/
- $Libraries: -lodbc $
-lodbc ist ein Linker Flag und gegen das entsprechende Shared Object zu linken. In diesem Fall libodbc (www.unixodbc.org resp. libodbc1 Debian Package).
proftpd hat da einen recht "interessanten" Mechanismus für seine contrib Module um das in der autoconf/automake zu verwursten. Idee scheint zu sein, die contrib Module einfach in den Source Tree packen zu können, ohne dass der Build Mechanismus angepasst werden muss.
Schau mal in configure resp. configure.in. Dort wir der Kram mit sed aus den Source Files "verwursted".
Ob das tatsächlich auf die Erkennung der libs beim configure Lauf einwirkt, oder bloss die Flags beim Linken hinzufügt kann ich nicht genau sagen, dazu kenne ich das automake Zeugs zu schlecht.
TL;DR; es sollte IMHO drin bleiben wenn man mod_sql_odbc erfolgreich kompilieren möchte. Es sei denn das Debian Paket fummelt noch anderweitig in den Linker Flags rum (hab ich mir jetzt nicht angeschaut).
Grüsse Andreas
Am 29.03.2020 um 22:31 teilte Andreas Fett mit:
On Sun, Mar 29, 2020 at 09:47:33PM +0200, Hilmar Preuße wrote:
Moin,
-lodbc ist ein Linker Flag und gegen das entsprechende Shared Object zu linken. In diesem Fall libodbc (www.unixodbc.org resp. libodbc1 Debian Package).
OK, klar soweit.
Schau mal in configure resp. configure.in. Dort wir der Kram mit sed aus den Source Files "verwursted".
Hmm, leider weiß ich nicht welches configure Du meinst. In contrib selber gibt es keines und im Main Directory finde ich nicht zum Thema odbc.
TL;DR; es sollte IMHO drin bleiben wenn man mod_sql_odbc erfolgreich kompilieren möchte. Es sei denn das Debian Paket fummelt noch anderweitig in den Linker Flags rum (hab ich mir jetzt nicht angeschaut).
So, ich habe jetzt das Paket zweimal gebaut: einmal mit, einmal ohne Patch. Wenn man das erzeugte Shared Object vergleicht fällt nur auf, daß das eine gegen libodbc.so.2 gelinkt ist, das Andere nicht.
hille@debian-amd64-sid:~/devel/proftp_debian/git$ ldd mod_sql_odbc.so linux-vdso.so.1 (0x00007ffd2f185000) libodbc.so.2 => /usr/lib/x86_64-linux-gnu/libodbc.so.2 (0x00007f6c7ec90000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6c7eacd000) libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f6c7eac2000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6c7eaa1000) /lib64/ld-linux-x86-64.so.2 (0x00007f6c7ed1f000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6c7ea9c000) hille@debian-amd64-sid:~/devel/proftp_debian/git$ ldd mod_sql_odbc_wo.so linux-vdso.so.1 (0x00007ffe497b6000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f30a3bf9000) /lib64/ld-linux-x86-64.so.2 (0x00007f30a3dd9000)
Wenn man sich nm -D anschaut gibt es keine Unterschiede. Das einzige Symbol, was auf odbc hinweist ist "sql_odbc_module". Ich wäre schon mal schwer davon ausgegangen, daß der Link fehlschlägt, wenn ein Symbol nicht aufgelöst werden kann. Weiterhin läßt sich der proftp auch mit der "reduzierten" Variante des Moduls laden.
H.
Hallo,
On Sun, Mar 29, 2020 at 11:48:41PM +0200, Hilmar Preuße wrote:
Schau mal in configure resp. configure.in. Dort wir der Kram mit sed aus den Source Files "verwursted".
Hmm, leider weiß ich nicht welches configure Du meinst. In contrib selber gibt es keines und im Main Directory finde ich nicht zum Thema odbc.
Ich mein configure(.in) im Toplevel Verzeichnis des Upstream oder Debian Source Repositories (~ line 3650 im master des Debian Repos).
if test -f $srcdir/contrib/$moduledir/$src ; then srcarch=`sed -n '/.*$Archive: (.*)$.*/s//\1/p' "$srcdir/contrib/$moduledir/$src"` srclib=`sed -n '/.*$Libraries: (.*)$.*/s//\1/p' "$srcdir/contrib/$moduledir/$src"` else srcarch= srclib= fi
if test -f $srcdir/contrib/$moduledir/$srcinc ; then if test -z $srcarch ; then incarch=`sed -n '/.*$Archive: (.*)$.*/s//\1/p' "$srcdir/contrib/$moduledir/$srcinc"` else incarch= fi
inclib=`sed -n '/.*$Libraries: (.*)$.*/s//\1/p' "$srcdir/contrib/$moduledir/$srcinc"` else incarch= inclib= fi
Da werden die entsprechenden Angaben offensichtlich extrahiert.
So, ich habe jetzt das Paket zweimal gebaut: einmal mit, einmal ohne Patch. Wenn man das erzeugte Shared Object vergleicht fällt nur auf, daß das eine gegen libodbc.so.2 gelinkt ist, das Andere nicht.
hille@debian-amd64-sid:~/devel/proftp_debian/git$ ldd mod_sql_odbc.so linux-vdso.so.1 (0x00007ffd2f185000) libodbc.so.2 => /usr/lib/x86_64-linux-gnu/libodbc.so.2 (0x00007f6c7ec90000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6c7eacd000) libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f6c7eac2000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6c7eaa1000) /lib64/ld-linux-x86-64.so.2 (0x00007f6c7ed1f000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6c7ea9c000) hille@debian-amd64-sid:~/devel/proftp_debian/git$ ldd mod_sql_odbc_wo.so linux-vdso.so.1 (0x00007ffe497b6000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f30a3bf9000) /lib64/ld-linux-x86-64.so.2 (0x00007f30a3dd9000)
Was auch immer mod_sql_odbc_wo.so sein mag. Vll. "without"?
Wenn man sich nm -D anschaut gibt es keine Unterschiede. Das einzige Symbol, was auf odbc hinweist ist "sql_odbc_module". Ich wäre schon mal schwer davon ausgegangen, daß der Link fehlschlägt, wenn ein Symbol nicht aufgelöst werden kann. Weiterhin läßt sich der proftp auch mit der "reduzierten" Variante des Moduls laden.
Ich denke mal die Module werden via dlopen(3) geladen. Damit ist das Starten des daemons erstmal kein Problem solange das Modul nicht in der Config auftaucht. Siehe modules/mod_dso.c. Vll. ist diese _wo.so auch sonne Art Dummy, dass es sogar dann funzt. Ich bezweifele allerding, dass das Paket proftpd-mod-mysql dann wirklich funktioniert.
Grüsse Andreas
Am 30.03.2020 um 00:25 teilte Andreas Fett mit:
On Sun, Mar 29, 2020 at 11:48:41PM +0200, Hilmar Preuße wrote:
Moin,
Sorry Leute für die lange Funkstille! Ich habe Euch / den Thread nicht vergessen, nur keine Zeit zum Antworten.
Schau mal in configure resp. configure.in. Dort wir der Kram mit sed aus den Source Files "verwursted".
Hmm, leider weiß ich nicht welches configure Du meinst. In contrib selber gibt es keines und im Main Directory finde ich nicht zum Thema odbc.
Ich mein configure(.in) im Toplevel Verzeichnis des Upstream oder Debian Source Repositories (~ line 3650 im master des Debian Repos).
<Code Snip>
Da werden die entsprechenden Angaben offensichtlich extrahiert.
Augenscheinlich. Auf jeden Fall wird libtool zum Build mit der Option "-lodbc" aufgerufen, was ohne den Patch nicht passiert. Sonst wurde am Build Dir nicht geändert.
So, ich habe jetzt das Paket zweimal gebaut: einmal mit, einmal ohne Patch. Wenn man das erzeugte Shared Object vergleicht fällt nur auf, daß das eine gegen libodbc.so.2 gelinkt ist, das Andere nicht.
hille@debian-amd64-sid:~/devel/proftp_debian/git$ ldd mod_sql_odbc.so linux-vdso.so.1 (0x00007ffd2f185000) libodbc.so.2 => /usr/lib/x86_64-linux-gnu/libodbc.so.2 (0x00007f6c7ec90000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6c7eacd000) libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f6c7eac2000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6c7eaa1000) /lib64/ld-linux-x86-64.so.2 (0x00007f6c7ed1f000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6c7ea9c000) hille@debian-amd64-sid:~/devel/proftp_debian/git$ ldd mod_sql_odbc_wo.so linux-vdso.so.1 (0x00007ffe497b6000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f30a3bf9000) /lib64/ld-linux-x86-64.so.2 (0x00007f30a3dd9000)
Was auch immer mod_sql_odbc_wo.so sein mag. Vll. "without"?
Ja, w/o. Ich habe den Patch einfach weg gelassen, damit wird nicht mehr gegen die libodbc gelinkt. Um die beiden so Files (liegend im selben Verzeichnis) unterscheiden zu können habe ich eines umbenannt.
Hilmar
Ich habe das jetzt nicht tiefgründig verfolgt, aber der proftpd hat in der Ausgabe von `ldd` auch `libdl` dabei, verfügt also vermutlich über die Fähigkeit, Libraries über `dlopen()` zur Laufzeit zu laden. Vielleicht wird das dann gemacht. -- Heiko
Am Sonntag, den 29.03.2020, 21:47 +0200 schrieb Hilmar Preuße:
Moin,
in proftp in Debian haben wir folgenden Patch:
Index: proftpd-dfsg/contrib/mod_sql_odbc.c
--- proftpd-dfsg.orig/contrib/mod_sql_odbc.c 2018-01-14 23:24:03.000000000 +0100 +++ proftpd-dfsg/contrib/mod_sql_odbc.c 2018-01-15 20:49:02.000000000 +0100 @@ -19,6 +19,7 @@
- As a special exemption, TJ Saunders gives permission to link this
program
- with OpenSSL, and distribute the resulting executable, without including
- the source code for OpenSSL in the source distribution.
*/
- $Libraries: -lodbc $
#include "conf.h"
i.e. im Kommentar wird etwas eingefügt. Da ich nicht so recht weiß, wonach ich googeln soll: wozu ist der Kommentar gut?
Wenn ich die debian/changelog-Datei richtig interpretiere nutzt proftpd irgendein System um die Linker flags in den Kommentaren aus dem $Libraries$ keyword zu sammeln. Ggf. werden damit die Linker-flags für die Module definiert (#519029 deutet auf so etwas hin). Mit `grep -rn Libraries` hat man etliche Treffer im Quellcode. In ./configure(.in) kann man das gut sehen (Zeile 3635 in der .in). Sowas ist ganz und gar nicht in den autotools vorgesehen oder muss ein Relikt ein. Ich habe lange mit den autotools gearbeit und kenne das nicht.
Der Patch fügt nur den Linker-Flag für das Modul hinzu. Warum der zwingend notwendig ist, geht aus debian/changelog nicht hervor.
MfG Daniel
Am 30.03.2020 um 00:21 teilte Daniel Leidert mit:
Moin,
Wenn ich die debian/changelog-Datei richtig interpretiere nutzt proftpd irgendein System um die Linker flags in den Kommentaren aus dem $Libraries$ keyword zu sammeln. Ggf. werden damit die Linker-flags für die Module definiert (#519029 deutet auf so etwas hin).
Genau. Wenn man den Patch weg läßt und damit den Kommentar entfernt wird nicht gegen libodbc gelinkt.
Der Patch fügt nur den Linker-Flag für das Modul hinzu. Warum der zwingend notwendig ist, geht aus debian/changelog nicht hervor.
Ja, leider. Der einzige Effekt den ich sehe ist, daß das Module gegen libodbc gelinkt wird. Damit erkennt dh_shlibdeps die Abhängigkeiten von der Link und erstellt eine Abhängigkeit zwischen dem proftp Modul und "libodbc1 (>= 2.3.1)" im Debian Paket.
Unklar ist mir allerdings ob die libodbc1 wirklich (noch) gebraucht wird oder ob das ein Relikt aus alten Zeiten ist. Im Changelog finde ich nur:
* [PATCH] Added odbc.dpatch to manage automagically unixodbc library linking.
...aber das wäre dann schon ein neuer Thread zum Thema "Gibt es in mod_sql_odbc.c Referenzen auf Symbole, für die man libodbc1 braucht?". Den werde ich aber hier nicht aufmachen.
Vielen Dank an alle Beteiligten. Nochmal sorry für die langen Reaktionszeiten!!
Hilmar
lug-dd@mailman.schlittermann.de
-
Andreas Fett -
Daniel Leidert -
Heiko Schlittermann -
Hilmar Preuße