ch424 wrote: [snip] > However, when I open up the python command line, and type "from gpib > import *" or "import gpib" I get "ImportError: /usr/.../gpibmodule.so: > undefined symbol: ibdev" -- but I know it's defined in the ni488.h > file, especially as I can use this code from actual C programs without > problems. The ni488.h file in in the right place to be used for C > compilation. > > So, the question is, what did I type wrong? Why is python examining > that c function embedded in another, surely it should only be > interested in providing arguments and getting returned values, and what > the c function does is its own bussiness? >
Daniel has already given you what to do to get over your immediate problem. I'd just like to add a couple of mindset adjustments to get you over the next few stiles. The message ".... gpibmodule.so: undefined symbol: ibdev" is being reported by Python, but this problem is detected by an operating-system specific loader. What it is trying to tell you is that gpibmodule.so contains a call to a function named ibdev, but the loader can't find ibdev. This is nothing to do with extending Python; if you had written a stand-alone program in C, and made the same mistake [not providing the name of the library containing ibdev], you would have got a similar message either from the linker or later from the loader. Neither Python nor the loader is "examining" ibdev, the loader can't even find it, and Python has no way of knowing that it exists (and doesn't and shouldn't care) even if the loader could find it! It is the job of *your* code to interface with the ibdev routine. Another slant on all this: the problem doesn't exist on the boundary between Python and your extension module; it exists on the boundary between your module and a 3rd party function called by your module. HTH, John -- http://mail.python.org/mailman/listinfo/python-list
