Portable Programmierung mit C und Makefiles

@darktym: Hatte ich ja oben schon geschrieben, die exe funktioniert nicht.

Fehlermeldung beim Aufruf:
Die Version von C:\Users\rubri\project\vsh\bin\vsh.exe ist mit der ausgeführten Windows-Version nicht kompatibel. Überprüfen Sie die Systeminformationen des Computers, und wenden Sie sich anschließend an den Herausgeber der Software.

Aber da Lua problemlos kompiliert und inzwischen auch Cello habe ich genug make Material um herauszufinden was da falsch läuft, vermutlich einige Flags. Ich verstehe den ganzen Make- und Kompilationsprozess eben noch nicht ausreichend. Wir werden sehen und dann kann ich ggf. gezieltere Fragen stellen....

Nachtrag: Cello macht eine raffinierte Platform-Abfrage die, wenn ich das richtig verstehe, allein mit internen Make-Mitteln funktioniert und keine externen tools benötigt. Verstehe ich im Moment allerdings noch nicht...
 
Zuletzt bearbeitet:
@gadean: Das ist ja ein tolles tool. Danke!
@darktrym: Nöö, fängt mit 'dt' an. Ich hänge den dump mal an.

Schon erstaunlich mit was man sich alles beschäftigen muss um mit C ernsthaft zu arbeiten...
 

Anhänge

  • main.txt
    4,3 KB · Aufrufe: 284
So, das war die Quelle allen Ungemaches: Nicht 'std=c99' sondern 'std=gnu99' ist gefordert. Und schon läuft es!

Solche Sachen nerven! Aber es kann weiter gehen... :-)

Nachtrag: Man muss wohl eine Rechtsanwaltseele haben um die Doku eindeutig zu verstehen.
 
Zuletzt bearbeitet:
Nur eine Randbemerkung.
Es gab und gibt Projekte die das perfektioniert haben/hatten.
Bei mir war es Gnuplot, das habe ich vor mehr als 20 Jahren per Quellcode auf jede Plattform bringen
können. Die damaligen Entwickler haben da wirklich einen super Job gemacht.
Und was die Funktionalität von Gnuplot angeht, respekt!

Der Makefile hatte es wirklich in sich. Vor allem, wenn man selbst
Code einbauen wollte.

Und ich arbeite immer noch gern damit! Genauso wie mit XFIG!!

Aber das ist alles verdammt lang her und die Welt war noch offen.
Und Linux noch nicht kommerzialisiert.
 
@
Nun ist gnu99 natürlich wieder ein ganz eigener "Standard"...
Mag ja sein, aber dessen Compiler ich benutze, dessen Flags muss ich fressen. Dürfte bei VC auch nicht anders sein. Und was heißt schon 'standart' und wer definiert den ?

@f41thr : Es gibt schon noch Software die das auch heute noch hinbekommt. Sowohl Lua als auch die Cello sind wohl so etwas. Das ist eine Frage der Sorgfalt für die nicht immer jeder Zeit hat, - insbesondere natürlich wenn damit Geld verdient werden muss. Und die alten Zeiten waren nun wirklich nicht immer besser!
 
@CrimsonKing: Kann man so sehen, - oder auch nicht! Das Problem mit solchen Std. ist dass das sich die relevanten Player (1) darauf einigen müssen, (2) das implementieren und sich (3) auch daran halten müssen. Und der Prozess dauert so lange dass der Std. möglicherweise antiquiert erscheint. Denke mal an posix.

Ich betrachte GNU als so etwas wie einen Industriestandart.Wir leben leider nicht wie der alte Leibnitz meinte in der besten aller Welten. Aber das wird OT
 
Zuletzt bearbeitet:
Außer Microsoft haben "die relevanten Player" C11 implementiert. Microsoft will nicht. Microsoft will nur C++ (da sind sie allerdings unter den Ersten) und C#. Schade eigentlich.
 
Was ist vcvarsall? Gibt es bei Mysys2 nicht.

Das ist ein Batch-Skript, was die Umgebungsvariablen passend zur aktuellen Visual Studio Installation und Konfiguration setzt. Visual Studio installiert seinen Kram irgendwo unter c:\Program Files (x86)\Visual Studio 2017\Community\1.23.456\VC und liest alles andere aus diesen Umgebungsvariablen. Der Visual Studio Installer legt normalerweise Links für die verschiedenen Konfigurationen im Startmenü an, ich glaube auf Deutsch heißt es "Entwicklungskonsole" oder so. Alternativ kann man auch das Batch-Skript in einem eigenen Konsolenfenster ausführen, aber dann muss man eben den Pfad wissen (was leicht umständlich ist).

So, das war die Quelle allen Ungemaches: Nicht 'std=c99' sondern 'std=gnu99' ist gefordert. Und schon läuft es!

Das klingt nach einem Bug, die Standardversion der Programmiersprache sollte eigentlich keinen Einfluss auf das Dateiformat der erstellten Datei haben. Am Ende sollte so oder so eine PE Datei für das aktuelle System entstehen.
Das einzige was ich mir noch vorstellen kann ist dass das System die Laufzeitbibliothek von mingw nicht finden kann, aber eigentlich müsste das eine andere Fehlermeldung geben.
 
Das klingt nach einem Bug, die Standardversion der Programmiersprache sollte eigentlich keinen Einfluss auf das Dateiformat der erstellten Datei haben.
Na ja, das ist ja die cmdline für den Compiler und hat mit der Sprache selbst nichts zu tun.
Am Ende sollte so oder so eine PE Datei für das aktuelle System entstehen.
Was meinst due mit PE Datei? Eine executable (.exe unter windows);
 
Dein main.(txt|exe) habe ich mal in dependencywalker geladen. Der erkennt auch den Header nicht.

Dein main.c hab ich mit mingw64 übersetzt. Das funktionierte einwandfrei unter Win7 und Win10 (jeweils 64 Bit).
Code:
[EMAIL]xx@xxxMINGW64[/EMAIL] ~
$ nano main.c
[EMAIL]xx@xxx MINGW64[/EMAIL] ~
$ gcc main.c -o test
[EMAIL]xx@xxx MINGW64[/EMAIL] ~
$ ./test.exe
Hallo World
[EMAIL]xx@xxx MINGW64[/EMAIL] ~
$ gcc --version
gcc (GCC) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.
[EMAIL]xx@xxx[/EMAIL] MINGW64 ~ ldd test.exe
ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x77cb0000)
kernel32.dll => /c/Windows/system32/kernel32.dll (0x77a90000)
KERNELBASE.dll => /c/Windows/system32/KERNELBASE.dll (0x7fefda00000)
SYSFER.DLL => /c/Windows/System32/SYSFER.DLL (0x75540000)
msys-2.0.dll => /usr/bin/msys-2.0.dll (0x180040000)
[/code}
 

Anhänge

  • B1.PNG
    B1.PNG
    31,4 KB · Aufrufe: 329
@schorsch_76: Interessant! Heißt dass das mingw64 -std=c99 akzeptiert oder brauchen die auch -std=gnu99? Oder hat das mit dem Pfad zu den mingw-libs zu tun? Ich werde das später wohl mal selbst ausprobieren. Jetzt muss ich erst einmal weiterkommen und es gibt ja leider auch noch anderes zu tun.

Danke für den Hinweis auf Dependency walker!
 
@rubricanis : Ich hab das aktuelle msys2 runtergeladen und installiert. pacman -Suy laufen lassen bis alles aktuell war. Mit pacman -S gcc make nano installiert. Mit nano dein main.c editiert und die obigen Kommandos ausgeführt. War sehr straight Forward. Ich denke dass evtl. dein Update schief gegangen ist. Mein msys64 Ordner ist direkt unter D:
 
@schorsch_76: OK, du hast den -std= rausgelassen. Dann benutz gcc ein Fallback, vermutlich gnu89. Aber ist auch egal, das Problem ist gelöst. Ich habe auch mysys2 installiert (gcc 8.2) und dann funktioniert das. Mich hätten noch die anderen MingW-Installationen interessiert: x86_64-w64-mingw32-gcc und i686-w64-mingw32-gcc. Was für eine bekloppte Namensgebung! Das werde ich gelegentlich mal ausprobieren.
 
Wenn du nur einen reine GNU-Toolchain ohne das nachgebaute unoixide Userland außen herum haben willst, schaue mal tdm-gcc an: http://tdm-gcc.tdragon.net Das ist so für sicher aber mittelsinnlos. Da kann man dann auch gleich wieder Clang nehmen, was ja direkt ohne externe Patches und Gemurkse Windows spricht. Clang hat außerdem einen mit cl.exe kompatiblem Driver, wodurch er sich viel besser in die Windows-Welt integriert.
 
Na ja, das ist ja die cmdline für den Compiler und hat mit der Sprache selbst nichts zu tun.

Dieses Flag bestimmt den Sprachstandard, hat also alles damit zu tun: https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/C-Dialect-Options.html#C-Dialect-Options
(Und ja, ich habe die aktuellste GCC-Doku verlinkt, aber die Option gibt es schon seit Ewigkeiten).

Was meinst due mit PE Datei? Eine executable (.exe unter windows);

Genau, wie CrimsonKing schon gesagt ist dass das Binärformat von Windows, so wie eben aktuelle unixoide Systeme ELF verwenden. Ich habe deine Fehlermeldung aber noch nie gesehen und könnte daher lediglich spekulieren.
 
Wenn du nur einen reine GNU-Toolchain ohne das nachgebaute unoixide Userland außen herum haben willst, schaue mal tdm-gcc an: http://tdm-gcc.tdragon.net Das ist so für sicher aber mittelsinnlos.
TDM-GCC habe ich früher mal zum lernen von C verwendet und der war dazu auch ok. Die verwenden jetzt gcc 5.1, und das ist mir zu outdated und läßt Zweifel an dessen weiteren Entwicklung aufkommen. Ich habe keine Lust auf ein totes Pferd zu setzen.

Mir geht es nicht um die GNU-Toolchain, sondern um Portabilität. Zur Zeit verwende ich Win10, im Winter wieder Fedora, demnächst vielleicht einen Mac oder mal wieder ein BSD. Das was ich mache soll überall ohne allzu großen Aufwand laufen. Als portables GUI habe ich IUP ins Auge gefaßt was ein ziemliches Hammerding ist. Bei der Beschäftigung mit Scheme bin ich zu der Auffassung gelangt dass jede Sprache neben einem gmdline interface auch ein gutes GUI-Toolkit braucht. Das ist z.B. ein wesentlicher Unterschied zwischen Racket und Chicken. Chicken war ohne gui ein wenig frustrierend.
Da kann man dann auch gleich wieder Clang nehmen, was ja direkt ohne externe Patches und Gemurkse Windows spricht. Clang hat außerdem einen mit cl.exe kompatiblem Driver, wodurch er sich viel besser in die Windows-Welt integriert.
An clang bin ich bislang gegscheitert, obwohl ich das gerne verwenden würde. Ich hatte das als binary heruntergeladen und dann suchte es nach den <std*.h>. Die gcc-header waren Fehlerhaft und ich konnte die auch auch nicht bei VC-7 finden. Ich wußte bislang noch nichts von clang-cl und vcvarsall.bat. Ich werde mich damit befassen sobald ich Zeit habe, im Moment steht aber noch make und compilation im Vordergrund. Clang soll ja diesbezgl. weitgehend kompatibel zu gcc sein.

Ich hoffe ich nerve hier nicht mit solchen Fragen. Ich hatte zwar schon mit einer Reihe von Sprachen zu tun, aber noch nie mit so low-level Kram. Sprachen sind eine Sache, die Umgebung eine andere, Dokumentation eine dritte...
 
Zuletzt bearbeitet:
Zurück
Oben