Kurz und knapp: 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? Warum? Weil die Kompilierung unter Windows 10 nicht funktioniert. Hat hier jemand gute Ideen zur Lösung und kann sie hier für die User hier posten?
Dafür gibt's spezielle Cross-Compiler wie i686-w64-mingw32-gcc.
Esmu P. schrieb: > 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.
Esmu P. schrieb: > kann ich mit dem Kompiler unter Linux auch eine *.exe Datei > erzeugen die auch unter Windows10 funktioniert? Mit dem Compiler geht das wohl nicht, aber mit dem anderen. Bitte, gerne geschehen.
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.
Unter Debian:
1. sudo apt install apt install gcc-mingw-w64-i686-win32
2. echo "int main(void) { printf(\"Hello World\\n\");}" > hello.c
3. i686-w64-mingw32-gcc hello.c -o hello.exe
4. wine hello.exe
Hello World
:)
Eventuell musst du unter Windows dann noch nach ein paar notwendigen
DLLs Ausschau halten.
Motopick schrieb: > 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.
Esmu P. schrieb: > Warum? Weil die Kompilierung unter Windows 10 nicht funktioniert. [ ] Der Compiler gibt ohne Ausgabe einer Fehlermeldung auf [ ] Windows 10 enthält gar keinen Compiler [ ] Der Compiler lässt sich unter Windows 10 nicht aufrufen, es erscheint die Fehlermeldung, daß 16-Bit-Code nicht ausgeführt werden kann [ ] Der Compiler gibt diverse Fehlermeldungena aus, Du hast aber keine Lust, sie Dir anzusehen [ ] Du machst irgendwas anderes falsch
Es ist jetzt nicht mehr nötig, da ich die Kompilierung unter Windows hin bekommen habe. :-) Habe das Makefile passend editiert.
Malte _. schrieb: > Unter Debian: > > 1. sudo apt install apt install gcc-mingw-w64-i686-win32 > 2. echo "int main(void) { printf(\"Hello World\\n\");}" > hello.c > 3. i686-w64-mingw32-gcc hello.c -o hello.exe > 4. wine hello.exe > > Hello World > > :) > > Eventuell musst du unter Windows dann noch nach ein paar notwendigen > DLLs Ausschau halten. Was ist Wein? Ich benutze es nicht. Im letzten Jahrtausend ein paar Male verwendet.
Johann L. schrieb: > Dafür gibt's spezielle Cross-Compiler wie i686-w64-mingw32-gcc. Danke für den Tip! Den unter Linux, hier ein Mint-System, installieren reicht aus? Oder muß man dann wieder herum frickeln?
Esmu P. schrieb: > Den unter Linux, hier ein Mint-System, installieren reicht aus? Oder muß > man dann wieder herum frickeln? Keiner von uns weiß, welche Bibliotheken Du verwenden willst... Und eigentlich interessiert es auch keinen.
Esmu P. schrieb: > Was ist Wein? Ich benutze es nicht. Im letzten Jahrtausend ein paar Male > verwendet. Wine, nicht Wein. Und wenn du es ein paar mal verwendet hast, dann weisst du auch, was es ist.
Andreas S. schrieb: > 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.
In erster Annäherung ist es völlig egal! Aber: 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.
Andreas S. schrieb: > Esmu P. schrieb: >> Den unter Linux, hier ein Mint-System, installieren reicht aus? Oder muß >> man dann wieder herum frickeln? > > Keiner von uns weiß, welche Bibliotheken Du verwenden willst... Und > eigentlich interessiert es auch keinen. Ja, wenn ich das nur selber wüßte? Geht jetzt aber auch am Thema vorbei, es geht mir um ein prinzipielles vorgehen.
Moin, Esmu P. schrieb: > Ja, wenn ich das nur selber wüßte? 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. Gruss WK
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. Das sollte doch irgendwie gehen. Ok, diese eine Antwort mit dem Cross-compiler Beitrag "Re: Kompiler unter Linux soll eine *.exe für Windows erzeugen" zeigt schon einmal die grobe Richtung vor. Habe ich aber noch nie gemacht, daher meine Eingangsfrage.
:
Bearbeitet durch User
G. K. schrieb: > 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" > bei normalen Unix-Sourcen
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.
Esmu P. schrieb: > Andreas S. schrieb: >> 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.
Stefan F. schrieb: > 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.
Andreas S. schrieb: > 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".
Stefan F. schrieb: > 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. https://wiki.archlinux.org/title/Open_Watcom
Rbx schrieb: > Dann mal schauen, wie gut man den OpenWatcom-Compiler unter Wine zum > laufen bekommt. Sinnvoller dürfte es sein, llvm/clang zu verwenden und dem die maschinenspezifischen Libraries/Header/etc. unterzujubeln. Die kann man beispielsweise einer Windows-Installation von llvm/clang entnehmen. Und man kann damit auch den Gegenweg gehen, unter Windows nativ ausführbare *nix-Binaries erzeugen. Vorteil: Moderner Compiler, kein Emulationsgekrampfe mit Wine o.ä.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.