GNU Octave changed its detection of readline library in [1]. This
commit was first included in version 8.1.0.
GNU Octave was updated to 8.1.0 in Buildroot in commit b36e4b10f3
"package/octave: bump to version 8.1.0".
Since this commit, Octave can fail to find readline automatically in
some specific situations. For example, when host system is Fedora 39
and the host "readline-devel" package is installed (see detailed
explanation below).
Octave is now using a m4 macro from gnulib to detect readline.
See [2].
This macro is calling AC_LIB_LINKFLAGS_BODY([readline]). Note that
this macro will look into $libdir and $includedir by default. See [3].
Buildroot is calling target autotools configure command with
--prefix=/usr and --exec-prefix=/usr arguments. See [4].
Autotools derives libdir='${exec_prefix}/lib' and
includedir='${prefix}/include'.
Finally, gnulib will also search automatically into alternate library
directories (i.e. lib32, lib64). See [5].
All of this will make the configure script searching the readline
library by default (i.e. if the library prefix is not provided) into
the host "/usr/lib", "/usr/lib32" and "/usr/lib64", when configuring
for target.
This issue is not happening on the Buildroot docker reference image,
because the package "libreadline-dev" is not present in this image.
Even if the package "libreadline-dev" is installed on a Debian based
host systems, the issue is still not happening because libraries are
installed in the path "/usr/lib/x86_64-linux-gnu", which is not
searched by gnulib macros.
On host systems which installs libraries into one of the
"/usr/lib{,32,64}" directories, the Octave configuration script will
fail, because it will detect the host library and try to link against
it with target architecture and compilation flags and will fail. Since
the --enable-readline configure option is present, the configuration
script will fail because it cannot find a working readline library.
This can be seen in the octave configuration log, in file:
output/build/octave-8.4.0/config.log
configure:73671: checking for readline
configure:73705: /buildroot/output/host/bin/aarch64-none-linux-gnu-gcc -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -g0 -D_FORTIFY_SOURCE=1 -pthread -fopenmp -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 conftest.c -lpthread -lm /usr/lib64/libreadline.so >&5
/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64-none-linux-gnu/13.2.1/../../../../aarch64-none-linux-gnu/bin/ld: /usr/lib64/libreadline.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
This situation can be reproduced on a Fedora 39 x86_64 host system,
with the "readline-devel" package installed. Note: uninstalling the
"readline-devel" will work around the issue.
The issue can be reproduced with a Buildroot configuration such as:
cat > .config <<EOF
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_OCTAVE=y
BR2_PACKAGE_READLINE=y
EOF
make olddefconfig
make
In order to avoid those host/target readline detection mix-ups, the
readline search prefix need to be explicitly passed during octave
configuration. This commit adds this search prefix to fix this build
issue.
Fixes:
checking for readline... (cached) no
checking for readline/readline.h... (cached) yes
checking for readline/history.h... (cached) yes
configure: WARNING: I need GNU Readline 4.2 or later
configure: error: this is fatal unless you specify --disable-readline
[1] 3645c78658
[2] https://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/readline.m4?id=2cdc1bafb20b187ad067056e090fcb4396ed9099
[3] https://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/lib-link.m4?id=2cdc1bafb20b187ad067056e090fcb4396ed9099#n190
[4] https://gitlab.com/buildroot.org/buildroot/-/blob/2023.11/package/pkg-autotools.mk#L175
[5] https://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/lib-prefix.m4?id=2cdc1bafb20b187ad067056e090fcb4396ed9099#n276
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
02df283415