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.

Sign up for GitHub

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

Jump to bottom

Posix module init function name should not be compiler-dependent #66769

Closed
JeffreyArmstrong mannequin opened this issue Oct 8, 2014 · 6 comments
Closed

Posix module init function name should not be compiler-dependent #66769

JeffreyArmstrong mannequin opened this issue Oct 8, 2014 · 6 comments
Labels
build The build process and cross-build interpreter-core (Objects, Python, Grammar, and Parser dirs) OS-windows

Comments

@JeffreyArmstrong
Copy link
Mannequin

JeffreyArmstrong mannequin commented Oct 8, 2014

BPO 22579
Nosy @loewis, @birkenfeld, @pitrou, @vstinner
Files
  • posix_init.patch: Patch to check for MS_WINDOWS when determining name of posix module's init function
    		•

    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 = <Date 2014-10-09.22:14:23.921>
created_at = <Date 2014-10-08.13:26:55.042>
labels = ['interpreter-core', 'build', 'OS-windows']
title = 'Posix module init function name should not be compiler-dependent'
updated_at = <Date 2014-10-09.22:14:23.920>
user = 'https://bugs.python.org/JeffreyArmstrong'

    bugs.python.org fields:

    activity = <Date 2014-10-09.22:14:23.920>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2014-10-09.22:14:23.921>
closer = 'vstinner'
components = ['Interpreter Core', 'Windows']
creation = <Date 2014-10-08.13:26:55.042>
creator = 'Jeffrey.Armstrong'
dependencies = []
files = ['36835']
hgrepos = []
issue_num = 22579
keywords = ['patch']
message_count = 6.0
messages = ['228789', '228861', '228908', '228911', '228914', '228929']
nosy_count = 6.0
nosy_names = ['loewis', 'georg.brandl', 'pitrou', 'vstinner', 'Arfrever', 'Jeffrey.Armstrong']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue22579'
versions = ['Python 3.5']
    @JeffreyArmstrong
    Copy link
    Mannequin Author

    JeffreyArmstrong mannequin commented Oct 8, 2014

    The determination of the name of the posix module's initialization function (at Modules/posixmodule.c:12055) is currently dependent on the compiler being used. For MSVC, Watcom, or Borland, the name is defined as "PyInit_nt." However, both Open Watcom and Borland have shipped compilers for GNU/Linux (and other platforms), making determining the posix module initialization function based on compiler incorrect.

    Most other places in Modules/posixmodule.c correctly use the "MS_WINDOWS" preprocessor definition to determine if Windows routines should be used. Naming the intialization function for the posix module should be dependent on this as well rather than compiler identifiers.

    Linking the interpreter natively with Open Watcom fails under GNU/Linux due to "PyInit_posix" being undefined. This occurs because of the reasons described above. The patch included corrects the issue.

    @JeffreyArmstrong JeffreyArmstrong mannequin added interpreter-core (Objects, Python, Grammar, and Parser dirs) build The build process and cross-build labels Oct 8, 2014
    @vstinner
    Copy link
    Member

    vstinner commented Oct 9, 2014

    The patch looks good to me, but I would prefer that someone else double check.

    @birkenfeld
    Copy link
    Member

    There is also

    #if !defined(__QNX__)
#if defined(MS_WINDOWS) || defined(__BORLANDC__) || defined(__WATCOMC__) || defined(__DJGPP__)
#define SEP L'\\'
#define ALTSEP L'/'
#define MAXPATHLEN 256
#define DELIM L';'
#endif
#endif

    in Include/osdefs.h

    @pitrou
    Copy link
    Member

    pitrou commented Oct 9, 2014

    I would remove the "|| defined(BORLANDC) || defined(WATCOMC) || defined(DJGPP)" part, since it's probably for MSDOS variants of those compilers.

    @vstinner
    Copy link
    Member

    vstinner commented Oct 9, 2014

    I would remove the "|| defined(BORLANDC) || defined(WATCOMC) || defined(DJGPP)" part, since it's probably for MSDOS variants of those compilers.

    I agree, but IMO it is unrelated to this issue. Jeffrey wants to support a new C compiler (OpenWatcom) on Windows, not drop support of MS-DOS or old C compiler.

    I created the issue bpo-22591 to drop support of MS-DOS specific code.

    @vstinner
    Copy link
    Member

    vstinner commented Oct 9, 2014

    Ok, I pushed the change:
    ---
    changeset: 92900:c7adad17f663
    user: Victor Stinner <victor.stinner@gmail.com>
    date: Fri Oct 10 00:09:47 2014 +0200
    files: Modules/posixmodule.c

    Closes bpo-22579: Fix posixmodule.c to support any C compiler on Windows
    ---

    Oh, I forgot to mention that Jeffrey Armstrong wrote it, sorry :-(

    I created the issue bpo-22592 "Drop support of Borland C compiler". See also the issue bpo-22591 for MS-DOS.

    @vstinner vstinner closed this as completed Oct 9, 2014
    @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
    Assignees
    No one assigned
    Labels
    build The build process and cross-build interpreter-core (Objects, Python, Grammar, and Parser dirs) OS-windows
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    3 participants
    @birkenfeld @vstinner @pitrou