linux-l: dynamisch <-> statisch gelinkt

[thomsen at cs.tu-berlin.de]

In message <19970701221347.44702 at schintke.isdn.cs.tu-berlin.de>, Florian Schint
ke writes:
[..]
> Es gibt schon Gruende warum man auch wenn man keine kommerziellen libs
> verwendet   statisch    linken  will.   Vielleicht   nicht   im  nicht
> kommerziellen Umfeld, aber wenn  man kommerziell  Software entwickelt,
> dann muss man sicher sein, dass die Software beim Kunden auch genau so
> laeuft, wie    bei    einem  selbst.  Und   da   koennen   schon   die
> unterschiedlichen Versionen der Bibliotheken gefaehrlich sein. 
> 
Aber genauso, wie man die Kernelversion, bzw. die Distribution (FS)
spezifiziert, koennte man es auch mit den shared libs machen. Die
haben ja auch inzwischen eine zufriedenstellende Stabilitaet (fuer
Systeme auf Linux 2.0 aufbauend, nicht die experimentellen Versionen)
erreicht.

> Gleiches     gilt,    wenn     man    Binaer-Versionen  von    Paketen
> vertreibt.  Entweder die Software   testet selbst, ob  die benoetigten
> Bibliotheken vorhanden sind  und  gibt sonst eine  Fehlermeldung  aus,
> oder sie ist statisch gelinkt. Nur  so kann man Aerger bei Fehlersuche
> und anderem wirkungsvoll vermeiden. 
>  
Und ich aerger mich dann, wie ruecksichtslos der Hersteller mit meinem
Speicher umgeht. Siehe Netscape, Gimp (beide Motif). 
BTW: Kann man Gimp nicht auch mit LessTif linken?

Warum nicht dem Anwender nicht den Sourcecode in die Hand druecken, mit
einem vernuenftigen Makefile versteht sich - damit er die 'Warnings'
nicht sieht und denken koennten hier sei lausig programmiert worden?

Es gibt doch tools (vor langer Zeit habe ich darueber in Bericht in
der c't geklesen - leider wiess ich weder Produkt- noch Herstellername), 
die C-source 'scramblen', z.B. alle Bezeichener durch generierte 
alphanumerische Kurzbezeichner und alle whitespaces durch spaces (bis 
zur maximalen Zeilenlaenge) ersetzt. Dann ist reverseengineering 
sicherlich vergleichbar aufwendig, wie neu entwickeln.

Guenther