Kylix läuft auf neuren SuSe-Versionen auch nicht mehr.
Für was ne Anleitung? In Delphi CLX-Anwendung erzeugen und diese mit Kylix kompilieren.
[OT]Man könnte es auch mit Mono versuchen[/OT]

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 ?!

Zitat:

Was ? soweit ich weiss gibt es keinen pascal compiler der das unterstützt oder sind .net Anwendungen mit mono lauffähig ?!

Ja, Mono ist ja eine freie Implementierung von .Net. (Aber VCL.Net funktioniert natürlich nicht).

christian_u hat folgendes geschrieben:

Das compilieren nimmt auch Zeit in anspruch

Der Microsoft-JIT ist verdammt schnell und diese Latenzen hast du ein Mal bei der ersten Kompilierung.

Zitat:

der Code lässt sich sicher relativ leicht wieder decompilieren

Obfuscators schützen dagegen.

Zitat:

und Viren und co habens damit sicher auch um einiges leichter.

Nicht wirklich, wenn du Assemblies signierst und schützt.

Zitat:

Was ? soweit ich weiss gibt es keinen pascal compiler der das unterstützt oder sind .net Anwendungen mit mono lauffähig ?!

Gutes Pascal unter .NET (und somit Mono): Chrome.

Noch eine Frage : reichen 10 GB für Suse 7 ? Geht doch hoffentlich. Der Download der 10 ist offensichtlich gedrosselt auf immer weiter abnehmende mittlerweile 400 Baud.

tommie-lie hat folgendes geschrieben:

Der Microsoft-JIT ist verdammt schnell und diese Latenzen hast du ein Mal bei der ersten Kompilierung.

Stimmt auch nicht. Die Programme werden just in Time compiliert (sagt ja schon der Name). Und zwar jedesmal neu ! Programmstart => erneute Compilierung. Das ist zwar kein glasklarer Interpreter, aber abwegig ist der Vergleich damit auch wieder nicht. Das mit den Viren ist auch nicht abwegig. M$ war quasi gezwungen, dagegen vorzugehen und es blieb keine Alternative übrig, es anders zu machen.

hansa hat folgendes geschrieben:

Noch eine Frage : reichen 10 GB für Suse 7 ?

Für die Siebener mit Sicherheit, keine Ahnung was ein 10er haben will. Mein System benötigt (ohne persönliche Daten) ca 5GB, inklusive von mir verwendete Software, devel-Pakete und alles was dazu gehört, es ist aber auch ein Debinoides System und kein SuSE.

hansa hat folgendes geschrieben:

Der Download der 10 ist offensichtlich gedrosselt auf immer weiter abnehmende mittlerweile 400 Baud.

400 Baud ist nun wirklich nicht normal. Daß der Download vom server absichtlich gedrosselt wird (und dann auch noch auf eine so geringe Datenrate) wäre mir neu. Da wäre der Postversand ja tatsächlich schneller...

hansa hat folgendes geschrieben:

Programmstart => erneute Compilierung.

Pro Programmstart, ja, aber nicht bei jedem Aufruf einer Funktion, solange man zwischendurch das Programm nicht beendet. Das wäre für mich eher in Richtung Interpreter als das, was ein JIT in Wirklichkeit ist.

[quote="tommie-lie"]

hansa hat folgendes geschrieben:

...Pro Programmstart, ja, aber nicht bei jedem Aufruf einer Funktion, solange man zwischendurch das Programm nicht beendet. Das wäre für mich eher in Richtung Interpreter als das, was ein JIT in Wirklichkeit ist.

Da hat er Recht. Nur beim Programmstart ist der Effekt zu bemerken. Und den nehme ich gerne in Kauf, sofern das .NET-Konzept aufgeht in Richtung Viren etc.

tommie-lie hat folgendes geschrieben:

...Pro Programmstart, ja, aber nicht bei jedem Aufruf einer Funktion, solange man zwischendurch das Programm nicht beendet. Das wäre für mich eher in Richtung Interpreter als das, was ein JIT in Wirklichkeit ist.

Da hat er Recht. Nur beim Programmstart ist der Effekt zu bemerken. Und den nehme ich gerne in Kauf, sofern das .NET-Konzept aufgeht in Richtung Viren etc.

Hallo Hansa, könntest du deinen letzen Beitrag noch einmal wiederholen

Aller guten Dinge sind halt drei

hansa hat folgendes geschrieben:

Nur beim Programmstart ist der Effekt zu bemerken.

Und IMHO selbst da nicht besonders. Der Flaschenhals beim Starten von Programmen und beim Kompilieren von Software ist in den meisten Fällen immer noch die Festplatte. Allenfalls über den erhöhten Speicherbedarf durch das Framework könnte man noch streiten...

Doppelt genäht hält eben besser. Suse 10 Download ist fast fertig und Suse 7 wird auch parallel installiert. Aller guten Dinge sind dann drei und Suse 7 wird wieder deinstalliert.

shootout.alioth.debi...cal&lang2=csharp

Naja anscheinend nicht nur beim Programmstart sonst würden die Benchmarks nicht so mies ausfallen oder ?
Und Schnellere teile kann ich da nicht endecken *fg*

[quote="christian_u"]

Zitat:

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.

Möglicherweise beziehst du dich auf die überraschenden Ergebnisse, die ich mit meinem Programm erreichte:

www.delphi-forum.de/...mp;highlight=lazarus

genau das ist der Thread

also ich möchte hier mal einiges klar stellen(auch wenn der letze beitag schon etwas her ist):
1: Die Erzeugten FPC Programme sind deshabl so groß weil sehr viele debug Infos eingebunden werden,
her steht es genauer: wiki.lazarus.freepas....org/Size_Matters/de
2: Mittlerweile ist der FPC Delphi 7 kompertibel d.h. Lazarus ist kein Delphi Clone. Wenn die Std. Komponenten genutzt wurden dürfte das keine Probleme geben.
3: Ich habe ca 10 Jahre mit Borland Delphi(1,5,6,7,2005) gearbeitet. Wobei die Lezte Version(2005) für mich einfach nicht brauchbar war: viel zu gewaltig war sie. und Delphi 7 fand ich auch nicht sonderlich praktisch.
4: ich bin der Meinung das es inzwischen ganz gut geht. Es können größe Projekte unter Lazarus erstellt werden.
ich verweise mal einfach auf ein Deutsprachiges Lazarus Forum:
www.lazarusforum.de/

einiges Fehlt noch wie z.b. die RTF komponente. Dafür gibt es mitlerweile aber die VST, GLscene Komplet.
Und einen FMOD oder Bass ersatzt gibt es auch ACS. Achja was Grafik angeht mit einem zusatzt Download können sehr viele Grafikformate unterstützt werden in einem Lazarus Programm und das sogar ohne vorraussetzung einer GUI.