[offen] Kompilieren für x86 ?

    • Offizieller Beitrag

    Ich habe mal etwas probiert, um Programme sowohl für 32bit, als auch für 64bit zu erstellen.

    x64 ist Standard und somit kein Problem.

    Laut Beschreibung "Use --cpu:i386 or --cpu:amd64 to switch the CPU architecture." sollte also mit --cpu:i386 eine 32bit Version erstellt werden können. (Wobei der Schalter ja auf die CPU Architektur ausgerichtet ist. x86-CPU habe ich schon seit Jahren nicht mehr gesehen, selbst die 8 Jahre alten PC in der Firma haben x64 CPU - Aber: Dort laufen x86-OS!)

    Wie muss ich denn ein Programm erstellen, dass auf CPU(x64) mit OS(x86) laufen soll?

    Ich wollte jetzt meine Dll-Datei mal als x86 erstellen: nim c --app:lib --cpu:i386 -o:math32.dll math.nim

    Das haut mir der Compiler um die Ohren.

    Fehlermeldung
  • Eine Googlesuche bzgl. Nim liefert i.d.R. ja recht überschaubare Ergebnisse ;).

    Diesen Thread hast Du sicher bereits selbst gefunden, oder ?

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

    • Offizieller Beitrag

    Diesen Thread hast Du sicher bereits selbst gefunden, oder ?

    Ja, du brauchst aber keine Threads vor ~2018 ansehen. 90% von dem dort geschriebenen ist inzwischen inhaltlich überholt.

    Das, was dort zusätzlich als Einzelparameter übergeben wird, ist inzwischen schon so in der Konfiguration enthalten.

  • Wenn ich von hier die Versionen für x86 (nim-1.2.0_x32.zip, mingw32.7z) verwende, dann kann ich die dll mit deinen Parametern zwar erstellen, ohne dass gemeckert wird, aber es funktioniert dann trotzdem nicht in AutoIt, wenn #AutoIt3Wrapper_UseX64=n.

    • Offizieller Beitrag

    Wenn ich von hier die Versionen für x86 (nim-1.2.0_x32.zip, mingw32.7z) verwende, dann kann ich die dll mit deinen Parametern zwar erstellen, ohne dass gemeckert wird, aber es funktioniert dann trotzdem nicht in AutoIt, wenn #AutoIt3Wrapper_UseX64=n.

    Ja, ich hatte dazu in der VM nim und mingw schon als 32bit installiert um so eine eigene Umgebung zu haben. Da funktioniert auch das Kompilieren, aber die Dll ist nicht nutzbar (@error=1).

    Hinzu kommt das Problem des automatisch erstellten Funktions-Namens-Suffix (@8).

    • Offizieller Beitrag

    Ich hab's geschafft, eine 32Bit-Dll zu erstellen und mit AutoIt nutzen zu können. Und zwar habe ich die 32Bit-Version und die 64Bit-Version von mingw gemäß dieser Anleitung installiert: https://github.com/khchen/winim (ganz unten bei: Cross Compile)

    Hinweis: <USER> mit eurem Usernamen ersetzen!

    Bei mir liegen jetzt also im Verzeichnis c:\Users\<USER>\.choosenim\toolchains\nim-1.2.0\dist\ zusätzlich zum "nimble"-Ordner, die beiden Ordner "mingw64" und "mingw32".

    Dann im Verzeichnis c:\Users\<USER>\.choosenim\toolchains\nim-1.2.0\config\ die Datei "nim.cfg" ändern. Ab Zeile 162 muss da jetzt folgendes stehen:

    Und dann den Compiler mit dieser Zeile starten: nim c -d:release --cpu:i386 -o:math32.dll program.nim

    Ja, ganz wichtig, ohne "--app:lib"!

    "program.nim" ist die von BugFix erstellte Nim-Dll:

    So wurde die Dll zumindest schonmal in AutoIt erfolgreich geladen.

    Im Hex-Editor habe ich dann die "falschen" Funktionsnamen gesehen (wie BugFix schon schrieb). Also habe ich in AutoIt die Funktionen auch mit diesen "falschen" Namen aufgerufen und das funktionierte dann.

  • Bei mir funktioniert es nun auch... nur sehr seltsam, dass es mit --app:lib nicht funktioniert.

    Hier hin habe ich die Archive mingw32.7z und mingw64.7z entpackt:

    c:\Users\<USER>\scoop\apps\nim\current\dist\

    mingw32 

    mingw64 

    nimble

    Hier die nim.cfg geändert:

  • Ich habe jetzt mal gesucht, Ursache ist der Linker, der hier die Namen vergibt. Aber ich habe noch keine Möglichkeit gefunden das zu ändern.

    Ich habe mich mal wieder mit dem Thema beschäftigt.

    Die Namenskonvention sieht vor, dass standardmäßig als Suffix "@" und die Größe der übergeben Parameter an den Funktionsnamen angehängt wird. In C/C++ kann man das dann mit einem .DEF -File umrouten auf den gewünschten Exportnamen. Bei den Nim Pragmas habe ich da aber keine Einstellung für gefunden.

    Also bin ich mal von der anderen Seite rangegangen: Automatische Namenskonvertierung beim Aufruf.

    Dazu wird die Dll-Funktion mit dem intern verwendeten Namen aufgerufen. Bei x64 ist alles schick. Bei x86 bekomme ich den Fehler "Dll Funktion nicht gefunden". Dann frage ich die Größe der übergebenen Parameter ab und bilde somit den Suffix für den Funktionsnamen und rufe diese erneut auf.

    Aufruf, Parameterreihenfolge und Return sind an der Original DllCall-Funktion orientiert. Unterschied: Bei einem Fehler gebe ich als Returnwert "Null" zurück.

    Die Funktion kann 6 Parameter übernehmen. Kann man bei Bedarf auch anpassen.