pfalcon/esp-open-sdk

error: too few arguments to function '_PyImport_FixupBuiltin'

DanielMazurkiewicz opened this issue ยท 13 comments

Was redirected here from: SmingHub/Sming#1432
Do you have any ideas what might be causing such an issues? (or how to solve them?)

I too experienced this issue when building.

It is due to a gdb bug caused by the use of the internal-only API method _PyImport_FixupBuiltin. The signature of this method changed at some point in Python 3, leading to the issue.

The official bug report is here, the fix is here, and some additional discussion from the Python developers about the issue is here.

The issue was fixed in gdb-8.1.50.20180605-18.fc29.

Manually updating the python.c file per the patch resolves the issue.

Are you using pyenv?

I mitigated this issue by changing my global python version to micropython like so -
$ pyenv global micropython-1.9.4

export python=python2 is another workaround in case python points to python3 on your system.

Neither workaround worked for me (on Arch AMD64, where python does point to python3). After applying the patch (manually, since it didn't apply as-is) I get a different error:

[ERROR]    /home/rena/projects/esp8266/esp-open-sdk/crosstool-NG/.build/src/gdb-7.10/gdb/python/python.c:1748:35: error: 'PyInit__gdb' undeclared (first use in this function); did you mean 'PyInit__imp'?

Any solutions? export python=python2 didn't work for me, and I'm not using pyenv.

I fixed it on my machine (Arch linux) by temporarily changing my python symlink in /usr/bin to point to python2 instead of python3. So:

cd /usr/bin/
sudo ln -sf python2 python

After this you should be able to build esp-open-sdk without any trouble. When you're done building, you should reset the symlink back to its original state:

cd /usr/bin/
sudo ln -sf python3 python

That seems like a pretty intrusive change, using a cannon to kill a fly. I'd be worried something would break when I do that.

I did try alias python=python2 (instead of export) but it still gives the same error. I'm not sure how changing the python interpreter path will fix a compile error, anyway...

I'm also having this same issue. mvanaltvorst solution worked for me.

I fixed it on my machine (Arch linux) by temporarily changing my python symlink in /usr/bin to point to python2 instead of python3. So:

cd /usr/bin/
sudo ln -sf python2 python

After this you should be able to build esp-open-sdk without any trouble. When you're done building, you should reset the symlink back to its original state:

cd /usr/bin/
sudo ln -sf python3 python

Thanks, it worked for me!

I fixed it on my machine (Arch linux) by temporarily changing my python symlink in /usr/bin to point to python2 instead of python3. So:

cd /usr/bin/
sudo ln -sf python2 python

After this you should be able to build esp-open-sdk without any trouble. When you're done building, you should reset the symlink back to its original state:

cd /usr/bin/
sudo ln -sf python3 python

I know that it I'm coming a little bit late, but instead of messing around with system file, you can use the same idea with a "softer" way, create a temporary directory that will contain your link to python2.7 and add it at the beginning of your PATH variable.

mkdir /tmp/tmpbin && ln -s /usr/bin/python2.7 /tmp/tmpbin/python && export PATH=/tmp/tmpbin:${PATH}

bhase commented

I had also some problems with pyhton. I used the workaround for python2 as mentioned in #339 (comment)

After that I got another compilation error, which could be resolved by installing the python2-devel package (I use Fedora, in other distros this could be named slightly different). It seems that the development-dependency is not caught from the config script.

Ran into this problem on Manjaro. I applied the given patch (the line numbers have changed so much that patch can't find them, so I updated the patch, which you can find here https://pastebin.com/uLDBv1tr ) but then run into more errors:

[INFO ]  Installing cross-gdb
[ERROR]    /home/amr/workspace/ESP8266/esp-open-sdk/crosstool-NG/.build/src/gdb-7.10/gdb/guile/scm-ports.c:231:47: error: dereferencing pointer to incomplete type 'scm_t_port' {aka 'struct scm_t_port'}
[ERROR]    /home/amr/workspace/ESP8266/esp-open-sdk/crosstool-NG/.build/src/gdb-7.10/gdb/guile/scm-ports.c:681:19: error: 'SCM_PORT_NEITHER' undeclared (first use in this function); did you mean 'SCM_PORT_TYPE'?
[ERROR]    /home/amr/workspace/ESP8266/esp-open-sdk/crosstool-NG/.build/src/gdb-7.10/gdb/guile/scm-ports.c:711:19: error: 'SCM_PORT_NEITHER' undeclared (first use in this function); did you mean 'SCM_PORT_TYPE'?
[ERROR]    /home/amr/workspace/ESP8266/esp-open-sdk/crosstool-NG/.build/src/gdb-7.10/gdb/guile/scm-ports.c:790:24: error: 'SCM_PORT_WRITE' undeclared (first use in this function); did you mean 'SCM_PORT_TYPE'?
[ERROR]    /home/amr/workspace/ESP8266/esp-open-sdk/crosstool-NG/.build/src/gdb-7.10/gdb/guile/scm-ports.c:816:29: error: 'SCM_PORT_READ' undeclared (first use in this function); did you mean 'SCM_PORT_TYPE'?
[ERROR]    make[5]: *** [Makefile:2469: scm-ports.o] Error 1
[ERROR]    make[4]: *** [Makefile:8755: all-gdb] Error 2
[ERROR]    make[3]: *** [Makefile:845: all] Error 2

I guess I will just try doing the symlink change, but it would be nice if this could build using Python 3.8. Though this second error seems possibly unrelated.

I was able to fix this as canardos suggested above. You can find a patch that should apply cleanly here:

https://github.com/ChrisMacGregor/esp-open-sdk/blob/builds-on-Ubuntu-21.10/1000-fix-build-python3.9.patch

Note also that I subsequently ran into a couple of other issues that needed patches. The end result (which gets me a clean build on Ubuntu 21.10 of an apparently working toolchain) can be found here:

#391
https://github.com/ChrisMacGregor/esp-open-sdk/tree/builds-on-Ubuntu-21.10
Tarball of built toolchain: https://github.com/ChrisMacGregor/esp-open-sdk/releases/tag/builds-on-Ubuntu-21.10