Hallo, vielleicht hat hier noch jemand einen hilfreichen Tipp? Auch wenn ich in der Konsole: make —-Version eingebe meldet er sich nicht Den Pfad habe ich schon eingegeben… grr
Da das normalerweise alles völlig problemlos funktioniert, wird’s wohl ein Ebene 8 Problem sein. Oliver
Oliver S. schrieb: > Da das normalerweise alles völlig problemlos funktioniert, wird’s > wohl > ein Ebene 8 Problem sein. > > Oliver Danke! Problem: vor längerer Zeit hat es funktioniert. Keine Ahnung ob es noch unter W7 war oder schon mit W10? Ich hatte einen Systemcrash mit W10 und das neu installiert. MSVS 2022 funktioniert jedenfalls korrekt so wie ich es sehe. Mir fehlt echt jetzt der Ansatz zur Fehlersuche.
schon lange her das ich das benutzt habe, aber da gab es eine Batchdatei die man starten musste für die Msys Umgebung. In der normalen Windows CMD geht das nicht.
J. S. schrieb: > schon lange her das ich das benutzt habe, aber da gab es eine > Batchdatei > die man starten musste für die Msys Umgebung. In der normalen Windows > CMD geht das nicht. Das kann nicht die Ursache sein. Unter Windows muß sich make ansprechen lassen. Das ist ein DOS Programm. Ich hatte es ja schon früher als es funktionierte in der Konsole erfolgreich testen können.
Windows kannte nie ein make, da muss etwas zusätzlich installiert werden und dann auch im Suchpfad stehen. Oder man startet eben eine Batchdatei die den Suchpfad für die gestartete Konsole setzt.
J. S. schrieb: > Windows kannte nie ein make, da muss etwas zusätzlich installiert > werden > und dann auch im Suchpfad stehen. Oder man startet eben eine Batchdatei > die den Suchpfad für die gestartete Konsole setzt. Stimmt, den mußte man irgendwie nach installieren. Ich suche in dieser Richtung weiter.
Windows10 schrieb: > J. S. schrieb: >> Windows kannte nie ein make, da muss etwas zusätzlich installiert >> werden >> und dann auch im Suchpfad stehen. Oder man startet eben eine Batchdatei >> die den Suchpfad für die gestartete Konsole setzt. > > Stimmt, den mußte man irgendwie nach installieren. > > Ich suche in dieser Richtung weiter. Jetzt: Ein neuer Versuch. https://www.technewstoday.com/install-and-use-make-in-windows/
gucke doch erstmal ob nicht so ein Link für eine MSys Konsole unter der MSys Installation in den Programmen liegt.
und wenn es um Cross Compilation für Cortex-M geht, dann ist WSL mittlerweile eine gute Wahl.
Windows10 schrieb: > Windows10 schrieb: >> J. S. schrieb: >>> Windows kannte nie ein make, da muss etwas zusätzlich installiert >>> werden >>> und dann auch im Suchpfad stehen. Oder man startet eben eine Batchdatei >>> die den Suchpfad für die gestartete Konsole setzt. >> >> Stimmt, den mußte man irgendwie nach installieren. >> >> Ich suche in dieser Richtung weiter. > Jetzt: > > Ein neuer Versuch. > > https://www.technewstoday.com/install-and-use-make-in-windows/ Microsoft Windows [Version 10.0.19044.2364] (c) Microsoft Corporation. Alle Rechte vorbehalten. C:\Users\Privat>make --version GNU Make 4.3 Built for Windows32 Copyright (C) 1988-2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>; This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Das war es. :-)) endlich.
Damit bist du aber nicht in der MSys Welt. Die Toolchain(s) fehlen ja noch und die laufen dann auch unter Windows. Wenn ein makefile ein rm zum aufräumen benutzt, dann funktioniert das auch nicht. make unter Windows ist eine Krücke. Und es kann mit anderen Umgebungen kollidieren wenn die das zuerst im Suchpfad finden und ein anderes make haben wollen. Wenn es um Selbstgebautes geht, dann sollte man sich eher CMake und Ninja ansehen.
J. S. schrieb: > Windows kannte nie ein make, da muss etwas zusätzlich installiert werden > und dann auch im Suchpfad stehen. Was genauso für msys2 gilt. Auch da muß man make und auch gcc installieren, sonst gibts die da auch nicht. Oliver
J. S. schrieb: > Wenn ein makefile ein rm > zum aufräumen benutzt, dann funktioniert das auch nicht. Vielleicht ist ja auch die Idee, betriebssystemabhängige Dinge in Makefiles zu stecken, nicht die hellste Kerze auf der Torte.
J. S. schrieb: > Damit bist du aber nicht in der MSys Welt. Die Toolchain(s) fehlen > ja > noch und die laufen dann auch unter Windows. Wenn ein makefile ein rm > zum aufräumen benutzt, dann funktioniert das auch nicht. make unter > Windows ist eine Krücke. Und es kann mit anderen Umgebungen kollidieren > wenn die das zuerst im Suchpfad finden und ein anderes make haben > wollen. > Wenn es um Selbstgebautes geht, dann sollte man sich eher CMake und > Ninja ansehen. Na, erst einmal muß eines erst funktionieren bevor man andere Möglichkeiten ausprobieren kann. Habe jetzt ein Programm compiliert was ich schon unter MSVS zum laufen gebracht hatte. Dazu mußte ich das Makefile anpassen. Das Makefile ist sehr, sehr lang ca. 1000 Zeilen….
Windows 10 schrieb: > J. S. schrieb: >> Damit bist du aber nicht in der MSys Welt. Die Toolchain(s) fehlen >> ja >> noch und die laufen dann auch unter Windows. Wenn ein makefile ein rm >> zum aufräumen benutzt, dann funktioniert das auch nicht. make unter >> Windows ist eine Krücke. Und es kann mit anderen Umgebungen kollidieren >> wenn die das zuerst im Suchpfad finden und ein anderes make haben >> wollen. >> Wenn es um Selbstgebautes geht, dann sollte man sich eher CMake und >> Ninja ansehen. > > Na, erst einmal muß eines erst funktionieren bevor man andere > Möglichkeiten ausprobieren kann. > > Habe jetzt ein Programm compiliert was ich schon unter MSVS zum laufen > gebracht hatte. Dazu mußte ich das Makefile anpassen. Das Makefile ist > sehr, sehr lang ca. 1000 Zeilen…. https://ibb.co/k6nCmFX
Windows10 schrieb: > Windows 10 schrieb: >> J. S. schrieb: >>> Damit bist du aber nicht in der MSys Welt. Die Toolchain(s) fehlen >>> ja >>> noch und die laufen dann auch unter Windows. Wenn ein makefile ein rm >>> zum aufräumen benutzt, dann funktioniert das auch nicht. make unter >>> Windows ist eine Krücke. Und es kann mit anderen Umgebungen kollidieren >>> wenn die das zuerst im Suchpfad finden und ein anderes make haben >>> wollen. >>> Wenn es um Selbstgebautes geht, dann sollte man sich eher CMake und >>> Ninja ansehen. >> > >> Na, erst einmal muß eines erst funktionieren bevor man andere >> Möglichkeiten ausprobieren kann. >> >> Habe jetzt ein Programm compiliert was ich schon unter MSVS zum laufen >> gebracht hatte. Dazu mußte ich das Makefile anpassen. Das Makefile ist >> sehr, sehr lang ca. 1000 Zeilen…. > > https://ibb.co/k6nCmFX Grrrrrr.... So ein Mist! Wo bekomme ich die richtige *.dll her und wo gehört sie konkret hin?
Windows10 schrieb: > https://ibb.co/k6nCmFX Du kannst in diesem Forum Bilder hochladen. Du musst nicht in jedem Beitrag alles, was Du davor geschrieben hast, wieder und wieder zitieren. Das müllt nur das Forum zu. Wenn eine DLL nicht gefunden wird, ist sie vielleicht nur nicht dort, wo sie hingehört.
DerEinzigeBernd schrieb: > Windows10 schrieb: >> https://ibb.co/k6nCmFX > > Du kannst in diesem Forum Bilder hochladen. > > Du musst nicht in jedem Beitrag alles, was Du davor geschrieben hast, > wieder und wieder zitieren. Das müllt nur das Forum zu. > > Wenn eine DLL nicht gefunden wird, ist sie vielleicht nur nicht dort, wo > sie hingehört. Deshalb meine Frage, siehe oben.
Am einfachsten ist es, die DLL genau dorthin zu packen, wo die die DLL verwendende ausführbare Datei liegt. Alternativ kann die DLL in das zur ausführbaren Datei passende System-Verzeichnis kopiert werden. Bei 32-Bit-Binaries unter 64-Bit-Windows ist das %sysroot%\syswow64, bei 32-Bit-Binaries unter 32-Bit-Windows und bei 64-Bit-Binaries unter 64-Bit-Windows ist das %sysroot%\system32. Was ist eigentlich das Ziel der Übung?
DerEinzigeBernd schrieb: > Am einfachsten ist es, die DLL genau dorthin zu packen, wo die die > DLL > verwendende ausführbare Datei liegt. > > Alternativ kann die DLL in das zur ausführbaren Datei passende > System-Verzeichnis kopiert werden. Bei 32-Bit-Binaries unter > 64-Bit-Windows ist das %sysroot%\syswow64, bei 32-Bit-Binaries unter > 32-Bit-Windows und bei 64-Bit-Binaries unter 64-Bit-Windows ist das > %sysroot%\system32. > > Was ist eigentlich das Ziel der Übung? Das Ziel besteht darin um 1. kleine Dateigrößen und oder 2. schnelle Ablauf der Dateien zu erstellen mit diversen Compilern. Clang ist sehr schnell aber es soll schnellere geben. Und das möchte ich heraus finden. Mehr nicht.
Windows10 schrieb: > Grrrrrr.... > > So ein Mist! > > Wo bekomme ich die richtige *.dll her und wo gehört sie konkret hin? Wenn du MSYS bzw. MinGW verwendest, dann musst du make mit ming32-make aufrufen und nicht make direkt. Der Befehl ming32-make macht noch ein paar Einstellungen ready, die GNU Make unter Windows braucht. Das gleiche gilt für den gcc und g++ Compiler. Den darfst du nicht wie unter Linux mit: gcc code.c -o program starten, sondern musst mingw32-gcc.exe dafür verwenden. Also so: mingw32-gcc.exe code.c -o programm.exe
Oh, das werde ich prüfen. Vielen Dank erst einmal.
Windows 10 schrieb: > Das Ziel besteht darin um 1. kleine Dateigrößen und oder 2. schnelle > Ablauf der Dateien zu erstellen mit diversen Compilern. > > Clang ist sehr schnell aber es soll schnellere geben. > > Und das möchte ich heraus finden. > > Mehr nicht. Die verschiedenen Compiler haben auch noch unterschiedliche Optimizerstufen. Die müsstest du alle durchprobieren und im Worst Case Fall kann es dir passieren, dass die Anwendung ab einer bestimmten Optimizerstufe nicht mehr sauber läuft, weil der Optimizer Mist gebaut hat. Beim Compilervergleich gibt es mindestens 4 Dinge zu beachten. 1. Sprachsupport und Einhaltung von Standards 2. Laufzeitverhalten des zu erstellenden Programms optimiert auf Ausführungszeit. 3. Das zu erstellende Programm optimiert auf Speicherbedarf. 4. Die Geschwindigkeit des Compilers selbst. Punkt 2 zu optimieren kann bezüglich Punkt 4 Zeit kosten.
>Clang ist sehr schnell aber es soll schnellere geben. Einfach aus Interesse, oder braucht dein Build mehrere Stunden? Ich hatte bei den nachfolgenden Varianten durchaus Unterschiede in der Compilezeit. Aber letzlich waren anderen Parameter wichtiger. * mingw Build si686/x86_64: https://github.com/niXman/mingw-builds-binaries/releases * gcc Crosscompiler (i686, x86_64, armv7 and arm64) Variante auf clang Basis: https://github.com/mstorsjo/llvm-mingw * Linux Varianten unter wsl...
Nano schrieb: > Also so: > > mingw32-gcc.exe code.c -o programm.exe Seit gefühlt zwei zilliarden Jahren ist gcc.exe unter msys2 das selbe wie mingw32-gcc. Oliver
Oliver S. schrieb: > Nano schrieb: >> Also so: >> >> mingw32-gcc.exe code.c -o programm.exe > > Seit gefühlt zwei zilliarden Jahren ist gcc.exe unter msys2 das selbe > wie mingw32-gcc. > > Oliver Ich habe das so immer machen müssen, ansonsten hat irgendwas nicht richtig funktioniert. Wenn sich das inzwischen geändert hat (Quelle?), dann ist das natürlich gut.
Quelle? Keine Ahnung… war schon immer so. Im msys2 bin-Verzeichnis gibts Compiler mit zig verschiedenen Namen, das sind aber alles nur Kopien von ein- und dem selben. Wenn du natürlich noch andere gcc‘s auf dem Rechner hast, dann wird es halt erforderlich sein, den richtigen aufzurufen. Entweder per vollständigem Pfad, oder mit einem seiner exotischen und daher eindeutigen Namen. Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > Quelle? Keine Ahnung… war schon immer so. Schon immer war das definitiv nicht so. Denn wie schon gesagt, früher gab es da dann diverse Fehler. Deswegen habe ich das ja auch dann erst so gemacht. Vorher habe ich auch gcc direkt aufgerufen, wie man es unter Linux macht bis es dann mal ein Problem gab und ich dann herausgefunden habe, dass man das mit dem mingw32.. bzw. mingw64.. davor verwenden muss. > Im msys2 > bin-Verzeichnis > gibts Compiler mit zig verschiedenen Namen, das sind aber alles nur > Kopien von ein- und dem selben. Habe msys2 und mingw gerade nicht unter Windows installiert. Ein MD5 Dateilisting wäre nicht schlecht. > Wenn du natürlich noch andere gcc‘s auf dem Rechner hast, dann wird es > halt erforderlich sein, den richtigen aufzurufen. Nein, das war nicht der Grund, warum man mingw... davor setzen muss.
Nano schrieb: > habe, dass man das mit dem mingw32.. bzw. mingw64.. davor verwenden > muss. Wenn du die 32- und die 64-Bit Version installiert hast, gibts da schon zwei gcc.exe. Und schon gehts mit dem Durcheinander los. Oliver
Oliver S. schrieb: > Nano schrieb: >> habe, dass man das mit dem mingw32.. bzw. mingw64.. davor verwenden >> muss. > > Wenn du die 32- und die 64-Bit Version installiert hast, gibts da schon > zwei gcc.exe. Das "bzw." ist kein "und". So schlau bin ich auch nur eine davon zu installieren. Fakt ist, die gcc.exe war mit bestimmten Umgebungsbedingungen nicht zufrieden, führst du dagegen mingw32-gcc.exe aus, compilierte der Code. Warum ich das weiß? Weil ich genau auf dieses Problem damals mit gcc.exe gestoßen bin und die Verwendung von mingw32-gcc.exe das Problem löste, nach es mir vorgeschlagen wurde das so zu machen. Und bei make ist es genau das gleiche, in verschiedenen Dokus steht das auch so drin.
DerEinzigeBernd schrieb: > Am einfachsten ist es, die DLL genau dorthin zu packen, wo die die > DLL > verwendende ausführbare Datei liegt. > Stimmt! Die dll‘s gehören aber in das Compilat. Mit MSVS macht das nicht so zicken.
Windows 10 schrieb: > Die dll‘s gehören aber in das Compilat. Dann sind es keine DLLs, sondern statische Libraries.
Windows10 schrieb: > Oliver S. schrieb: >> Da das normalerweise alles völlig problemlos funktioniert, wird’s >> wohl >> ein Ebene 8 Problem sein. >> >> Oliver > > Danke! > > Problem: vor längerer Zeit hat es funktioniert. Keine Ahnung ob es noch > unter W7 war oder schon mit W10? Ich hatte einen Systemcrash mit W10 und > das neu installiert. > > MSVS 2022 funktioniert jedenfalls korrekt so wie ich es sehe. > > Mir fehlt echt jetzt der Ansatz zur Fehlersuche. Ich werde jetzt das System Msys2 noch einmal komplett neu installieren. Keine Ahnung was ihm fehlt.
Windows 10 schrieb: > Windows10 schrieb: >> Oliver S. schrieb: >>> Da das normalerweise alles völlig problemlos funktioniert, wird’s >>> wohl >>> ein Ebene 8 Problem sein. >>> >>> Oliver >> >> Danke! >> >> Problem: vor längerer Zeit hat es funktioniert. Keine Ahnung ob es noch >> unter W7 war oder schon mit W10? Ich hatte einen Systemcrash mit W10 und >> das neu installiert. >> >> MSVS 2022 funktioniert jedenfalls korrekt so wie ich es sehe. >> >> Mir fehlt echt jetzt der Ansatz zur Fehlersuche. > > Ich werde jetzt das System Msys2 noch einmal komplett neu installieren. > > Keine Ahnung was ihm fehlt. Was mich sehr wurmt sind das die Fehlermeldungen nichtssagend sind.
Wenn ich überlege wie einfach und zuverlässig es unter Ubuntu funktioniert hat. Und welche unnötigen Klimmzüge einem unter Windows zugemutet werden. Einfach großer Käse.
Ich nutze msys2 fast jeden Tag mit make,cmake, ninja, gcc, clang, qt..., Windows 10 Wichtig: Msys2 kommt in mehreren Varianten, 32/64bit, und verschiedene Runtimes Make und gcc muss man gezielt über Pacman installieren, es ist so gut wie nix per default installiert Jedes Msys2 Environment steht für sich, Tools die du in einem installiert gehen nicht im anderen, in der einfachen Windows Console kommst du nicht dran, ich hatte irgendein msys2 howto gcc x64 Blog zur Hand damit hat alles sofort funktioniert, war mein msys2 Erstkontakt, arbeite sonst nur mit den typischen windows/Linux Tools direkt
install msys2: https://www.msys2.org/ basierend auf: https://www.msys2.org/docs/cmake/ https://stackoverflow.com/questions/30069830/how-to-install-mingw-w64-and-msys2 https://gist.github.com/Bluexin/1c58d9b6d707f755b66a94314e3dfd32 pacman -Syu [optional msys2 Neustart] pacman -Syu pacman -S mingw-w64-x86_64-toolchain pacman -S mingw-w64-x86_64-cmake pacman -S mingw-w64-x86_64-make pacman -S mingw-w64-x86_64-ninja pacman -S mingw-w64-x86_64-clang pacman -S mingw-w64-x86_64-lld pacman -S p7zip pacman -S mingw-w64-x86_64-qt5 [optional] pacman -S mingw-w64-x86_64-qt-creator pacman -S mingw-w64-x86_64-gdb immmer mit "MSYS2 MinGW x64" (MSYS2 ist Standard) starten - damit die MinGW Umgebung Default ist - sonst kann man gcc usw. nicht einfach mit "gcc" erreichen einfach in der Win10-Suchtextzeile "MSYS2 MinGW x64" eingeben
Vielen Dank für die Links. Bin leider erkrankt, daher wird es etwas länger dauern bis ich mich wieder melde. Aber daran kann man erkennen, vier Links aus unterschiedlichen Quellen in einer bestimmten Art und Weise abzuarbeiten ist alles nicht trivial. So wie es aussieht ist Dein Tipp wahrscheinlich zielführend.
Ich war in der Zwischenzeit auch nicht untätig und fand das dazu: https://www.ur.de/assets/physik/fakultaet/IT/Tutorials-Installation-Programming-Environment/main-mingw.pdf
Msys2 ist die aktuellste und gepflegteste Linux-Tools-unter-Windows-Toolchain Bitte nicht mit Cygwin oder dem Mingw Projekt verwechseln Halt dich an meine Liste, so richte ich es immer ein dann läufts
Ich bin immer noch krank und habe in Deinstallation und neu Installation noch nichts unternommen. Mir ist jetzt dazu noch eingefallen das bestimmte Punkte mit Häkchen selektiert werden sollten. Aber ich habe keine Häkchen setzen können. So, jetzt geht es wieder ins Bett.
Windows 10 schrieb: > Mir ist jetzt dazu noch eingefallen das bestimmte Punkte mit Häkchen > selektiert werden sollten. Aber ich habe keine Häkchen setzen können. alles default belassen - Häkchen werden nur gesetzt wenn man sich wirklich auskennt
cppbert schrieb: >> Mir ist jetzt dazu noch eingefallen das bestimmte Punkte mit Häkchen >> selektiert werden sollten. Aber ich habe keine Häkchen setzen können. ich glaube du verwechselst MSYS2 ständig mit den älteren 32bit Cygwin, Mingw Toolchains - die sind "einstellunglastiger" - bei MSYS2 gibt es gar keine Häkchen wenn du nicht unbedingt alles anklickst läuft die Installation direkt durch ohne irgendwelche Fragen - danach die installations-Liste von mir durchmachen, alles andere ist eher für andere ähnliche Toolchains wie Cygwin oder MingW bekannt https://www.msys2.org/ download & install https://github.com/msys2/msys2-installer/releases/download/2022-12-16/msys2-x86_64-20221216.exe dann meine Liste durchmachen und fertig das geht out-of-the-box - wenn du nicht noch irgendwas anderes ausprobierst oder rumspielst
Windows10 schrieb: > Auch wenn ich in der Konsole: > > make —-Version eingebe meldet er sich nicht Das ist erst problematisch, wenn es nach einem Neustart immer noch nicht geht.
rbx schrieb: > Das ist erst problematisch, wenn es nach einem Neustart immer noch nicht > geht. nach der Installation braucht man keine Neustarts damit das geht
cppbert schrieb: > install msys2: https://www.msys2.org/ > > basierend auf: > https://www.msys2.org/docs/cmake/ > https://stackoverflow.com/questions/30069830/how-to-install-mingw-w64-and-msys2 > https://gist.github.com/Bluexin/1c58d9b6d707f755b66a94314e3dfd32 > > pacman -Syu > [optional msys2 Neustart] > pacman -Syu > pacman -S mingw-w64-x86_64-toolchain > pacman -S mingw-w64-x86_64-cmake > pacman -S mingw-w64-x86_64-make > pacman -S mingw-w64-x86_64-ninja > pacman -S mingw-w64-x86_64-clang > pacman -S mingw-w64-x86_64-lld > pacman -S p7zip > pacman -S mingw-w64-x86_64-qt5 > [optional] > pacman -S mingw-w64-x86_64-qt-creator > pacman -S mingw-w64-x86_64-gdb > Bis hierher ist alles noch in Ordnung. Was mir aufgefallen ist dass das unter unter der Konsole "ucrt64" stattgefunden hat. gcc war sofort vorhanden. > immmer mit "MSYS2 MinGW x64" (MSYS2 ist Standard) starten Diesen Satz verstehe ich nicht. Diesen hier? "mingw64" Diese Linux Konsole unter C:\msys64? >- damit die > MinGW Umgebung Default ist - sonst kann man gcc usw. nicht einfach mit > "gcc" erreichen > einfach in der Win10-Suchtextzeile "MSYS2 MinGW x64" eingeben
Vielen dank an diejenigen die wirklich helfen wollten. Leider war alles vergebens. Daher alles in die Mülltonne!!! Das Internet ist voll von den Problemen mit msys... So eine große Scheiße habe ich noch nie gesehen außer der Slackware.
Windows 10 schrieb: > Das Internet ist voll von den Problemen mit msys... Du könntest mal für mich schauen, wie weit man mit der 64Bit-Variante vom Watcom-Compiler bei Windows 10 kommt: https://open-watcom.github.io/ Ansonsten würde ich auch WSL vorziehen.
rbx schrieb: > Windows 10 schrieb: >> Das Internet ist voll von den Problemen mit msys... > > Du könntest mal für mich schauen, wie weit man mit der 64Bit-Variante > vom Watcom-Compiler bei Windows 10 kommt: > https://open-watcom.github.io/ > > Ansonsten würde ich auch WSL vorziehen. Ich bin jetzt endgültig geheilt davon halbfertige Software zu installieren und tappte in die nächste Falle. Sie nennt sich WSL.
Windows 10 schrieb: >> immmer mit "MSYS2 MinGW x64" (MSYS2 ist Standard) starten > Diesen Satz verstehe ich nicht. Ist auch Quatsch. Einfach die passende Shell, I.d.R. mingw64.exe, starten. Oliver
Windows 10 schrieb: > So eine große Scheiße habe ich noch nie gesehen außer der Slackware. Liegt eindeutig an deine Fähigkeiten, bei mir funktioniert es problemlos, so wie unter Linux und WSL - es ist nicht mal klar was nicht geht oder was du überhaupt erreichen wolltest
rbx schrieb: > Du könntest mal für mich schauen, wie weit man mit der 64Bit-Variante > vom Watcom-Compiler bei Windows 10 kommt Warum soll er denn um Himmels Willen einen völlig veralteten Kompiler nutzen (nur super fuer Legacy Zeug) wenn x freie, aktuelle, problemlos funktionierende Kompiler verfügbar sind?
Oliver S. schrieb: > Ist auch Quatsch. Einfach die passende Shell, I.d.R. mingw64.exe, > starten. Ich denke er versteht einfach nicht das man Msys2 mit verschiedenen environments starten kann, im win10 menü kann man das deutlich sehen, darum mein Hinweis es so zu tun
Cppbert schrieb: > nur super fuer Legacy Zeug Das ist nicht der Punkt. Ich hätte eher gesagt, beim Visual Studio bekommt man so einen schönen Debugger mit. Bei Watcom bekommt man dafür einen netten Mausbedienbaren Konsole-VI und kann auch was mit Fortran machen. Aber gut, Fortran geht auch mit mingw https://tough.lbl.gov/assets/docs/support/MinGW-gfortran.pdf
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.