whipper-team / whipper

Python CD-DA ripper preferring accuracy over speed
GNU General Public License v3.0
1.15k stars 91 forks source link

ImportError: libcdio.so.16: cannot open shared object file: No such file or directory #229

Closed Matt07211 closed 6 years ago

Matt07211 commented 6 years ago
$ whipper cd rip -p -U --track-template='%A/(%y) %d/%t. %n' --disc-template='%A/(%y) %d/%A - %d'
Traceback (most recent call last):
  File "/usr/bin/whipper", line 11, in <module>
    load_entry_point('whipper==0.6.0', 'console_scripts', 'whipper')()
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 572, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2755, in load_entry_point
    return ep.load()
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2408, in load
    return self.resolve()
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2414, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python2.7/site-packages/whipper-0.6.0-py2.7.egg/whipper/command/main.py", line 11, in <module>
    from whipper.command import cd, offset, drive, image, accurip, debug
  File "/usr/lib/python2.7/site-packages/whipper-0.6.0-py2.7.egg/whipper/command/cd.py", line 22, in <module>
    import cdio
  File "/usr/lib/python2.7/site-packages/cdio.py", line 20, in <module>
    import pycdio
  File "/usr/lib/python2.7/site-packages/pycdio.py", line 25, in <module>
    _pycdio = swig_import_helper()
  File "/usr/lib/python2.7/site-packages/pycdio.py", line 24, in swig_import_helper
    return importlib.import_module('_pycdio')
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
ImportError: libcdio.so.16: cannot open shared object file: No such file or directory

Quick grep (find command was taking to long...) of /usr indicates that I do have the libcdio.so liibrary, but a newer version that what the program is looking for.

$ tree -f  /usr | grep libcdio.so
│   ├── /usr/lib64/libcdio.so -> libcdio.so.18.0.0
│   ├── /usr/lib64/libcdio.so.18 -> libcdio.so.18.0.0
│   ├── /usr/lib64/libcdio.so.18.0.0

OS: Solus Python 2.7.14

Matt07211 commented 6 years ago

A little digging, I figured out that pycdio didn't support the newer versions of libcdio by my system. I came to the conclusion from the following info.

I first symlinked the libcdio.so to libcdio.so.16 for testing sudo ln -s /usr/lib64/libcdio.so /usr/lib64/libcdio.so.16

I then re-ran whipper

$ whipper cd rip -p -U --track-template='%A/(%y) %d/%t. %n' --disc-template='%A/(%y) %d/%A - %d'
Traceback (most recent call last):
  File "/usr/bin/whipper", line 11, in <module>
    load_entry_point('whipper==0.6.0', 'console_scripts', 'whipper')()
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 572, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2755, in load_entry_point
    return ep.load()
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2408, in load
    return self.resolve()
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2414, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python2.7/site-packages/whipper-0.6.0-py2.7.egg/whipper/command/main.py", line 11, in <module>
    from whipper.command import cd, offset, drive, image, accurip, debug
  File "/usr/lib/python2.7/site-packages/whipper-0.6.0-py2.7.egg/whipper/command/cd.py", line 22, in <module>
    import cdio
  File "/usr/lib/python2.7/site-packages/cdio.py", line 20, in <module>
    import pycdio
  File "/usr/lib/python2.7/site-packages/pycdio.py", line 25, in <module>
    _pycdio = swig_import_helper()
  File "/usr/lib/python2.7/site-packages/pycdio.py", line 24, in swig_import_helper
    return importlib.import_module('_pycdio')
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
ImportError: /usr/lib64/libcdio.so.16: version `CDIO_16' not found (required by /usr/lib/python2.7/site-packages/_pycdio.so)

I noticed the pycdio expected and tried to verify the version of libcdio, and since the above test failed I removed the symlink and updated pycdio to the newest version (2.0, but the README suggests 0.20...)

Collecting pycdio
  Downloading pycdio-2.0.0.tar.gz (242kB)
    100% |████████████████████████████████| 245kB 39kB/s 
Installing collected packages: pycdio
  Found existing installation: pycdio 0.20
    Uninstalling pycdio-0.20:
      Successfully uninstalled pycdio-0.20
  Running setup.py install for pycdio ... done
Successfully installed pycdio-2.0.0

I have now re-run the whipper command and all seems good so far (disc is currently ripping).

MerlijnWajer commented 6 years ago

OK. We should check if the API changes for the newer pycdio. If so, we can support both for a while, but suggest the newer package. (Let's not jump now, since that might bite distros)

MerlijnWajer commented 6 years ago

Please let us know of the outcome of that rip.

Matt07211 commented 6 years ago

Everything looks like it should, ripped fine, no errors have showed up, I've been ripping a few discs since that last comment from me and nothing has exploded.

As for pycdio, https://git.savannah.gnu.org/cgit/libcdio/pycdio.git/ , this info may be of relavence

2018-01-25  rocky <rocky@gnu.org>

    * .gitignore, README.txt, __pkginfo__.py,
    admin-tools/how-to-make-a-release.md, cdio.py, setup.py,
    swig/device.swg, swig/device_const.swg, swig/pyiso9660.i,
    test/test-cdio.py: Ready for Release 2.0.0 * Update API to 2.0.0. Assume version 2.0.0 or greater of libcdio.  * remove old compatibilty code.  * Update usual Python administrivia and package info.
calumchisholm commented 6 years ago

The Travis builds are currently broken, and this version bump seems a likely suspect.

First breakage: https://travis-ci.org/JoeLametta/whipper/jobs/338013828

Matt07211 commented 6 years ago

So if libcdio >= 18 use pycdio 2.00 Else libcdio <18 use pycdio 0.20, correct?

So what's the correct way of handling this moving forward, just documenting it in the readme?

adrienbeau commented 6 years ago

This is already documented in the README:

to avoid bugs please use pycdio 0.20 & libcdio >= 0.90 or, with previous libcdio versions, pycdio 0.17

This was added more than a year ago, maybe updated version information needs to be put there. (Though be careful when you talk about "libcdio >= 18", because I think you are talking about the soname version number, which is not at all the same as the libcdio project version number.)

Matt07211 commented 6 years ago

Yea, I probably was using soname but it definitely seemed to correlate to the actual software version so...

Either way, the readme does need to be update to make mention that newer versions of libcdio wont work nicely with the 0.20 version of pycdio.

JoeLametta commented 6 years ago

OK. We should check if the API changes for the newer pycdio.

It does but I'm not sure we're affected (a section of libcdio's NEWS file):

2017-12-31 version 2.0.0

This release bumps library version numbers and bumps the
major release number. We should have gone from 1.0.0 to 2.0.0
in the last release since there is an API incompatability.

In addition...

- Add NetBSD drive detection; correct drive detection in cd-info.c
  Patches from Onno van der Linden
- Fix some MinGW and Windows portability issues
- Remove some memory leaks in some tests
- Lint (a little) with clang static analyzer

There are some programs and bindings that will need to be updated
if you want to use them with this library. Specifically:

- Device::Cdio (2.0.0 or greater)
- vcdimager (2.0.0 or greater)
- pycdio (2.0.0 or greater)
- rbcdio (2.0.0 or greater)

2017-12-10 version 1.1.0 Dr. Gecko

Caveats:
pycdio and Deveice::Perl will be broken but that'll be fixed later

- Remove many remaining memory leaks, invalid
  reads, writes (as per valgrind) in library,
  test and demo code
- Types CdioISO9660{Dir,File}List_t,  have been added
  and iso9660_{dir,file}list_{new,free} have been added.
- cdio_list_free() now takes an additional parameter: a function to
  free list items. This is not compatible with 1.0.0

More work is needed on MacOS and other OS's where I don't have
valgrind accessible.

AIX is left untouched - that is probably heading for removal in the
future.

2017-11-21 version 1.0.0 Thanksgiving

This is an API breaking change

- Remove deprecated items:
   * OS/2 driver (never really was supported)
   * BSDI driver remnants
   * mmc_isrc_track_read_subchannel
   * CDIO_MIN_DRIVER, CDIO_MIN_DEVICE_DRIVER, CDIO_MAX_DRIVER, CDIO_MAX_DEVICE_DRIVER
   * CdioList, CdioListNode
- Apple Darwin OS X -> macOS
- Subdir objects breaks symbol versioning. See https://savannah.gnu.org/bugs/?49907
- Handle bad iso 9660 better. Fixes Savannah bug https://savannah.gnu.org/bugs/?52091
- Apple (High) Sierra compatiablity
- NetBSD patches
- Fixes for Rock Ridge SUSP (Thomas Schmitt)
- Reduce MinGW compilation warnings
- Add asserts to test memory allocations and misc bug fixes (Pete Batard)
- Enable CD drivers on current and future versions of FreeBSD and macOS,
  so we do not have to add every new OS version explicitly. (Robert Kausch)
- Cross-compiling friendliness (Ozkan Sezer)
- Small texinfo doc fixes (Wieland Hoffmann)
- Simplify making doc from autogen.sh
- Bug fix for https://savannah.gnu.org/bugs/?45015 (Thomas Schmitt)
- Bug fixes for #45017,#52265, and #52264
- Add more compiler warning flags, i.e. -Wshadow, -Wundef, ...
- Reduce numerous memory leaks (more though remain)

libcdio-paranoia's last release seems to be still based upon libcdio 0.94.