cwiid.so import error about cwiid

[abstrakraft]

That's odd - cwiid_set_data as defined in libcwiid. What sort of error did you see before adding the last line?

[ibbo]

Without the last line I get:

import cwiid
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named cwiid

[mabrowning]

I also have the same problem as ibbo, same setup. I noticed that setup.py was not linking with libcwiid, and it was installing to site-packages instead of dist-packages, which on Karmic wasn't working. How should I post a patch?

Temporarily, the patch can be seen at http://www.pastebin.com/m6ba3fa7a

[ibbo]

Hi I applied the patch and this prevents me having to do the python installation manually. However I still get the original import error: "undefined symbol: cwiid_set_data".

Note: I've tested this on both my 64-bit and 32-bit machines and I get the same error on both.

[ibbo]

Further info, here's the output of 'ldd cwiid.so':
linux-gate.so.1 => (0x00f1a000)
libbluetooth.so.3 => /usr/lib/libbluetooth.so.3 (0x0039f000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x007ba000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x009c7000)
/lib/ld-linux.so.2 (0x00bbf000)

[ibbo]

and here's the output of 'nm cwiid.so': http://www.pastebin.com/f2bf75ab2

[ibbo]

Ok I've done a bit more detective work and I've narrowed down the source of the problem to this commit:
commit 6af6786
Author: L. Donnie Smith [email protected]
Date: Thu Feb 4 22:53:41 2010 -0500

fix link options for --as-needed (#90)

also fix a couple of includes

[ibbo]

Ok I've finally worked out what exactly is causing the problem, it is the change from #include "cwiid.so" to #include <cwiid.so> in Wiimote.c and cwiidmodule.c. If I change them back then it works.

[abstrakraft]

No, that would cause compilation issues, not dynamic linking issues.

The problem is that 'python setup.py build_ext' appears to only take the last -l argument rather than both, as is standard for -l options to gcc. Specifying the libraries in setup.py rather than on the command line (via the Makefile) fixes it. This change has been committed.

As far as site-packages vs dist-packages, I've never heard of dist-packages before this. If there is some standard environment variable, or other way of determining the proper directory, I'll be happy to use it, but if not, site-packages is the standard.

[ibbo]

I can confirm that the original problem is solved in the latest git version. As for the site-packages/dist-packages issue, you could run setup.py install without an explicit install-lib, which would use the default from setuptools, which is set to dist-packages in Ubuntu. This would of course make uninstalling more difficult, but you can find where a module is installed in

module.file

for example:

>>> import cwiid
>>> print cwiid.__file__
/usr/local/lib/python2.6/dist-packages/cwiid.so

[abstrakraft]

The problem there is that I've got to have some control over where the files are installed. I really need to be able to specify the top-level lib (e.g. /usr/local/lib) directory, but I don't think distutils has any way to do that - I can only specify the prefix (e.g. /usr/local) or the site/dist-packages level directory.

Rant Warning: I really don't understand why distros feel the need to muck around with standards like this. From what I can find online, the reason for dist-packages is to separate distro managed packages from user managed packages. However, there has been a solution to this problem for decades: the user owns everything in /usr/local, the distro owns everything in /usr outside of /usr/local. The fallout from Ubuntu's (or Debian's?) failure to follow these conventions is the breaking of packages like we're seeing here. Unless I'm convinced of a good reason for adopting this dist-packages nonsense (and I will listen to reason), this is will not be a priority for me. If Ubuntu users can put together a good patch that works everywhere with little maintenance, I have no problem committing it, but I refuse to convolute my build system because distro maintainers feel the need to stray from standards without reason.

I like your method of determining uninstall directory, but I think the correct thing to do is know which directory the package was installed to, and delete it only from there. This becomes an issue if you have two instances installed, e.g. user install, then distro install, then user uninstall.