![]() |
AW: Linux - Ick freu mir ;-)
Zitat:
Indy TCP/HTTP Server verwenden Threads. Und vermutlich werden auch viele andere Delphi Servertools wie DataSnap, IntraWeb usw. das tun. Bedeutet: für jede libc-Version neu kompilieren. Viel Spass :) |
AW: Linux - Ick freu mir ;-)
Zitat:
|
AW: Linux - Ick freu mir ;-)
VGScene verwendete OpenGL. Ich vermute mal unter Linux in Verbindung mit SDL.
|
AW: Linux - Ick freu mir ;-)
Zitat:
Kann natürlich sein, dass ich jetzt zufällig überall auf dieselbe Version der libc gestoßen bin, aber dennoch hatte ich so damit trotz langer Nutzung nie Probleme. |
AW: Linux - Ick freu mir ;-)
Zitat:
![]() Zitat:
Wir Softwareentwickler wissen aber, dass ständige Rückwärtskompatibilität selten etwas gutes für unsere Software bedeutet. Zitat:
Man muss ich wohl in erster Linie daran gewöhnen, dass man unter Linux nicht irgendwelche Webseiten besucht und dort irgendetwas herunterlädt. Dein Maintainer stellt alles für dich zusammen. Du benutzt zum Installieren von Software deinen Paketmanager. Ausnahmen sind selten. OpenSource-Programme kann man von extern kompillieren und das läuft meist anstandslos. Binaries wie Google Chrome oder Spotify sind da schwieriger. Google hat bei Chrome gute Arbeit geleistet. Spotify hingegen ist schon deutlich wählerischer bei seiner Plattform. |
AW: Linux - Ick freu mir ;-)
Ich freu mich auch, allerdings erst, wenn man auch Linux-Desktop-Anwendungen erstellen kann.
Konsolenprogramme? Was soll das? Selbst ein Konsolen-Serverprogramm muss man administrieren, venünftigerweise macht man das mit einer richtigen Benutzeroberfläche. Zugegeben, der Markt für kommerzielle Linux-Desktop-Anwendungen ist klein, aber ich finde es gut, dass man den Kunden Lösungen für alle Plattformen anbieten kann. Seit Windows 10 stelle ich vermehrt Wechsler zu Linux fest, die dann bei mir die entsprechende Linux-Variante des bisherigen Windows 10 Programms bestellen. Bislang ist das leider relativ aufwändig, einen zusätzlichen Programmcode extra für Linux mit Lazarus zu pflegen (wobei man gegen Lazarus aus meiner Sicht nichts sagen kann, sehr gute Entwicklungsumgegebung, funktioniert auf allen Plattformen hervorragend). Na ja, insofern aber schon mal ein Lichtblick... |
AW: Linux - Ick freu mir ;-)
Zitat:
Zitat:
|
AW: Linux - Ick freu mir ;-)
Zitat:
Davon abgesehen sind da noch die mobilen Versionen für IOS und Android, die man doch am einfachsten mit Delphi entwickeln kann... Es gäbe natürlich noch die Variante, tatsächlich voll auf Lazarus umzusteigen und die mobilen Versionen mit Swift (IOS) bzw. Android Studio zu entwickeln... Aber das käme nur ernsthaft in Betracht, wenn die Preispolitik um Delphi völlig abdreht oder Linux wirklich mal so aufholen sollte, dass man da deutlich mehr machen muss und in Delphi dafür weiterhin kein vernünftiges Angebot besteht... |
AW: Linux - Ick freu mir ;-)
Zitat:
Jede Weblösung die sich nicht über das Web (hier http) Administrieren lässt ist keine vollständige Weblösung |
AW: Linux - Ick freu mir ;-)
Zitat:
Hast du Erfahrungen mit Android Studio? Seit CodeTyphon bin ich für Linux und Windows auf FreePascal umgestiegen und habe lange Zeit dann Delphi fast nur für Android genutzt. Mittlerweile, weil mein XE5 zunehmend unpraktischer wurde (fehlende Features, keine Unterstützung neuerer Androidversion etc.) bin ich dann, als Weg des geringsten Übels (und weil es kostenlos wurde), auf C# mit VS/Xamarin umgestiegen. |
AW: Linux - Ick freu mir ;-)
Zitat:
Zitat:
Aber zu Delphi möchte ich noch erwähnen, dass mir die Aktivitäten von Emba/Idera in den letzten 1-2 Jahren gut gefallen haben. Was die alles an Webinaren, Informationen etc. zur Verfügung stellen ist schon Klasse, hier bekommt man viele Hilfestellungen. Mit den Aktionen um Delphi-Starter herum versucht man wieder (Neu-) Kunden zu gewinnen und die Rechnung könnte aufgehen. Und je mehr Delphi Entwickler, desto besser. Ich bin da bei Delphi also noch grundsätzlich in positiver Grundhaltung, auch wenn es bei FMX immer noch ein paar ärgerliche Entwicklungen gibt, wo z.B. Fehlerkorrekturen noch zu lange auf sich warten lassen, oder in der nächsten Version der Source-Code der Vorversion nicht mehr funktioniert, etc. Die IDE ist in 10.1 ist deutlich besser als unter XE5, sie ist schneller, macht sogar kleinere Kompilate, der Installationsprozess ist nun super über das Internet zu bewerkstelligen und anpassbar. Wenn Dein Budget es her gibt, dann gönne Dir das Update auf 10.1... Wenn ich jetzt noch Linux-Desktop-Versionen entwickeln könnte, das wäre echt super... Ich kann zwar verstehen, dass die Erfahrungen mit Kylix für das Unternehmen eher abschreckend waren, aber bin der Meinung, man sollte nicht direkt nach dem ersten Versuch aufgeben. Linux hat potential (dafür sorgt auch Windows 10)... |
AW: Linux - Ick freu mir ;-)
Als ich das las war mein erster Gedanke: ach guck,
![]() Leider kein Wort davon, daß man hier auch mit GDB debuggen kann. Stichwort gdbserver. Zitat:
Das kann man, wie geschrieben, steuern. Aber es bringt auch kleine Nachteile mit sich. Dennoch: prinzipiell ist es möglich auch mit einer aktuellen Toolchain Programme zu verfassen die auf uralten Systemen, bspw. 2.6.2er Kernel aufwärts (glibc hängt naturgemäß stark vom Kernel ab), laufen. Den großen Nachteil einer statisch gelinkten Datei hat Valle natürlich tunlichst verschwiegen: die LGPL. Ja, die LGPL ist hier insofern relevant, weil sie verlangt, daß wahlweise der Quelltext zu eurem Programm mitgeliefert werden muß oder alternativ ihr die Objektdateien mitliefern dürft, damit der Benutzer sie mit einer neuen Version der Bibliothek (bspw. glibc) linken darf. Man kann mutmaßen, daß die ![]() ![]() Zitat:
Zitat:
Ach ja und wenn Delphi hier wie der Linker von Binutils im ELF-Header gewisse Hinweise hinterläßt über die Kompatibilität mit dem Kernel, wirkt das auch einschränkend. Ich empfehle einmal
Code:
auszuführen und die Ausgabe hier zu zeigen. Das hat Herr Cantu leider versäumt.
file <Dateiname>
Zitat:
Zitat:
Zitat:
Zitat:
![]() ![]() Zitat:
Kernel und libc sind aufeinander bis zu einem gewissen Punkt abgestimmt. Viele der Funktionen aus der C-Laufzeit sind nämlich direkt in Systemaufrufe übertragbar. Lesetip: "Designing BSD Rootkits" (Kong), "The Linux Programming Interface" (Kerrisk) und "Advanced Programming in the UNIX Environment" (Stevens, Rago), "The Design and Implementation of the FreeBSD Operating System" (McKusick, Neville-Neil). Dazu kommen noch die Versionsnummern auf welche ich weiter oben verwies und nicht zuletzt ![]() Zitat:
![]() Zitat:
Zitat:
Zitat:
Zitat:
![]() Falls du immer verwirrt bist worum es sich bei einer Datei handelt, empfehle ich das oben bereits erwähnte Tool "file", welches dir auf unixartigen Systemen üblicherweise zur Verfügung steht. Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
|
AW: Linux - Ick freu mir ;-)
Zitat:
Zitat:
|
AW: Linux - Ick freu mir ;-)
Zitat:
|
AW: Linux - Ick freu mir ;-)
Zitat:
Zitat:
![]() Zitat:
![]() |
AW: Linux - Ick freu mir ;-)
Zitat:
Zitat:
Dem Wikipediaartikel entnehme ich auch keine endgültige Entscheidung in die eine oder andere Richtung. Aber wir können uns ja einigen, daß wir da einfach verschiedener Ansicht sind was wann sinnvoll ist ;) ... hab ich kein Problem mit. Zitat:
[1] und dann kann man mit musl-libc oft selbst statisch gelinkte Dateien kleiner bekommen als dynamisch gegen die glibc gelinkten. |
AW: Linux - Ick freu mir ;-)
Hallo Asserbad,
dankesehr für deine Erleuchtungen und Lesetips :-) Es ist doch gut zu wissen das sich hier schon einige Linux-Experten tummeln. Zitat:
Jedenfalls denke ich das die Headerkonvertierung von den Libs zu Delphi nicht immer 1:1 und einfach sein wird, oder hat FPC schon vorgemacht das man alles butterweich eingebunden bekommt ? Deshalb ist mein Gedanke (eigentlich genau wie unter Windows), das man besser mit C++Builder direkt auf die GCC Projekte losgeht. Und bestenfalls die vielen bestehenden Linux-Projekte 1:1 mit GCC oder C++Builder kompilieren könnte. Das wünschte ich mir übrigens auch unter Windows, um VC Projekte direkt im C++-Builder kompilieren zu können, aber immer wenn ich das mal versucht hatte artete das in komplette rewrites aus. So könnte man die ganzen bestehenden Projekte in Linux/Windows direkt ohne Umweg nutzen. Da könnte ich einen Vorteil von C++Builder zu Delphi sehen. Wie oft habe ich schon versucht eine VC++ DLL einzubinden, und konnte keine Lösung für bestimmte Konstrukte finden. Ich sehe aber das es Zeit wird sich mal tiefer mit Linux zu beschäftigen (das wollte ich schon seit Jahren). Rollo |
AW: Linux - Ick freu mir ;-)
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
@Valle: ich wollte nur noch anfügen, daß ich mittlerweile daran arbeite meine Test- und Buildumgebung als "ephemeral container" laufen zu lassen, also einen Container der aus einer Vorlage zum Erledigen einer Aufgabe und darauffolgendem Wegwerfen erstellt wird. x86_32 Linux lassen sich hervorragend auch auf einem x86_64-Host als Container betreiben (LXC oder sogar chroot über schroot). |
AW: Linux - Ick freu mir ;-)
Zitat:
(Wobei strenggenommen läuft da kein Linux in deinem Container, da die Container den Hostkernel verwenden. Da läuft nur GNU. Soviel dazu.) |
AW: Linux - Ick freu mir ;-)
Zitat:
Zitat:
|
AW: Linux - Ick freu mir ;-)
Zitat:
Zitat:
|
AW: Linux - Ick freu mir ;-)
Zitat:
Generell verstehe ich bei diesen POSIX-Funktionen nicht ganz WAS sih eigentlich ändert. Ich sehe das ein bischen so wie die API zur DOS-CommandZeile, oder zu WMI, da gibt es verschiedene Katgorien: "Mature"-Funktionen ? - Memory Zugriff - Filezugriff - Sockets - IPC - Pipes - Regex - Math - etc. Funktionen vielleicht in "Änderung" - SystemManagement - ??? Von der Seite der System-Stabilität her würde ich erwarten das 98% der glibc API doch komplett "durchentwickelt" sein müsste, zumindest hinsichtlich der APIs. Und mögliche Änderungen beziehen sich hoffentlich nur auf Neue oder "Sonder"-Funktionen. Oder wird auch ständig an den Grundpfeilern herumgebastelt ? Solange die APIs gleich bleiben, und nur an der Performance verbessert wird, sollte die Anpassung auf neue Versionen doch relativ simpel bleiben. Ich kann mir einfach nicht vorstellen das man bei jeder Version alles wieder auf den Kopf stellt. Rollo |
AW: Linux - Ick freu mir ;-)
Zitat:
Zitat:
Zitat:
Zitat:
Ein altes Programm welches, sagen wir mal, vor 10 Jahren gegen glibc gelinkt wurde auf einer damals aktuellen Distro, läuft ja üblicherweise problemlos auf einer neueren Distro. Umgekehrt aber nicht. Also ein auf einer neueren Distro gelinktes Programm mit älterer glibc. Hier zwei Beispiele von Funktionen bei denen man die Kompatibilität mit älteren glibc-Versionen erzwingen muß: memcpy und realpath. Das erreicht man folgendermaßen. Man erzeuge ein Macro entsprechend der glibc-Version zu der man Kompatibilität herstellen möchte:
Code:
Hinweis: 2.2.5 war die erste Version mit Unterstützung für amd64 bzw. x86_64. Der Parameter fct ist dabei der Name der Funktion, welcher mithilfe des Stringification-Operators (#) zu einem Literalstring wird.
#ifdef __amd64__
# define GLIBC_COMPAT_SYMBOL(fct) __asm__(".symver " #fct "," #fct "@GLIBC_2.2.5"); #else # define GLIBC_COMPAT_SYMBOL(fct) __asm__(".symver " #fct "," #fct "@GLIBC_2.0"); #endif /* __amd64__ */ ![]() Angewendet wird das Makro dann wie folgt:
Code:
Mit dem Effekt, daß nunmehr nicht die neueste Version von memcpy und realpath, sondern die älteste Version benutzt wird. Die Methode kann man übrigens der Datei include/libc-symbols.h entnehmen welche sich in (e)glibc befindet.
GLIBC_COMPAT_SYMBOL(realpath)
GLIBC_COMPAT_SYMBOL(memcpy) Für jene die nachvollziehen wollen welche Symbole in welcher Version vorliegen, hier eine Möglichkeit:
Code:
$ readelf -a /lib/x86_64-linux-gnu/libc.so.6|grep ' memcpy@'
1123: 0000000000091620 61 IFUNC GLOBAL DEFAULT 12 memcpy@@GLIBC_2.14 1125: 000000000008c420 71 IFUNC GLOBAL DEFAULT 12 memcpy@GLIBC_2.2.5 |
AW: Linux - Ick freu mir ;-)
Zitat:
![]() |
AW: Linux - Ick freu mir ;-)
Ja dankesehr für das Beispiel, das macht es schon etwas klarer.
Also kommt man ggf. doch in die IFDEF-Hölle, wenn man nicht aufpasst. Ich versuche meistens immer eher einen Grundsatz von Funktionen zu verwenden, und Spezialitäten erstmal wegzulassen. Also z.B. strcpy, memcpy, etc. solche Funktionen die es schon seit den 60ern unverändert geben sollte. Sollte doch möglich so einen Satz Grundfunktionen zu finden wo die API nicht komplett verrückt spielt, und ich gehe für mich jetzt mal vom aktuellsten Linux aus. Muss ja bei Neuprojekten nicht 20 Jahre rückwärtskompatibel sein. Ich warte mal ab wie das im neuen Delphi umgesetzt wird, da bin ich schonmal gespannt. Rollo |
AW: Linux - Ick freu mir ;-)
Zitat:
|
AW: Linux - Ick freu mir ;-)
Zitat:
|
AW: Linux - Ick freu mir ;-)
Zitat:
Vergessen darf man auch nicht, daß du den gleichen Compiler benutzt, möglicherweise sogar denselben, falls du cross-kompilierst. Wenn du jeweils GCC auf Windows, Linux, AIX und Solaris benutzt können dir viele Probleme anderer Leute mit ifdefs auch wumpe sein. Sobald aber schon ein Strauß verschiedener GCC-Versionen benutzt wird, kommste u.U. in unruhige Gewässer. Wenn dann dein Code auch noch gewisse Anforderungen an den Compiler hat (Speicherausrichtung auf 64-bit SPARC [1], bspw.) und der GCC in seiner vorhandenen Version genau dort schwächelt, kommste um eine Alternative für GCC schon nicht mehr herum (SunC/Sun Studio). Wenn du aber bspw. auf Windows auch sinnvoll post-mortem Debugging mit Minidumps machen willst, brauchste DbgHelp-kompatible Symbole, welche der GCC (bzw. der benutzte Linker) nicht erstellt. Also stellste in Windows auf MSVC um. Und so weiter und so fort. Dann sind wir bei vier Systemen schon bei drei Compilern (jeweils gleiche Sprache C/C++), wobei die Versionsunterschiede noch nicht mitgerechnet sind. Da lassen sich #if und #ifdef selten vermeiden. Bei der Software für die ich beruflich verantwortlich zeichne, habe ich es, je nach Paket, mit bis zu 14 Plattform/Prozessorarchitektur-Paaren zu tun. Und da sind dann die OS-Versionen noch nicht mitgerechnet, sei es wegen glibc oder wegen einer inkompatiblen ABI-Änderung. Aber ich hoffe daß hier die Konkurrenz (FPC vs. Delphi) die treibende Kraft ist und sich die Entwickler von Delphi ein Beispiel an der tollen Umsetzung bei FPC nehmen. Bei Clang vs. GCC hat es ja geklappt. Die hilfreichen Fehlermeldungen gibt es nun schon eine Weile auch mit dem GCC und die Sanitizer wurden auf GCC portiert. Zitat:
Zitat:
Und viele der API-Funktionen die spezifisch nur für ein System entwickelt wurden (vfork, wait3, wait4), haben es auch schon in andere Systeme geschafft (bei Linux/FreeBSD mehrfach), bei anderen gibt es gute Alternativen. Aber in vielen Fällen wird das erst dann relevant wenn du deinen Code auf Geschwindigkeit trimmst oder ähnliches. Solange du ein 08/15-Programm schreibst (also keinen Datenbank- oder Webserver) und mit der Geschwindigkeit zufrieden bist, tun es auch jene Funktionen für Speicherverwaltung, Stringverarbeitung und E/A, welche auf allen unixartigen Systemen quelltextkompatibel implementiert sind. Zitat:
[1] Speicherausrichtung wird relevant wenn du bspw. auf Integer zugreifst die nicht korrekt ausgerichtet sind. Zwar geht auch das bspw. in SunC und GCC, aber es führt zu einer Geschwindigkeitsreduktion, weil die Ausrichtung auf Prozessorebene erwartet wird. Sind Daten falsch ausgerichtet, kommt es zu einem Fehler ähnlich wie bei einer Division durch Null. Dieser Fehler kann abgefangen und behandelt werden, aber diese Behandlung führt eben zu Performanceverlusten. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:16 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz