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
Port Python to 3DS: micro kernel, homebrew, newlib (Missing guards for some POSIX functions) #66813
Comments
Many POSIX functions aren’t available on every system, especially embedded ones. The first patch introduces guards around some of these functions and add them to AC_CHECK_FUNCS in the configure.ac; the second one recompile every changed generated file, using autoreconf -fi and clinic. |
This issue is still present in latest 3.5, all the way down to 2.7. |
Removed the unwanted introduced function, and added a comment signaling the end of the HAVE_TTYNAME #ifdef. The full patch is attached, the diff with the previous version can be found at http://linkmauve.fr/files/getedig.patch |
3.2 and 3.3 are only for security fixes now. |
HAVE_SYS_RESOURCE_H still is used for #include in several files. If guards are added to pwd functions, shouldn't it be added to grp and spwd functions? Is there a platform that have pwd.h, but not getpwuid, getpwnam or getpwent. May be instead testing the existence of separate functions adds the test about the existence of pwd.h in configure? |
Personally, I'd rather answer that it's not our problem if some systems are not POSIX-compliant. Maintainers of such systems can always maintain a patch to disable the missing functionality. Adding conditionals everywhere has a non-trivial maintenance cost. |
What do you call "embedded systems"? I worked on set top boxes (the box to watch television) between 2011 and 2013 and we had a regular Linux kernel with all POSIX functions. Most of the time, the CPU was a slow MIPS. The tool chain was based on GCC. For some hardware, we used the µlibc but this C library provides all functions required by Python.
I agree. Anyway, in the embedded world, softwares are usually old and heavily patched. For example, in 2013 we still used Python 2.5.2 with a lot of patches. For example, patches for cross compilation. But also backported features like HTTP Keep-Alive or HTTPS checks. Technically, you can easily fork Python repository and keep your patches up to date using rebase. We defined better rules to support officially a platform. A requirement is for example to have a buildbot running tests daily on the platform. I'm not sure that you are able to host a public buildbot for each custom embedded platform... Android looks a more important target and it was already discussed to setup a Android buildbot. I'm in favor of *dropping* all these annoying #ifdef because it's harder to review, maintain and debug such code. Here is my contribution: issue bpo-23753 "Drop HAVE_FSTAT: require fstat() to compile/use Python". A concrete example: we are working on a Python implementation of io.FileIO and I don't want to see hasattr(os, 'fstat') in the Python code because it has a performance cost *at runtime* (see issue bpo-21859). See also the new Mobile-SIG mailing list which is maybe more appropriate to discuss such changes: |
On Mon, Mar 23, 2015 at 09:05:20PM +0000, STINNER Victor wrote:
My target platforms have been the Newlib-based Wii and 3DS homebrew toolchains, which emulate a POSIX system on top of the raw hardware (or in the case of the 3DS, a proprietary micro-kernel.
There is a port of Python 2.5.something for the Wii, terribly outdated, and this is why I wanted to merge the non-specifics parts of my port upstream, as I thought it would help everyone in that case.
I can provide such a buildbot on my spare Wii. Not really for the 3DS yet, as the homebrew scene is much younger there and unrecoverable lockups happen.
On those two platforms, fstat() is correctly defined and works fine, so it shouldn’t be a problem to drop its #ifdef.
|
What do you think of my idea of maintaining a fork of the Python repository to store your patches, and rebase them sometimes? Would it be an acceptable solution? |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: