Hallo,
ich habe ein Verzeichnis in dem sich eine Herader-Datei "Common.h" und dei zugehörige "Common.c" befinden.
Meine Setup-Scripte befinden sich in anderen Verzeichenissen.
Wenn ich jetzt in der Header Datei "#include Common.c" schreibe läuft alles sauber durch,
lasse ich das weg bekommme zu den in "Common.c" definierten Funktionen "undefined references".
was fehlt nir um nur mit einem "#include Common.h" in den Sourcen der Extensions die Funktionen nutzen zu können?
Danke
undefined reference fehler
@hypnoticum: Dazu müsstest Du dem Compiler mitteilen wo er die Include-Datei finden kann, falls er das nicht tut. Du schreibst ja leider nicht wo das Problem liegt, also was genau passiert wenn Du die ``Common.h`` inkludierst. Oder kommt der Fehler erst beim Linken? Da muss natürlich auch die ``Common.o`` mit eingebunden werden, die aus der ``Common.c`` übersetzt wurde.
-
- User
- Beiträge: 132
- Registriert: Dienstag 15. März 2011, 15:43
@BlackJack:
Ja ich denke der Fehler tritt erst beim linken auf, denn die Fehlermeldung erwähnt auch die Object -Dateien.
running install
...
writing build\temp.win32-2.6\Release\c\Ext.def
C:\Program Files\pythonxy\mingw\bin\dllwrap.exe -mno-cygwin -mdll -static --entry _DllMain@12 --output-lib build\temp.win32-2.6\Release\c\libExt.a --def build\temp.win32-2.6\Release\c\Ext.def -s build\temp.win32-2.6\Release\c\gsm.o "-LC:/Program Files/IVI Foundation/VISA/WinNT/lib/msc" -LC:\Python26\libs -LC:\Python26\PCbuild -lvisa32 ... -lpython26 -lmsvcr90 -o H:\...\Ext.pyd
build\temp.win32-2.6\Release\c\gsm.o:GSM.c:(.text+0x79): undefined reference to `MsgDia'
(Ich habe teilweise Zeilen, Pfade und dateien durch "..." ersetzt)
aber wie weise ich den Kompiler an die "Common.c" mit zu übersetzen?
Wenn ich "sources = ['H:\...\Common.c'] schreibe, ändert sich nichts.
Ja ich denke der Fehler tritt erst beim linken auf, denn die Fehlermeldung erwähnt auch die Object -Dateien.
running install
...
writing build\temp.win32-2.6\Release\c\Ext.def
C:\Program Files\pythonxy\mingw\bin\dllwrap.exe -mno-cygwin -mdll -static --entry _DllMain@12 --output-lib build\temp.win32-2.6\Release\c\libExt.a --def build\temp.win32-2.6\Release\c\Ext.def -s build\temp.win32-2.6\Release\c\gsm.o "-LC:/Program Files/IVI Foundation/VISA/WinNT/lib/msc" -LC:\Python26\libs -LC:\Python26\PCbuild -lvisa32 ... -lpython26 -lmsvcr90 -o H:\...\Ext.pyd
build\temp.win32-2.6\Release\c\gsm.o:GSM.c:(.text+0x79): undefined reference to `MsgDia'
(Ich habe teilweise Zeilen, Pfade und dateien durch "..." ersetzt)
aber wie weise ich den Kompiler an die "Common.c" mit zu übersetzen?
Wenn ich "sources = ['H:\...\Common.c'] schreibe, ändert sich nichts.
Wo ist denn MsgDia definiert?
Oh, und wenn du schreibst du setzt Pfade auf
H:\foo\bar
dann wird mir schon wieder schummerig - dir ist schon bekannt, dass der backslash in Python ein escape-character ist, und du den in Pfaden wahlweise doppelt setzen musst, oder raw-strings verwenden, oder gleich darauf verzichten & forward-slashes benutzen?
Oh, und wenn du schreibst du setzt Pfade auf
H:\foo\bar
dann wird mir schon wieder schummerig - dir ist schon bekannt, dass der backslash in Python ein escape-character ist, und du den in Pfaden wahlweise doppelt setzen musst, oder raw-strings verwenden, oder gleich darauf verzichten & forward-slashes benutzen?
-
- User
- Beiträge: 132
- Registriert: Dienstag 15. März 2011, 15:43
@Blackjack:
"MsgDia" ist in "Common.c" definiert. Die Backslashes sind im Orginalcode nach vorn gekippt und nur beim nachträgl. Bearbeiten des Pfades enstanden - sorry wenn dir jetzt schummrig ist
"MsgDia" ist in "Common.c" definiert. Die Backslashes sind im Orginalcode nach vorn gekippt und nur beim nachträgl. Bearbeiten des Pfades enstanden - sorry wenn dir jetzt schummrig ist
Dann scheint Common.o nicht mit verlinkt zu werden. Woher kommt denn das gsm.c?
Und ich bin nicht BlackJack, ob dem schummerig ist kann ich nicht beurteilen...
Und ich bin nicht BlackJack, ob dem schummerig ist kann ich nicht beurteilen...
-
- User
- Beiträge: 132
- Registriert: Dienstag 15. März 2011, 15:43
Da hab ich schon wieder nicht aufgepasst. Entschuldigung deets.
Die Dateien "Common.h" und "Common.c" sind im Package "Device".
Das Package "Device" enthält das Package "CMU".
In "CMU" gibt es ein Verzeichnis "C", das "GSM.c" beinhaltet.
Die Dateien "Common.h" und "Common.c" sind im Package "Device".
Das Package "Device" enthält das Package "CMU".
In "CMU" gibt es ein Verzeichnis "C", das "GSM.c" beinhaltet.
Code: Alles auswählen
import shutil
import sys
import os
from distutils.core import setup, Extension
sys.argv.append('install')
modul = Extension('Ext',
sources = ['C/GSM.c'],
depends = ['Common.h'],
include_dirs = ['H:/Python/Projects/Py_Workspace/PyAT/src/Device/C',
'C:/Program Files/IVI Foundation/VISA/WinNT/include',
'C:/Python26/include'],
library_dirs = ['C:/Program Files/IVI Foundation/VISA/WinNT/lib/msc'],
libraries = ['visa32', 'rscmu200', 'rscmuk6w', 'rscmuk2g'])
if os.path.isdir(os.getcwd() + '/build'):
try:
shutil.rmtree('build')
except:
print 'cant remove directory "build"'
try:
os.mkdir('build')
os.mkdir('build/lib.win32-2.6')
except:
print 'cant make directory "build/lib.win32-2.6"'
setup(
name = "GSM",
version = "1.0",
description = "C-Extensions for CMU-GSM-Modul",
ext_package = os.getcwd(),
ext_modules = [modul]
)
@hypnoticum: Damit die ``Common.c`` übersetzt und gelinkt wird, müsste sie doch eigentlich auch in `sources` auftauchen, oder? Sonst weiss das Installationsskript doch gar nichts von deren Existenz.
-
- User
- Beiträge: 132
- Registriert: Dienstag 15. März 2011, 15:43
ja, dass war was ich anfangs versucht hatte.
Im Moment habe ich einen anderen Fehler, weshalb ich das z.Zt. nicht mehr überprüfen kann:
... /Device/C/Common.C:1: error: expected constructor, destructor, or type conversion before '*' token
Zeile 1 von "Common.c": PyObject* MsgDia(void){ ...
(wahrscheinlich liegt es an der Python.h, die zu spät inkludiert wird)
eben hat es aber leider nicht gereicht ...
Im Moment habe ich einen anderen Fehler, weshalb ich das z.Zt. nicht mehr überprüfen kann:
... /Device/C/Common.C:1: error: expected constructor, destructor, or type conversion before '*' token
Zeile 1 von "Common.c": PyObject* MsgDia(void){ ...
(wahrscheinlich liegt es an der Python.h, die zu spät inkludiert wird)
eben hat es aber leider nicht gereicht ...
Na, du bist ja witzig. Ein Fehler beim kompilieren dadurch loesen, dass man *nicht* kompiliert, und sich dann wundern, warum's linken nicht geht?
Und der Fehler sieht etwas sehr seltsam aus, eine Funktionsdefinition in der ersten Zeile eines Stueckes C, mit PyObject* in der Signatur - da fehlt ja *mindestens* mal ein
#include "Python.h"
oder nicht?
Und der Fehler sieht etwas sehr seltsam aus, eine Funktionsdefinition in der ersten Zeile eines Stueckes C, mit PyObject* in der Signatur - da fehlt ja *mindestens* mal ein
#include "Python.h"
oder nicht?
-
- User
- Beiträge: 132
- Registriert: Dienstag 15. März 2011, 15:43
wenn das mal alles so einfach gewesen wäre.
Jedenfalls klappt es jetzt.
Ich habe nicht erkannt, dass ich Header-Dateien auch mehrfach inkludieren muss, wenn ich mehrere Sourcen kompiliere.
ich wusste nicht, wo der Fehler lag. Ich hatte mich nicht gewundert warum es beim linken nicht ging. Aber ich wusste nicht wo mein Fehler war.
Jedenfalls klappt es jetzt.
Ich habe nicht erkannt, dass ich Header-Dateien auch mehrfach inkludieren muss, wenn ich mehrere Sourcen kompiliere.
ich wusste nicht, wo der Fehler lag. Ich hatte mich nicht gewundert warum es beim linken nicht ging. Aber ich wusste nicht wo mein Fehler war.
Und da es eine ``Common.h`` gibt, sollte man die an der Stelle auch inkludieren. Mindestens mal, damit Redeklarationen mit anderer Signatur schon beim Übersetzen auffallen. Und wahrscheinlich wird auch dort ein Inkludieren der ``Python.h`` nötig sein. Dann braucht man das nicht mehr in der ``Common.c`` zu machen.
Im Sinne einer Vermeidung von kuenftigen Fehlern:
http://www.learncpp.com/cpp-tutorial/19-header-files/
http://www.learncpp.com/cpp-tutorial/11 ... processor/
Solltest du mal lesen, und vor allem im zweiten Link das Thema "header guards". Ich vermute mal stark, dein Common.h hat sowas nicht, oder?
http://www.learncpp.com/cpp-tutorial/19-header-files/
http://www.learncpp.com/cpp-tutorial/11 ... processor/
Solltest du mal lesen, und vor allem im zweiten Link das Thema "header guards". Ich vermute mal stark, dein Common.h hat sowas nicht, oder?
-
- User
- Beiträge: 132
- Registriert: Dienstag 15. März 2011, 15:43
@deets:
danke. header guards hatte ich schon verwendet.
danke. header guards hatte ich schon verwendet.
Hey! Das ist eine Super Tutorial-Seite! Werde ich mir mal abspeichern und bei Bedarf aufrufendeets hat geschrieben:Im Sinne einer Vermeidung von kuenftigen Fehlern:
http://www.learncpp.com/cpp-tutorial/19-header-files/
http://www.learncpp.com/cpp-tutorial/11 ... processor/
Solltest du mal lesen, und vor allem im zweiten Link das Thema "header guards". Ich vermute mal stark, dein Common.h hat sowas nicht, oder?