While using os.popen() from unix-ffi libraries on FreeBSD 14.1-RELEASE-p5 amd64, I encountered this error:
...
File "os/__init__.py", line 32, in <module>
File "ffilib.py", line 43, in libc
File "ffilib.py", line 39, in open
File "ffilib.py", line 33, in open
OSError: [Errno 2] ENOENT
On further investigation, I found that libc major version has been upgraded to 7, and ffilib.py is only looking for versions up to 6.
$ ls /lib/libc.so*
/lib/libc.so.7
https://github.com/micropython/micropython-lib/blob/e4cf09527bce7569f5db742cf6ae9db68d50c6a9/unix-ffi/ffilib/ffilib.py#L42
Changing the 6 to 7 fixed the issue.
Only making a note here since the readme for unix-ffi says: "This directory is unmaintained." and I would like to have a reference come up in searches when someone encounters the error.
Building fails for the unix port when adding the glob package to the variant manifest with:
require("glob", unix_ffi=True)
glob's manifest requires os-path, without unix_ffi, and that in turns requires os also without unix_ffi:
require("os", unix_ffi=True)
require("os-path")
os-path's manifest requires os:
require("os")
package("os")
This causes a conflict with the os that has already been required with unix_ffi:
build-standard/frozen_content.c:20526:27: error: redefinition of ‘const_qstr_table_data_os___init__’
20526 | static const qstr_short_t const_qstr_table_data_os___init__[158] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
build-standard/frozen_content.c:17919:27: note: previous definition of ‘const_qstr_table_data_os___init__’ was here
17919 | static const qstr_short_t const_qstr_table_data_os___init__[158] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
....
If I add unix_ffi=True to lib/micropython-lib/python-stdlib/os-path/manifest.py, then it is able to compile the frozen content.
If I add
unix_ffi=Truetolib/micropython-lib/python-stdlib/os-path/manifest.py, then it is able to compile the frozen content.
I don't think that's the correct solution because it will most likely break targets (eg bare-metal ports) that can't use the unix-ffi code.
One solution would be to make it ignore subsequent packages if one is already require'd by the same name. So in this case the unix_ffi os will take precedence because it's require'd first.
Should be fixed by https://github.com/micropython/micropython/pull/13620
Indeed (as this also applies to 15.0-RELEASE). That's also something that needs to be changed in MicroPython's own test suite, along with other minor things like moving part of the default sys.path from
/usr/lib/micropythonto/usr/local/lib/micropython, and recognising FreeBSD as its own thing rather than classify that as Linux.I believe some of these changes are already part of the patches in the ports tree, but last time I checked they still package a relatively old version. It won't hurt to have them in the source tree themselves.
This is fixed in
_libcbut still needs to be fixed inffilib.Right! I can fix that right now but then I'd have to fix it again if https://github.com/micropython/micropython/pull/18979 gets merged. In ffilib there's a check for
sys.platformand that PR will make it returnfreebsd, invalidating any small-scale change I'd make. I can also make it look for eitherlinuxorfreebsdfor the lookup to occur but then it'll take up bytes for nothing if that PR won't make the cut.I don't mind submitting multiple PRs over time, but maybe you may want to schedule the changes differently.
Yes, I see that now.
We are on the cusp of a release so can't make big changes. I think all this can be postponed until after the release.