From 02df2834155aec4c74149b1aacc4d56babcc9325 Mon Sep 17 00:00:00 2001 From: Julien Olivain Date: Sat, 6 Jan 2024 14:10:26 +0100 Subject: [PATCH] package/octave: add libreadline search prefix 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 < Signed-off-by: Arnout Vandecappelle --- package/octave/octave.mk | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/package/octave/octave.mk b/package/octave/octave.mk index cae0de7620..f240a5057c 100644 --- a/package/octave/octave.mk +++ b/package/octave/octave.mk @@ -20,7 +20,9 @@ OCTAVE_DEPENDENCIES = \ pcre2 ifeq ($(BR2_PACKAGE_READLINE),y) -OCTAVE_CONF_OPTS += --enable-readline +OCTAVE_CONF_OPTS += \ + --enable-readline \ + --with-libreadline-prefix=$(STAGING_DIR)/usr OCTAVE_DEPENDENCIES += readline else OCTAVE_CONF_OPTS += --disable-readline