Invalid conftest for rl_pending_input when compiling with -flto(=thin) | ext/readline/config.m4, PHP <= 8.3

[henderkes]

Description

The following code:

| char rl_pending_input ();
| int
| main (void)
| {
| return rl_pending_input ();
|   ;
|   return 0;
| }

zig-cc -o conftest -flto=thin conftest.c -lreadline >&5

Resulted in this output:

ld.lld: error: undefined symbol: rl_pending_input
>>> referenced by conftest.c:6
>>>               /home/m/.cache/zig/o/b805c69c22df553bed686894c3b10bd7/conftest.lto.conftest.o:(main)

But I expected this output instead:

configure:69337: $? = 0
configure:69347: result: yes

In my understanding, this comes down to LLVM IR code embedding type information for symbols. rl_pending_output is defined as an int. Linking against a function char rl_pending_order() works without lto because it ignores type information, but with lto it's a mismatch and the function is indeed undefined.

Passing ac_cv_lib_readline_rl_pending_input=yes to compilation works around the issue and php cli and fpm compile successfully. Embed SAPI fails, but that's for a different ticket.

PHP Version

8.3.23

Operating System

All unix systems

[henderkes]

I found this: https://bugs.php.net/bug.php?id=51360&edit=1

which never saw a resolution.

[henderkes]

This appears fixed in 8.4 and master, as they use

  AC_CHECK_DECL([rl_pending_input],, [AC_MSG_FAILURE([
      Invalid readline installation detected. Try --with-libedit instead.
    ])], [
      #include <stdio.h>
      #include <readline/readline.h>
    ])

instead of

  PHP_CHECK_LIBRARY(readline, rl_pending_input,
  [], [
    AC_MSG_ERROR([invalid readline installation detected. Try --with-libedit instead.])
  ], [
    -L$READLINE_DIR/$PHP_LIBDIR $PHP_READLINE_LIBS
  ])

But maybe we can get this fided in <= 8.3, too?

[nielsdos]

I suppose we either backport or change the return type to int. Cc @petk

[henderkes]

Sorry if I wasn't clear enough, it must be an extern int, not a int(void);. Like a variable, not a function.

[petk]

I have no idea, why people still use GNU Readline instead of Editline. If this build is for something serious, it's safer to switch to --with-libedit. I've given up on this extension.

Yes, that variable check can be I guess backported to PHP 8.3 to bypass this issue in the meantime.

[nielsdos]

I'll handle the backport

[henderkes]

I have no idea, why people still use GNU Readline instead of Editline. If this build is for something serious, it's safer to switch to --with-libedit. I've given up on this extension.

Yes, that variable check can be I guess backported to PHP 8.3 to bypass this issue in the meantime.

Is libedit the suggested library now? I cannot find any information of the sort, other than some old threads complaining about missing behaviour from libedit.