Skip to content

readline module fails to build against recent libedit #117845

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

Closed
jmroot opened this issue Apr 13, 2024 · 5 comments
Closed

readline module fails to build against recent libedit #117845

jmroot opened this issue Apr 13, 2024 · 5 comments
Labels
3.13 bugs and security fixes build The build process and cross-build type-bug An unexpected behavior, bug, or error

Comments

@jmroot
Copy link
Contributor

jmroot commented Apr 13, 2024

Bug report

Bug description:

Building Python 3.13.0a6 configured with --with-readline=editline fails like this for me:

./Modules/readline.c:1305:21: error: incompatible function pointer types assigning to 'rl_hook_func_t *' (aka 'int (*)(void)') from 'int (const char *, int)' [-Wincompatible-function-pointer-types]
    rl_startup_hook = on_startup_hook;
                    ^ ~~~~~~~~~~~~~~~
./Modules/readline.c:1307:23: error: incompatible function pointer types assigning to 'rl_hook_func_t *' (aka 'int (*)(void)') from 'int (const char *, int)' [-Wincompatible-function-pointer-types]
    rl_pre_input_hook = on_pre_input_hook;
                      ^ ~~~~~~~~~~~~~~~~~
2 errors generated.

It looks like e7e1116 is the cause. No editline header defines _RL_FUNCTION_TYPEDEF, but recent versions (in this case 20230828) declare these functions as taking void whereas Apple's version declares them the other way. I suspect that older clang versions and gcc may let you off with a warning rather than erroring on this type mismatch.

CPython versions tested on:

3.13

Operating systems tested on:

macOS

Linked PRs

@jmroot jmroot added the type-bug An unexpected behavior, bug, or error label Apr 13, 2024
@hugovk hugovk added 3.13 bugs and security fixes build The build process and cross-build labels Apr 13, 2024
@gaogaotiantian
Copy link
Member

The upstream libedit "fixed" the function declaration in 1.53, which kind of creates a disaster for us. The apple version branched before that and arguably the most common libedit we will have. Linux user (or maybe Mac user that builds their own libedit) potentially could use any version.

I can't think of anything to distinguish between the versions, and I think there are multiple version mechanics out in the market (ubuntu seems to use the version 3.1 + date?). I don't know any C tricks to make this work because that's a different typedef, not MACRO.

I can think of a couple non-ideal solutions:

  1. Let it be.
  2. Ask user to pass -D_RL_FUNCTION_TYPEDEF under such case.
  3. Use two different configuration names for libedit with two different callback signatures.

I don't think tricking compiler works in this case as the input argument number is different.

@jmroot
Copy link
Contributor Author

jmroot commented Apr 14, 2024

I can't think of anything to distinguish between the versions, and I think there are multiple version mechanics out in the market (ubuntu seems to use the version 3.1 + date?). I don't know any C tricks to make this work because that's a different typedef, not MACRO.

I think it would need to be an autoconf check, albeit a little more sophisticated than the one that was removed. You could check if a C function that calls function pointers of the appropriate types will compile when using the different numbers of args.

@gaogaotiantian
Copy link
Member

I'm not an expert on autoconf so I don't know if this kind of check is feasible or common for autoconf. @corona10 worked on the original option I believe and he might have a better idea of it.

jmroot added a commit to jmroot/cpython that referenced this issue Apr 14, 2024
Older libedit versions (like Apple's) use a different type signature
for rl_startup_hook and rl_pre_input_hook. Add a configure check to
determine which one is accepted.
erlend-aasland pushed a commit that referenced this issue Apr 17, 2024
Older libedit versions (like Apple's) use a different type signature
for rl_startup_hook and rl_pre_input_hook. Add a configure check to
determine which signature is accepted by introducing the
Py_RL_STARTUP_HOOK_TAKES_ARGS macro in pyconfig.h.
@erlend-aasland
Copy link
Contributor

diegorusso pushed a commit to diegorusso/cpython that referenced this issue Apr 17, 2024
…ython#117870)

Older libedit versions (like Apple's) use a different type signature
for rl_startup_hook and rl_pre_input_hook. Add a configure check to
determine which signature is accepted by introducing the
Py_RL_STARTUP_HOOK_TAKES_ARGS macro in pyconfig.h.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.13 bugs and security fixes build The build process and cross-build type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

4 participants