Ich habe in einer virtuellen Maschine Linux installiert.
Damit habe ich ein Programm kompiliert was unter Linux funktioniert.
Frage: kann ich mit dem Kompiler unter Linux auch eine *.exe Datei
erzeugen die auch unter Windows10 funktioniert?
Im Prinzip ist das kein großes Problem. So lange das Programm keine Abhängigkeiten hat, für die es kein passendes Äquivalent unter Windows gibt.
Warum? Weil die Kompilierung unter Windows 10 nicht funktioniert.
Nunja, das kann viele Ursachen haben. Eine davon wäre natürlich: fehlende Abhängigkeiten. Dann ist natürlich genauso Ende Gelände, als wenn du das Zeug unter Linux kompilierst.
Aber es gibt noch mehr Fehlermöglichkeiten, die unter dieser Schwelle bleiben und dementsprechend möglicherweise behebbar wären...
Die Chance, den Kram zum Kompilieren zu bringen, ist also (etwas) höher, wenn du das unter Windows versuchst.
Crosscompilieren ist ein urrrralter Hut.
Schon MS-C V6 konnte unter SCO-UNIX ein EXE-File erzeugen.
Auf Wunsch auch ein COM-File, wenn es denn hineinpasste.
Und das ist nun wirklich schon droellfzik Jahre her.
Ja, mingw sollte die einfachste Lösung sein. Damit cross-compiliere ich aus Windows-Programme von Linux aus. Wenn du aber viele Bibliotheksabhängigkeiten hast, musst du die auch alle bauen. Oder du verwendest mxe. Das dauert zwar etwas, weil es selbst den ganzen Cross-Compiler und die ganzen Libs baut, aber hat bei mir immer hervorragend funktionert. Siehe https://mxe.cc/
Mit clang kann man direkt auch native Windows-Programme erstellen, weil bei dem alle Zielplattformen in einem Compiler eingebaut sind, allerdings braucht man die ganzen Visual-C++-Bibliotheken und Header, weil die bei clang nicht dabei sind.
Crosscompilieren ist ein urrrralter Hut.
Schon MS-C V6 konnte unter SCO-UNIX ein EXE-File erzeugen.
Auf Wunsch auch ein COM-File, wenn es denn hineinpasste.
Und das ist nun wirklich schon droellfzik Jahre her.
Dafür hat dieser Dreck bei normalen Unix-Sourcen ziemlich verkackt.
Keiner von uns weiß, welche Bibliotheken Du verwenden willst.
Wir wissen noch nicht mal, ob es ein C Programm ist, was er compilieren will. Sein verspäteter Hinweis auf das Makefile legt es nahe, muss aber nicht zwingend sein.
Ich hatte die Quelldateien, die nicht von mir stammen, die in c und c++ geschrieben waren, mittels gcc auf einem Linux-Mint System compiliert und auf dem Mint Rechner super funktionieren.
Jetzt will ich auf dem Mint PC das Programm so kompilieren das es auf einem Windows PC auch läuft.
Tja...Das beste Klavier nuetzt nichts, wenn man nicht drauf spielen kann.
Geht jetzt aber auch am Thema vorbei, es geht mir um ein prinzipielles
vorgehen.
Nee, prinzipiell ist das ein grosser Unterschied, ob ich per Crosscompiler sowas wie ein helloworld fuer eine andere Platform bauen will, was "nur" eine libc braucht oder sowas wie z.b. ffmpeg, was je nach config alle moeglichen, teilweise recht "exquisiten" libraries brauchen kann.
Mein persoenlicher Eindruck ist dann auch noch: Je "moderner", d.h. weiter weg von Make und Autotools das Buildsystem ist, desto unangenehmer wird's mit dem crosscompilieren.
Volle Zustimmung, mein in Mint installiertes gcc ist normal mit dem Paketmanager installiert worden, ohne noch zusätzliche Pakete etc. Also Standard Version. Nix gefrickeltes.
Dafür hat dieser Dreck bei normalen Unix-Sourcen ziemlich verkackt.
Moegliche Alternativen waren aber auch seeehr duenn gesaet.
Der GCC war zu der Zeit noch bei Version 1.xyz. :)
Und die Moeglichkeit auch "cross" zu kompilieren dankend
entgegengenommen.
Als ich ein Vektorzeichenprogramm gebraucht habe, liess sich "TGIF"
aus den Quellen problemlos uebersetzen. Sogar mit meinen Aenderungen,
die aus den Zollskalen Centimeterskalen gemacht haben.
Aber netuerlich unter "X". :)
Mitunter lag es vielleicht auch an den "akrobatischen Turnuebungen"
Ich bin früher auf https://www.cygwin.com/ gekommen. Die Grundidee von CygWin ist, sämtliche Standardprogramme von Linux (nicht nicht den Kernel) für Windows zu Cross-Compilieren.
Ich brauchte es, um ein recht komplexes Shell Script unter Windows laufen zu lassen. Später habe ich das auch mal genutzt, um ein selbst entwickeltes C Programm sowohl für Linux als auch Windows bereit zu stellen.
Wenn du ein C Programm mit dem gcc von CygWin zu einer *.exe compilierst, kannst du zahlreiche Bibliotheken und System-Calls aus der Linux Welt nutzen. Die cygwin.dll enthält den dazu nötigen Kompatibilitäts-Layer.
CygWin geht also noch einen Schritt weiter, als ein einfacher Cross-Compiler. Sehr viele Linux Programme lassen sich damit ohne Anpassung unter Windows Nutzen - selbst wenn sie Linux Spezifische System-Calls enthalten.
Keiner von uns weiß, welche Bibliotheken Du verwenden willst... Und
eigentlich interessiert es auch keinen.
Geht jetzt aber auch am Thema vorbei, es geht mir um ein prinzipielles
vorgehen.
Nein, es geht (neben den Einstellungen für die Zielplattform) exat um dieses Thema und wenig anderes. Aber auf Grund Deiner völlig nichtsagenden Fehlerbeschreibungen läuft es wohl fast auf dasselbe hinaus, welche Art von Fehler auftritt.
Suche Dir lieber ein anderes Hobby, z.B. Kieselsteine sammeln.
Ich bin früher auf https://www.cygwin.com/ gekommen. Die Grundidee von
CygWin ist, sämtliche Standardprogramme von Linux (nicht nicht den
Kernel) für Windows zu Cross-Compilieren.
Jein. Die Grundidee besteht darin, eine POSIX- bzw. UNIX-artige Umgebung zu schaffen. Und hierfür bedient sich Cygwin unter anderem(!) der sehr gebräuchlichen GNU-Werkzeuge. Diese wurden ursprünglich aber als Grundlage für GNU Hurd entwickelt, aber dann auch für Linux "geklaut". Korrekterweise spricht man bei heutigen Systemen daher auch nicht von Linux, sondern von GNU/Linux.
Jein. Die Grundidee besteht darin, eine POSIX- bzw. UNIX-artige Umgebung
zu schaffen. Und hierfür bedient sich Cygwin unter anderem(!) der sehr
gebräuchlichen GNU-Werkzeuge. Diese wurden ursprünglich aber als
Grundlage für GNU Hurd entwickelt, aber dann auch für Linux "geklaut".
Sie wurden für GNU entwickelt. Hurd war ein Kernel, der ebenfalls für GNU entwickelt wurde. GNU sollte das neue Betriebssystem von Richard Stallman werden als Nachbau von Unix. Dann kam Torvalds mit seinem Linux-Kernel, und der wurde dann meistens statt Hurd verwendet, weil er schneller voran kam. Zum Ärger von Stallman wurde dann "Linux" als Bezeichnung für das ganze System üblich.
Korrekterweise spricht man bei heutigen Systemen daher auch nicht von
Linux, sondern von GNU/Linux.
Das ist nicht korrekt, denn viele Komponenten sind nicht Teil von GNU, wie z.B. Xorg, der designierte Nachfolger Wayland, KDE, Systemd und Tausende weiterer Tools. Die müssten dann also auch extra genannt werden, und wo hört man da dann auf? Von daher ist "GNU/Linux" eigentlich genauso falsch wie nur "Linux".
Ich bin früher auf https://www.cygwin.com/ gekommen. Die Grundidee
von
CygWin ist, sämtliche Standardprogramme von Linux (nicht nicht den
Kernel) für Windows zu Cross-Compilieren.
Ich brauchte es, um ein recht komplexes Shell Script unter Windows
laufen zu lassen. Später habe ich das auch mal genutzt, um ein selbst
entwickeltes C Programm sowohl für Linux als auch Windows bereit zu
stellen.
Wenn du ein C Programm mit dem gcc von CygWin zu einer *.exe
compilierst, kannst du zahlreiche Bibliotheken und System-Calls aus der
Linux Welt nutzen. Die cygwin.dll enthält den dazu nötigen
Kompatibilitäts-Layer.
CygWin geht also noch einen Schritt weiter, als ein einfacher
Cross-Compiler. Sehr viele Linux Programme lassen sich damit ohne
Anpassung unter Windows Nutzen - selbst wenn sie Linux Spezifische
System-Calls enthalten.
Danke, momentan besteht ja kein Handlungsbedarf. Ich melde mich wie der wenn es akut wird. :-)
Früher konne man mit Cygwin mit einem Schalter beim Kompilieren einfache Windowsprogramme, vor allem kleine Konsolenprogramme erstellen.
Es hieß dann, das der Übersetzer Windows-Ressourcen einbezieht.
Davon ist man aber weg - möglichereise auch wegen verschiedener Windowsversionen und -Bibliotheken da.
Aktuell müsste man bei Cygwin erstmal nachlesen, was aktuell geht, und was nicht.
https://www.cygwin.com/cygwin-ug-net/using-effectively.html
Es hängt bei dem Windowsprogramm auch sehr davon ab, wie kompatibel es ist. Es gibt Windowsprogramme, die laufen auf jedem Windows, bzw. sollten das tun - und andere, die laufen nur mit einem bestimmten Windows oder mit einer bestimmten Entwicklungsstufe.
Aktuell würde ich mal versuchen, wie weit man mit Wine kommt, Programme wie IDA oder Notepad laufen da ja auch ganz gut.
Dann mal schauen, wie gut man den OpenWatcom-Compiler unter Wine zum laufen bekommt.