Skip to content
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

Open
LinkMauve mannequin opened this issue Oct 13, 2014 · 9 comments
Labels
build The build process and cross-build extension-modules C modules in the Modules dir

Comments

@LinkMauve
Copy link
Mannequin

LinkMauve mannequin commented Oct 13, 2014

BPO 22623
Nosy @loewis, @pitrou, @vstinner, @ezio-melotti, @serhiy-storchaka
Files
  • guards.diff: Patch against latest default
  • getedig.patch: New version of the patch
  • getedig.patch: Same patch, without the git diff format.
  • getedig.patch: Newer version of the patch.
  • getedig.patch: Forgot one fix in the previous one.
  • 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:

    assignee = None
    closed_at = None
    created_at = <Date 2014-10-13.12:44:03.178>
    labels = ['extension-modules', 'build']
    title = 'Port Python to 3DS: micro kernel, homebrew, newlib (Missing guards for some POSIX functions)'
    updated_at = <Date 2016-01-03.06:41:09.673>
    user = 'https://bugs.python.org/LinkMauve'

    bugs.python.org fields:

    activity = <Date 2016-01-03.06:41:09.673>
    actor = 'ezio.melotti'
    assignee = 'none'
    closed = False
    closed_date = None
    closer = None
    components = ['Extension Modules']
    creation = <Date 2014-10-13.12:44:03.178>
    creator = 'Link Mauve'
    dependencies = []
    files = ['37971', '38160', '38161', '38172', '38173']
    hgrepos = ['276']
    issue_num = 22623
    keywords = ['patch']
    message_count = 9.0
    messages = ['229243', '235214', '236142', '236146', '236414', '239065', '239067', '239096', '239100']
    nosy_count = 6.0
    nosy_names = ['loewis', 'pitrou', 'vstinner', 'ezio.melotti', 'serhiy.storchaka', 'Link Mauve']
    pr_nums = []
    priority = 'normal'
    resolution = None
    stage = None
    status = 'pending'
    superseder = None
    type = 'compile error'
    url = 'https://bugs.python.org/issue22623'
    versions = ['Python 2.7', 'Python 3.5', 'Python 3.6']

    @LinkMauve
    Copy link
    Mannequin Author

    LinkMauve mannequin commented Oct 13, 2014

    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.

    @LinkMauve LinkMauve mannequin added build The build process and cross-build labels Oct 13, 2014
    @LinkMauve
    Copy link
    Mannequin Author

    LinkMauve mannequin commented Feb 2, 2015

    This issue is still present in latest 3.5, all the way down to 2.7.

    @LinkMauve LinkMauve mannequin added extension-modules C modules in the Modules dir and removed build The build process and cross-build labels Feb 2, 2015
    @LinkMauve
    Copy link
    Mannequin Author

    LinkMauve mannequin commented Feb 17, 2015

    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

    @serhiy-storchaka
    Copy link
    Member

    3.2 and 3.3 are only for security fixes now.

    @serhiy-storchaka
    Copy link
    Member

    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?

    @pitrou
    Copy link
    Member

    pitrou commented Mar 23, 2015

    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.

    @vstinner
    Copy link
    Member

    Many POSIX functions aren’t available on every system, especially embedded ones.

    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.

    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.

    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:
    https://mail.python.org/mailman/listinfo/mobile-sig

    @LinkMauve
    Copy link
    Mannequin Author

    LinkMauve mannequin commented Mar 24, 2015

    On Mon, Mar 23, 2015 at 09:05:20PM +0000, STINNER Victor wrote:

    STINNER Victor added the comment:

    > Many POSIX functions aren’t available on every system, especially embedded ones.

    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.

    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.

    > 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.

    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.

    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.

    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...

    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.

    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).

    On those two platforms, fstat() is correctly defined and works fine, so it shouldn’t be a problem to drop its #ifdef.

    See also the new Mobile-SIG mailing list which is maybe more appropriate to discuss such changes:
    https://mail.python.org/mailman/listinfo/mobile-sig

    ----------
    nosy: +haypo


    Python tracker <report@bugs.python.org>
    <http://bugs.python.org/issue22623\>


    @vstinner vstinner changed the title Missing guards for some POSIX functions Port Python to 3DS: micro kernel, homebrew, newlib (Missing guards for some POSIX functions) Mar 24, 2015
    @vstinner
    Copy link
    Member

    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.

    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?

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    build The build process and cross-build extension-modules C modules in the Modules dir
    Projects
    None yet
    Development

    No branches or pull requests

    4 participants