-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Downloads fail on Windows with Python 2.7.13 #11540
Comments
Thanks for the report and detailed investigation. I hope it fixed upstream and filed http://bugs.python.org/issue29082 |
Here's a summary:
Here S and U indicate bytes and unicode objects, respectively. |
Fixed in CPython - https://hg.python.org/cpython/rev/4ce22d69e134 This issue can be closed if Python 2.7.14 is released, which is likely to happen in mid-2017. See https://www.python.org/dev/peps/pep-0373/. Before that please downgrade to 2.7.12. |
I can reproduce this TypeError with 2.7.12 too. I didn't completely clean the previous 2.7.13 installation (only uninstalled) before installing 2.7.12 so it might have been due to that. Why not just |
Works for me with 2.7.12:
Maybe. If that's really the case, Python's installer has bugs.
I seldom boot into Windows and don't have so much time on testing all Python versions before commiting changes. If you have a patch working for all Python versions, feel free to open a pull request. |
Reopening. That workaround can be removed as 2.7.14 released. |
Uh, where was it released? |
It's not released yet. I omit the verb "is". |
To wiiaboo and yan12125, thank you both for working on this. wiiaboo, thank you for submitting the workaround I originally suggested. This bug report is my first effort on GitHub, and it is gratifying to see it working. I am not yet confident enough to fork and make a pull request. |
See, I don't even know what I'm doing when I "close" an issue! Sorry. |
Please follow the guide below
x
into all the boxes [ ] relevant to your issue (like that [x])Make sure you are using the latest version: run
youtube-dl --version
and ensure your version is 2016.12.22. If it's not read this FAQ entry and update. Issues with outdated version will be rejected.Before submitting an issue make sure you have:
What is the purpose of your issue?
The following sections concretize particular purposed issues, you can erase any section (the contents between triple ---) not applicable to your issue
If the purpose of this issue is a bug report, site support request or you are not completely sure provide the full verbose output as follows:
Add
-v
flag to your command line you run youtube-dl with, copy the whole output and insert it here. It should look similar to one below (replace it with your log inserted between triple ```):(Note this fails before any [debug] output)
If the purpose of this issue is a site support request please provide all kinds of example URLs support for which should be included (replace following example URLs by yours):
Description of your issue, suggested solution and other information
In Python 2.7.13, the Windows version of LoadLibrary requires a string, not a unicode arg. This is due to a change in Python-2.7.12\Modules_ctypes\callproc.c vs. Python-2.7.13\Modules_ctypes\callproc.c:
In:
static PyObject *load_library(PyObject *self, PyObject *args)
there is this change (from 2.7.12 to 2.7.13):
1280c1284
< if (!PyArg_ParseTuple(args, "O|O:LoadLibrary", &nameobj, &ignored))
---
> if (!PyArg_ParseTuple(args, "S|O:LoadLibrary", &nameobj, &ignored))
I was going to propose just changing:
libc = ctypes.cdll.LoadLibrary('libc.so.6')
to:
libc = ctypes.cdll.LoadLibrary(b'libc.so.6')
in utils.py, which does fix the TypeError, but I find that this TypeError does not occur under Python 3.6.0, apparently because callproc.c in 3.6.0 does not have the change shown above. Since this call to LoadLibrary() should fail under Windows anyway, maybe the correct fix is to have setproctitle() in utils.py just return if the LoadLibrary() raises either TypeError or OSError.
Is is correct under either Python 2 or 3 to pass a unicode string to LoadLibrary() in either Windows or Posix? Should b'libc.so.6' be used in all cases (Windows, Posix/Linux, Python 2 or 3)? I note that in Linux (Posix) environment, the LoadLibrary() call goes to py_dl_open() instead of load_library(), and it also does not have the "S" typecheck in 2.7.13 or in 3.6.0.
The text was updated successfully, but these errors were encountered: