Zitat: |
Ich habe ihn wiedergefunden, ich hatte nur in der falschen Abteilung geschaut. Leider mittlerweile in modifizierter Form (jetzt geht es um Objekte und Strings, was lediglich ein ABI-Problem ist und durch den Compiler und nicht durch den Linker bestimmt wird. Ich würde aber meine Hand dafür ins Feuer legen, daß mal die Rede vom reinen Erzeugen von Shared Objects war.
|
Es geht hier um Packages, die der Fpc noch nicht unterstützt damit man komponenten wie bei Delphi in dei ide einbauen kann ohne diese dabei neu übersetzen zu müssen.
Das hat aber nicht viel mit dem Linker zu tun soweit ich weiss sondern einfach damit das die Schnittstelle zu den dynamischen bibliotheken dafür noch nicht da ist.
Ganz genau kann ich dir das aber auch nicht sagen da mich das Feature nicht so wahnsinnig interessiert ich habe lediglich 4 Packages dazuzuinstallieren sonst komm ich mit eigenen Units oder mit den Standartkomponenten aus was meineserachtens eh besser für die Portierbarkeit des Codes ist.
Zitat: |
Das würde aber nicht erklären, warum die Binaries unter Linux so unglaublich groß waren (sind?).
|
Also, erstens werden generell Debugsymbole in den executables belassen welche ca 70% der grösse ausmachen. Danach hast du für eine einzelne Form eine Anwendung die ca 1mb gross ist. Das ist so weil die LCL mit den Standart Makefiles nicht smartgelinkt wird.
Damit ist es hinfällig ob du in deiner Applikation das Smartlinking aktivierst oder nicht.
Denn die LCL muss ja komplett mit rein. Compiliert man die LCL mit Smartlinking wird das ganze noch n stück kleiner.
Das 2. Problem ist das grosse Teile der LCL sowiso mit eincompiliert werden da die Forms ja wie in Delphi geparst werden und so immer der Code für alle Controls mit in die Anwendung muss.
Ich habe mal vorgeschlagen die Forms alternativ von der IDE in Code umwandeln zu lassen was sehr (sehr sehr) kleine Executables zur folge hätte. Allerdings wurde das wegen der häufigen Nutzunbg von RTTI Ausgeschlagen.
Der 3. Ist die LCL selbst. Sie muss auf bislang 7 Widgetsets und diversen CPU Architekturen auf denen es die Widgetsets gibt laufen und ist somit schon an sich etwas aufgebläht.
Also ich für meinen teil lach da immer drüber ein katuelles Spiel kommt auf 2-5 DVD´s daher und wir streiten uns um ein paar kilobyte ...
Das grösste Executable ausm Lazarus ist bei mit heute ca 3mb gross und das ist eine Warenwirtschaft die ich gerade Portiere die nicht gerade unfunktionell ist.
In Delphi hatte ich dort ein 3,5 mb Executable es ist aber auch noch nicht ganz alles portiert. Ich denke damit kann man leben.
Zitat: |
Nein, .NET-Code wird kompiliert, und zwar just in time. Interpretiert wurde QBASIC. In einigen Situationen kann .NET deutlich schneller sein als nativer Code. Frag mal Robert_G, der kann dir dazu mehr erzählen, ich bin leider etwas aus der Übung, was .NET angeht.
|
Richtig, hatte ich ganz vergessen. Naja mir ist nativer code doch lieber, Das compilieren nimmt auch Zeit in anspruch der Code lässt sich sicher relativ leicht wieder decompilieren und Viren und co habens damit sicher auch um einiges leichter.
Zitat: |
gnadenlos? Ist wohl übertrieben und kommt sehr selten vor.
shootout.alioth.debi...pp&lang2=fpascal
|
naja 15 mal weniger Speicher in etlichen tests find ich schon recht üppig.
Ich hab gestern einen Thread hier gelesen in dem sich jemand gewundert hat das sein von Delphi nach Lazarus portiertes Porgramm plötzlich doppelt so schnell rechnet.
Dort war auch ein Link mit Benchmarks die sich jedoch hauptsächlich auf FPU geschichten und optimierungen bezog.
Dort war fpc vor 6 Jahren schon führend. Delphi 4 war glaub ich auf Platz 4.
Zitat: |
Ich will vielmehr folgendes wissen : läßt sich eine ähnliche Konstellation mit Suse 8 oder besser 7 realisieren ?
|
was ? Delphi+Wine zu installieren oder Lazarus.
Lazarus läuft auf jeder Linux Platform (und *bsd,macos und windows) du benötigst nur libpixbuf devel und die gtk devel bibliotheken.
Zitat: |
Man könnte es auch mit Mono versuchen
|
Was ? soweit ich weiss gibt es keinen pascal compiler der das unterstützt oder sind .net Anwendungen mit mono lauffähig ?!