Crash when binaries from binary wheels are used #150
Comments
|
One option could be to skip the |
|
I've run into the same problem - sharing my experience in case someone turns up here via Google. Ultimately, after spending a lot of time mucking about with this trying to come up with a better way, I wound up using pip's --no-binary :all: option. I didn't want to disable dh_shlib/dh_shlibdeps selectively. I'm sure there's a way to use devpi with only locally built wheels (so they don't have to be compiled each time), but I ran out of time. My debian/rules now looks more or less like this: Edit: Also see this issue: |
|
You can likely shorten that to |
We want, and need, to rebuild everything from source, without using
pre-built wheels.
One reason is that it's just the right thing to do, but it's especially
pressing because the build actually fails with wheel, as described here:
spotify/dh-virtualenv#150
The solution would be to pass the --no-binary=:all: option to pip,
except it appeared in pip 7.0.0, and we're stuck on a much older one.
Fortunately, theold version had --no-use-wheel which does the same.
This commit bumps the dh-virtualenv dependency to 0.10 (only in the
Jessie backports), so we can use its --pip-extra-args option to tell pip
not to use wheels.
Relates to #408
|
Since there is probably not much we can do here for dh-virtualenv, I'll close the issue. Feel free to reopen if you disagree! |
…cts fails without this "fix". Also relevant, spotify/dh-virtualenv#150 and numpy/numpy#7570.
|
I have a slightly better solution to this enabled by the recently added The problem here is manylinux wheels. You can conveniently disable them by installing https://github.com/asottile/no-manylinux1 This can be done with |
|
I should clarify. This allows you to avoid the problematic wheels while still enabling pure python wheels |
|
I'm getting an error when trying to build matplotlib, the solutions above didn't solve the problem.
|
|
Appending stuff to closed tickets is not a good idea. And likely you'd be better off to actually use wheels and then prevent dh_strip from choking on them. Make sure you actually have the build deps when using --no-binary, i.e. try his manually in a virtualenv and check the output. |
|
Just for reference, the on-going discussion on this is #203 and the best solution (until that |
On 2016-04-13 a big project to build binary wheels of everything for Linux on https://pypi.python.org was started.
See for instance: https://pypi.python.org/pypi/numpy
This is great. It should cut down build time, probably produce more stable and better optimize builds in general.
However this can lead to build failures on a normal dh_virtualenv build started like this:
First it can crash on dh_strip:
Probably because the binutils package I have on Ubuntu 14.04 is different from the one used to build the binary package. Maybe some other reason as well.
If you manually exclude stripping those libraries with:
it will then fail in dh_shlipdeps:
which is probably only a problem finding internal libraries.
You can again work around by excluding:
I am not sure however if it is possible for dh_virtualenv to figure this out automatically.
The text was updated successfully, but these errors were encountered: