Linux - Ick freu mir ;-)

[Harry Stahl]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1346742)

Wenngleich ich einen etwas holprigen Start mit Lazarus hatte, so sehe ich zwischen Delphi und FreePascal, mittlerweile, nur noch wenig Unterschiede.

Dem würde ich überwiegend zustimmen. In Delphi gibt es allerdings noch einiges obendrauf (u.a. Threading-Library) und viele andere Nettigkeiten. Für MEINEN Anforderungsbereich jedenfalls kann ich aber sagen, dass ich für Windows oder MAC alles auch mit Lazarus erledigen kann (und eben auch noch die Linux-Plattform bedienen kann).

Zitat:

Zitat von Benedikt Magnus (Beitrag 1346742)

Hast du Erfahrungen mit Android Studio?

Nein. Ich hatte mir nur XCode/Swift installiert und einmal näher angesehen, ein Buch mal hierzu kurz überflogen, im Web einen Lehrgang dazu angesehen. Hier habe ich den Eindruck, dass man als Pascal-Entwickler sich schnell zurechtfinden könnte. Das haben auch schon andere im Forum hier bestätigt, die tatsächlich für ihre IOS oder MAC-Projekte auf Swift umgestiegen sind.

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

[Assarbad]

Als ich das las war mein erster Gedanke: ach guck, Kylix ist zurück. Alter Wein in neuen Schläuchen, sozusagen.

Leider kein Wort davon, daß man hier auch mit GDB debuggen kann. Stichwort gdbserver.

Zitat:

Zitat von Rollo62 (Beitrag 1346201)

Wer kennt sich denn mit Linux'en aus ?

Ich sehe 64-Bit Ubuntu im Beispiel als Platform ...

Ist das bei einem Kompilat ohne SO eigentlich egal, das sollte doch auf ALLEN Linux-Derivaten gleich Laufen.
Also wenn nichts spezielles eingebunden wird.

Also wenn die glibc eingebunden wird, kommt es ganz auf den Linker bzw. die Steuerung des Linkers an. Die glibc ist nämlich nur vorwärtskompatibel. Will heißen, daß du ein Programm welches gegen eine neue Version von glibc linkst nicht unbedingt auf einer anderen Distro mit älterer glibc oder derselben Distro aber in älterer Version laufenlassen kannst.

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 "GCC Runtime Library Exception" (FAQ) hier greift, aber eigentlich bezieht sich die ausschließlich auf die libgcc. Aber ihr könnt ja immernoch einen Anwalt anheuern um das ggf. klären zu lassen.

Zitat:

Zitat von Valle (Beitrag 1346206)

Unter Linux ist statisches Linken eher unüblich, zumal gelinkte Bibliotheken dann die Betriebssystemupdates nicht bekommen würden, aber das ist unter Windows ja sowieso immer der Fall.

Auch nur in den Fällen in denen es auf Linux der Fall ist, wenn wir über statisch gelinkte Bibliotheken reden. Ansonsten kommt es auf die Bibliothek an. Die C Runtime von Visual C++ 6.x wurde irgendwann in den Stand einer Systembibliothek erhoben. Ansonsten obliegt es dir die C Runtime Redistributables mitzuliefern.

Zitat:

Zitat von Valle (Beitrag 1346206)

Statisch gelinkte Kompilate sollten mit jeder Distribution auf x86/x64 laufen. Die Kernelversion hat vermutlich wenig Einfluss darauf.

Das kommt allein darauf an welche Systemaufrufe (system calls) in der statisch gelinkten Bibliothek Verwendung finden. So pauschal kann man das nicht sagen.

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:

file <Dateiname>

auszuführen und die Ausgabe hier zu zeigen. Das hat Herr Cantu leider versäumt.

Zitat:

Zitat von mjustin (Beitrag 1346215)

Mit Free Pascal und Ubuntu 12.04 / 14.04 Single-Exe Anwendungen hatte ich das Problem, dass wegen einer neueren eingebundenen libc die in Ubuntu 14.04 erzeugte Anwendung nicht auf 12.04 ausgeführt werden kann (anders herum habe ich es nicht getestet).

Ich benutze kein FPC, aber mit GCC läßt sich das relativ einfach umgehen. Es handelt sich genaugenommen nämlich nur um eine Handvoll von Funktionen gegen die auf dem neueren System gelinkt wird, welche in der älteren Bibliotheksversion nicht existent sind. Das ist alles steuerbar.

Zitat:

Zitat von Valle (Beitrag 1346245)

Wenn FMX auf Linux portiert würde, dann wahrscheinlich, wie gesagt, direkt auf das X11-Protokoll.

Meiner Meinung nach Wunschdenken. Die werden wohl den Weg des geringsten Aufwands gehen. Und das wäre eine existierende Lösung ala Qt. Was dann wiederum eigene Vorteile (aber auch ein paar Nachteile) mit sich brächte.

Zitat:

Zitat von Rollo62 (Beitrag 1346248)

Das größte Problem wird sein das die Libc-Files nicht konvertiert sind zu Delphi, und wahrscheinlich
auch nicht immer 1:1 oder überhaupt konvertierbar sind.

Wieso? Im Gegenteil, wenn diese Linuxversion direkt auf den Systemaufrufen aufsetzen würde, wäre dies lizenztechnisch für kommerzielle Anbieter ein nicht zu verachtender Vorteil (s.o.). FPC macht dies ja scheinbar so - siehe Beiträge von Mitdiskutanten weiter oben.

Zitat:

Zitat von Rollo62 (Beitrag 1346248)

Aber was ich generell nicht verstehe ist wie die verschiedenen Libc-Versionen in Linux organisiert sind.
Auch unter Linux muss alles aus dem gleichen Versionsraum kommen, sonst kracht es da auch.

Ich verweise auf diese Frage&Antwort. Es gibt da auch ein paar Artikel zum Thema von Herrn Drepper und einigen anderen.

Zitat:

Zitat von Rollo62 (Beitrag 1346248)

Gibt es immer mehrere Versionen des Kernels und der Libraries auf jedem System ?
Ich denke das ist eines der Probleme bei Linux, das jede Distribution da alt und neu mischen kann und
auch an anderen Stellen/Bezeichnern ablegen kann.

Leider ist das Problem nicht Linux, sondern dein mangelndes Verständnis :)

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 Versionsskripte, welche einzelnen Funktionen innerhalb einer Bibliothek ebenfalls Versionen mitgeben.

Zitat:

Zitat von Rollo62 (Beitrag 1346248)

Vielleicht gibt es aber auch standarisierte Methoden um Libc-Version und Kernelversion bei allen Distributionen rauszufinden, so ähnlich (aber hoffentlich besser strukturiert) wie bei COM ?

Ja, die Methode heißt Dynamic Linker (ld.so) und ist dokumentiert. Funktioniert allerdings etwas anders als in Windows.

Zitat:

Zitat von Rollo62 (Beitrag 1346248)

Ein GCC Compiler hat aber genau die gleichen Probleme, das liegt nicht an Delphi an sich.

Der GCC hat keine Probleme, der Linker gehört noch nicht einmal zu GCC, sondern zu Binutils. Zugegeben, als ich nur Delphi kannte, unterlag ich auch der Illusion daß es eines Schritts von Quelltext zur Binärform bedarf. Lesetip: das "Drachenbuch" über Compiler-Design (auf dt. "Compiler: Prinzipien, Techniken und Werkzeuge").

Zitat:

Zitat von Rollo62 (Beitrag 1346248)

Wenn man die richtigen Libs und deren Position kennt kann man das zusammenbauen.
Also wäre ein C++Builder vielleicht geeigneter als Delphi um GCC Projekte zu kompilieren und einzubinden ?

Es ist herzlich irrelevant welcher Compiler genutzt wird. Das vermeintliche Problem entsteht durch die Standardeinstellung des Linkers (und der kann gesteuert werden, so daß es überhaupt kein Problem gibt, wenn man sich damit beschäftigt).

Zitat:

Zitat von Namenloser (Beitrag 1346251)

Aber der klassische Unix-Weg wäre ja auch eher mit fork und wait statt Threads :roteyes:

Sehe ich auch so, aber bei uns in der Firma werden seltsamerweise oft trotzdem Threads bevorzugt. Finde es seltsam, denn bei einem Fehler ist es ja der Kernel welcher den Prozeß abschießt. Einen Mechanismus wie SEH gibt es da nicht. Kurzum: ich bevorzuge mindestens ein fork() denn nur dann kann ich den Kindprozeß überwachen und ggf. Maßnahmen ergreifen falls etwas passiert. Ist übrigens zusammen mit AFL oder den Sanitizern von Clang (und mittlerweile ja auch GCC) unschlagbar für automatisiertes Testen.

Zitat:

Zitat von mael (Beitrag 1346266)

Zitat:

Zitat von Valle (Beitrag 1346245)

Aber ich sprach von statisch gelinkten ELFs. (keine Exen, die gibt's unter Linux nicht ;-) ).

Wo wir schon genau sind :p
Unter Linux kann eine executable (=eine Datei die das executable-Recht gesetzt hat) jede Dateiendung haben die sie will, auch ".exe", nur hat sie üblicherweise keine Endung (oder es ist ein Skript wie .pl .sh oder eine ELF-Bibliothek .so). Das Gegenstück zu ELF in Windows sind PE-Dateien (die auch unterschiedliche Dateierweiterungen erlauben für "normale" ausführbare Dateien aber auch DLLs/Bibliotheken/Treiber).

Ich finde exe ist da klarer als das häufige binary (was alles sein kann).

Es kann gerade nicht alles sein. Auf Linux ist für Skripte nicht das x ausschlaggebend, sondern die Hashbang (#!). Für binäre Programme hingegen gibt es eine Möglichkeit beliebige Formate interpretieren zu lassen.

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 von Rollo62 (Beitrag 1346268)

Zitat:

Zitat von Valle (Beitrag 1346261)

Normalerweise kompilierst du dein Programm exakt für deine Zielplattform.

Mal dumm gesprochen: Das mache ich für Windows ja auch (XP/7/8/10).
Nur das dort wohl mehr Wert auf Rückwärtskompatibilität gelegt wird (was ich mir
bei Vergleich M$ - Linux aber auch nicht wirklich vorstellen kann).

Ist das so? Mal dumm geantwortet: auf Linux überwiegen Programme mit offenen Quellen, macht da Rückwärtskompatibilität mit Präprozessor-Direktiven (ifdef etc) soviel Sinn wie auf Windows? Abgesehen davon scheint dir der Begriff DLL-Hölle unbekannt zu sein. Möglicherweise der Segen eines jungen Lebens? ;)

Zitat:

Zitat von Rollo62 (Beitrag 1346268)

Ich habe bisher nur ein bischen mit Bash und Konsolen-GCC rumgespielt, das Hauptproblem was ich damit hatte ist "wo ist was ?".

Dann empfehle ich bspw. "apropos", "man" und "info". Wobei man die entsprechenden Handbücher vorher installieren sollte. Wer das nicht möchte, wendet sich vertrauensvoll an linux.die.net oder man7.org.

Zitat:

Zitat von Benedikt Magnus (Beitrag 1346288)

Kann natürlich sein, dass ich jetzt zufällig überall auf dieselbe Version der libc gestoßen bin, [...]

Bist du bei den genannten Versionen von Ubuntu definitiv nicht. Und selbst wenn die Versionsnummer stimmt, heißt das auf Linux oft wenig. Viele der Kernel die als 2.4er firmierten (ich sage nur Redhat) waren schon soweit gepatcht, daß sie halbe 2.6er waren. Offenliegende Quellen eben ...

Zitat:

Zitat von Valle (Beitrag 1346334)

Doch, ist aber so. Microsoft hat seine Plattform ja voll in eigener Hand. Linux besteht aus sehr vielen unabhängigen Projekten.

Linux besteht aus einem Kernel - Punkt. Was du vermutlich meinst ist der GNU-Aufsatz auf dem Linuxkernel ;)

Zitat:

Zitat von Valle (Beitrag 1346334)

Wir Softwareentwickler wissen aber, dass ständige Rückwärtskompatibilität selten etwas gutes für unsere Software bedeutet.

Den müßtest du - zumindest mir - nochmal erklären.

Zitat:

Zitat von Harry Stahl (Beitrag 1346739)

Nun ja, an Delphi hängt schon mein Herz...

Das zu hören freut die Verkaufsabteilung ;)

Zitat:

Zitat von Harry Stahl (Beitrag 1346739)

Aber das käme nur ernsthaft in Betracht, wenn die Preispolitik um Delphi völlig abdreht [...]

Ich finde sie schon seit Jahren völlig abgedreht. Weiter oben erwähnte einer der Mitdiskutanten, daß es Wahnsinn sei, daß er gebündelt Pakete mit kaufen müsse, welche er nicht benötigt. Dem kann ich nur aus ganzem Herzen zustimmen. Genau deshalb habe ich mich von Delphi abgewandt.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1346741)

Bis auf die "Grundeinrichtung" um das System überhaupt zum laufen zu bekommen wäre eine Linux-GUI sowas von 1995.
Jede Weblösung die sich nicht über das Web (hier http) Administrieren lässt ist keine vollständige Weblösung

Jeder "Administrator" der eine GUI benötigt um sich durchzufrickeln ist kein Administrator. Und da haben wir über die vielen Sicherheitslücken noch nicht gesprochen, welche allein aufgrund der webseitigen Administrationsoberflächen entstanden sind und entstehen.

[mkinzler]

Zitat:

Leider kein Wort davon, daß man hier auch mit GDB debuggen kann. Stichwort gdbserver.

Wahrscheinlich schon. Auch bei der der OSX-Variante ist das so.

Zitat:

Meiner Meinung nach Wunschdenken. Die werden wohl den Weg des geringsten Aufwands gehen. Und das wäre eine existierende Lösung ala Qt. Was dann wiederum eigene Vorteile (aber auch ein paar Nachteile) mit sich brächte.

Entweder FMX oder gar keine UI. Für die Linuxplattform wird man keinen Sonderweg gehen.

[Assarbad]

Zitat:

Zitat von mkinzler (Beitrag 1346807)

Entweder FMX oder gar keine UI. Für die Linuxplattform wird man keinen Sonderweg gehen.

Es ging ja auch um den Unterbau welcher am wahrscheinlichsten wäre.

[Valle]

Zitat:

Zitat von Assarbad (Beitrag 1346799)

Den großen Nachteil einer statisch gelinkten Datei hat Valle natürlich tunlichst verschwiegen: die LGPL.

Nicht verschwiegen, aber vergessen, ja.

Zitat:

Zitat von Assarbad (Beitrag 1346799)

Linux besteht aus einem Kernel - Punkt. Was du vermutlich meinst ist der GNU-Aufsatz auf dem Linuxkernel ;)

Für diese Diskussion bist du leider 20 Jahre zu spät.

Zitat:

Zitat von Assarbad (Beitrag 1346799)

Zitat:

Zitat von Valle (Beitrag 1346334)

Wir Softwareentwickler wissen aber, dass ständige Rückwärtskompatibilität selten etwas gutes für unsere Software bedeutet.

Den müßtest du - zumindest mir - nochmal erklären.

Für mich bedeutet Rückwärtskompatibilität mehr Arbeitsaufwand. Die Kompatibilität erhält sich leider meist nicht von selbst. Mehr Arbeit und das "Herumschleppen" alten Codes sind für mich Nachteile. Auch sich daraus ergebene APIs tendieren dazu, weniger schön zu werden. Das bedeutet nicht, dass es nicht notwendig sei. Manchmal will man gern alten Kram über Board werfen, aber das geht nun mal nicht immer.

[Assarbad]

Zitat:

Zitat von Valle (Beitrag 1346842)

Zitat:

Zitat von Assarbad (Beitrag 1346799)

Den großen Nachteil einer statisch gelinkten Datei hat Valle natürlich tunlichst verschwiegen: die LGPL.

Nicht verschwiegen, aber vergessen, ja.

Hmm, da habe ich Vorsatz unterstellt wo es keinen gab. Verzeihung :oops:

Zitat:

Zitat von Valle (Beitrag 1346842)

Für diese Diskussion bist du leider 20 Jahre zu spät.

Der Standpunkt von RMS ist mir leidlich bekannt. Die Frage ist nur in der Tat, wie man kurz und bündig von einem Linuxkernel mit GNU-Userland spricht und dies gleichzeitig von nicht GNU-basierten Systemen abgrenzt? Android läuft ja auch auf einem Linuxkernel, aber mit eigener C-Laufzeitbibliothek (Bionic) und einer Menge Komponenten die nicht unter GPL stehen oder dem GNU-Projekt unterstellt sind.

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:

Zitat von Valle (Beitrag 1346842)

Für mich bedeutet Rückwärtskompatibilität mehr Arbeitsaufwand. Die Kompatibilität erhält sich leider meist nicht von selbst. Mehr Arbeit und das "Herumschleppen" alten Codes sind für mich Nachteile. Auch sich daraus ergebene APIs tendieren dazu, weniger schön zu werden. Das bedeutet nicht, dass es nicht notwendig sei. Manchmal will man gern alten Kram über Board werfen, aber das geht nun mal nicht immer.

Für mich bedeutet das Erstellen von x Varianten desselben Projekts viel mehr Aufwand als einmal (wir sprachen ja über glibc) eine Lösung zu erarbeiten und diese konsequent einzusetzen. Oft läuft es ja auch darauf hinaus alte Distros vorzuhalten zu denen man nicht einmal mehr Medien bekommt. Denn jede Variante will getestet sein. Wenn aber nicht nur die C-Laufzeit, sondern auch andere Bibliotheken ins Spiel kommen, kann es zugegebenermaßen schnell unübersichtlich werden überhaupt eine Rückwärtskompatibilität herzustellen (wie in deinem Beispiel mit MySQL). Zum Glück habe ich dieses Problem nur mit der glibc [1] und nicht mit anderen Bibliotheken.

[1] und dann kann man mit musl-libc oft selbst statisch gelinkte Dateien kleiner bekommen als dynamisch gegen die glibc gelinkten.

[Rollo62]

Hallo Asserbad,

dankesehr für deine Erleuchtungen und Lesetips :-)
Es ist doch gut zu wissen das sich hier schon einige Linux-Experten tummeln.

Zitat:

Zitat von Assarbad (Beitrag 1346799)

Es ist herzlich irrelevant welcher Compiler genutzt wird. Das vermeintliche Problem entsteht durch die Standardeinstellung des Linkers (und der kann gesteuert werden, so daß es überhaupt kein Problem gibt, wenn man sich damit beschäftigt).

Vielleicht habe ich das nicht korrekt beschrieben, mit GCC meinte ich die ganze Toolchain im Vergleich zu BCB (auch mit Compiler/Linker).

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

[Assarbad]

Zitat:

Zitat von Rollo62 (Beitrag 1346888)

dankesehr für deine Erleuchtungen und Lesetips :-)

Gern.

Zitat:

Zitat von Rollo62 (Beitrag 1346888)

Es ist doch gut zu wissen das sich hier schon einige Linux-Experten tummeln.

Naja, also als Experten würde ich mich nicht sehen. Aber auch nicht mehr als blutiger Anfänger.

Zitat:

Zitat von Rollo62 (Beitrag 1346888)

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 ?

FPC umgeht das allem Anschein dadurch, daß sie eine eigene Laufzeit implementieren, welche direkt auf den Systemaufrufen aufsetzt. Das macht total viel Sinn und erleichtert bspw. die Portierung auf andere unixartige Systeme ungemein, denn die glibc ist nicht gerade dafür bekannt sich an Standards zu halten. Nicht nur daß man das Lizenzproblem mit glibc umschifft, nein man kann je nach Zielsystem bspw. einfach die Nummern der Systemaufrufe anpassen und hat sofort eine lauffähige Laufzeitumgebung. Das ist exakt weswegen es SUS (ehemals POSIX) gibt. Denn die Portierbarkeit bezieht sich ja in der Tat vor allem auf die standardisierte Schnittstelle Systemaufruf, sowie die C-Laufzeit welche zu einem bestimmten Grad standardisiert ist.

Zitat:

Zitat von Rollo62 (Beitrag 1346888)

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

Klingt auch irgendwie wie das schlechteste aus beiden Welten, es sei denn nur der BCB-Compiler würde benutzt und als Linker der von MSVC und das ganze würde in Debugsymbolen resultieren welche WinDbg lesen kann. Wobei vermutlich dazu Anpassungen seitens BCB notwendig wären. Aber Clang beweist, daß es geht.

Zitat:

Zitat von Rollo62 (Beitrag 1346888)

So könnte man die ganzen bestehenden Projekte in Linux/Windows direkt ohne Umweg nutzen.

Also einige Kommandozeilenprogramme solltest du im Prinzip ohne Umweg sowohl mit BCB als auch MSVC und auf Linux mit Clang oder GCC kompilieren können. Da gibt es nur im Detail Unterschiede oder verschiedene #ifdef-Blöcke je nach System oder Compiler (siehe auch predef.sf.net).

Zitat:

Zitat von Rollo62 (Beitrag 1346888)

Ich sehe aber das es Zeit wird sich mal tiefer mit Linux zu beschäftigen
(das wollte ich schon seit Jahren).

Viel Spaß und Erfolg!

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

[Valle]

Zitat:

Zitat von Assarbad (Beitrag 1346893)

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

Ja, natürlich. Hab ich das irgendwo abgestritten?

(Wobei strenggenommen läuft da kein Linux in deinem Container, da die Container den Hostkernel verwenden. Da läuft nur GNU. Soviel dazu.)

[Assarbad]

Zitat:

Zitat von Valle (Beitrag 1346895)

Ja, natürlich. Hab ich das irgendwo abgestritten?

Nein. Verzeih. Ich dachte nur die Information könnte interessant sein für dich. Immerhin ist das nirgends offiziell dokumentiert, daß man auch 32-bittige Gäste auf einem x86_64-Kernel laufenlassen kann (chroot oder LXC).

Zitat:

Zitat von Valle (Beitrag 1346895)

(Wobei strenggenommen läuft da kein Linux in deinem Container, da die Container den Hostkernel verwenden. Da läuft nur GNU. Soviel dazu.)

Kommt auf die verwendete Technik an, bei Namensräumen (LCX) kann man schon davon sprechen, daß auch ein Teil des Kernels im Container läuft, bei chroot eher nicht. Es ging aber oben auch um die Distro (also den Teil den du als Linux bezeichnetest). Da habe ich mich deiner Sprachregelung angepaßt und nun wirfst du es mir vor ... :roll: