Seite 1 von 2
Verfasst: Sonntag 26. November 2006, 17:03
von BlackJack
``PASCAL``!? Das ``FAR`` könnte ich ja noch verstehen wenn der OpenWatcom sonst 16-Bit-Code generiert, aber der Unterschied zwischen Aufrufen in Pascal und C ist doch die Reihenfolge in der die Argumente auf dem Stack abgelegt werden und wer für's Aufräumen des Stacks zuständig ist. Und da dachte ich das DLLs der C-Konvention folgen!?
Verfasst: Sonntag 26. November 2006, 19:17
von HWK
Das FAR kann man wirklich bei der 32-Bit-Code-Voreinstellung weglassen. Wenn ich aber statt PASCAL gar nichts oder CDECL angebe, wird die Funktion fib unter dem Namen fib_ oder _fib exportiert, was natürlich unschön ist. Wenn ich PASCAL angebe, muss ich entsprechend in ctypes auch WinDLL verwenden.
MfG
HWK
Verfasst: Sonntag 26. November 2006, 19:57
von BlackJack
Wo kommt der Unterstrich denn her? Und warum? Kann das am ``__extern`` liegen? Was macht das denn? Normalerweise wird bei C doch jede Funktion die nicht ``static`` deklariert wurde auch automatisch unter ihrem Namen wie er im Quelltext steht in der object-Datei verfügbar gemacht. So kenne ich das jedenfalls von allen C-Compilern mit denen ich bis jetzt zu tun hatte.
Verfasst: Sonntag 26. November 2006, 20:25
von HWK
Weiss ich auch nicht genau. Auf jeden Fall sind __export (nicht __extern) oder __declspec(dllexport) notwendig, damit etwas aus der DLL exportiert wird. Dies ist auch bei Visual-C der Fall. Möglicherweise sind es C-Konventionen unter Windows, dass eine exportierte Funktion mit einem Unterstrich beginnt oder endet, denn bei PASCAL passiert dies ja nicht. Deshalb sollte es am __export nicht liegen.
MfG
HWK
Verfasst: Sonntag 26. November 2006, 20:28
von sape
HWK hat geschrieben:Weiss ich auch nicht genau. Auf jeden Fall sind __export (nicht __extern) oder __declspec(dllexport) notwendig, damit etwas aus der DLL exportiert wird. Dies ist auch bei Visual-C der Fall. [...]
Full ack! Nicht nur bei VC sondern auch mit gcc unter Windows. Wie das unter Linux aussieht weiß ich auch nicht.
Verfasst: Freitag 19. März 2010, 22:20
von gfmwm
Ich grabe nur ungern Leichen aus, aber ich habe ein Problem mit ctypes.
Ich nutze Python 3.1 unter Win7 (64-bit). Ich erstelle folgendes Skript:
Code: Alles auswählen
import ctypes
f = ctypes.cdll.LoadLibrary("fib.dll")
print(f.fib(35))
Die fib.dll habe ich mit MinGW erstellt.
Unter Ubuntu läuft die Sache, nur unter Windows nicht. Ich erhalte immer folgende Fehlermeldung:
Traceback (most recent call last):
File "C:\...\ctypes.py", line 1, in <module>
import ctypes
File "C:\...\ctypes.py", line 2, in <module>
f = ctypes.cdll.LoadLibrary("fib.dll")
AttributeError: 'module' object has no attribute 'cdll'
Habe schon alles Mögliche probiert (z.B. Systempfade angepasst, Python neu installiert, etc.), leider ohne Erfolg.
Wenn ich allerdings im IDLE folgendes eingebe:
Code: Alles auswählen
>>> import ctypes
>>> print(ctypes.cdll)
<ctypes.LibraryLoader object at 0x027BDFB0>
Scheint es zu funktionieren!?!
Hat jemand eine Idee woran es liegen könnte?
Verfasst: Freitag 19. März 2010, 23:08
von BlackJack
@gfmwm: Du hast Dein Skript nicht zufällig `ctypes` genannt!?
Verfasst: Freitag 19. März 2010, 23:45
von gfmwm
@BlackJack
Doch das habe ich. Aber, wenn ich es als "test123.py" abspeichere, bekomme ich exakt dieselbe Fehlermeldung.
Verfasst: Freitag 19. März 2010, 23:54
von derdon
Dann lösche noch die Datei ctypes.pyc
Verfasst: Samstag 20. März 2010, 12:37
von gfmwm
Ok, das hat geklappt. Vielen, vielen Dank.
Hätte nie gedacht, dass es daran liegen könnte.
