linux-l: dynamisch <-> statisch gelinkt

[Florian Schintke]

+------------+
| Antwort auf
|   wen:      thomsen at cs.tu-berlin.de <thomsen at cs.tu-berlin.de>
|   vom:      2. Jul 1997
|   Thema:    'Re: linux-l: dynamisch <-> statisch gelinkt'
+------------+
> 
> 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?
> 

Also  im    nichtkommerziellen  Umfeld,    wo man     auch   keinerlei
Funktionalitaet garantieren muss,  ist    das sicherlich nicht     das
Problem. Bei kommerzieller  Software hast  Du aber die   Verpflichtung
gegenueber dem  Kunden (M$ mal ausgenommen),   dass die Programme auch
das leisten, was  Du  versprochen hast.  Ansonsten  gibt es Teile  vom
bezahlten Geld fuer den Kunden  zurueck. Das Kann sich ein Unternehmen
nicht leisten. 

Es kann  sein, dass sich das  Programm auch  mit aelteren oder neueren
Versionen der Bibliotheken kompilieren laesst, Teile davon aber anders
funktionieren. Du hast  als  Softwareentwicklungsunternehmen nicht das
Geld Dein Produkt mit allen  moeglichen Versionen der Bibliotheken  zu
testen.  Damit  Du  also  sicher gehen kannst,   dass  das Produkt die
gleichen Eingenschaften    hat,  wie auf   Deinem Entwicklungsrechner,
linkst Du statisch.

Man  koennte auf die  Idee kommen, den Kunden  zu zwingen die richtige
Version der Bibliotheken  zu installieren, was  aber inakzeptabel ist,
da vielleicht  andere   Produkte andere   Versionen  der  Bibliotheken
vorschreiben, was zu unvereinbaren Anforderungen fuehren kann. 

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

Das  Problem ist eher   nicht der Klau  des  Source-Codes, sondern die
Moeglichkeit die Funktionalitaet zu garantieren. 

Gruss

Florian Schintke
-- 
E-Mail: schintke at cs.tu-berlin.de
WWW   : http://user.cs.tu-berlin.de/~schintke/