Re: [Buildroot] [PATCH v2 1/1] package/octave: add libreadline search prefix

[Peter Korsgaard <peter@korsgaard.com>]

>>>>> "Arnout" == Arnout Vandecappelle via buildroot <buildroot@buildroot.org> writes:

 > On 06/01/2024 14:10, Julien Olivain wrote:
 >> 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]
 >> https://github.com/gnu-octave/octave/commit/3645c78658c4c66f2bc346fdbc5c7c77d8d8dd12
 >> [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>


 >  Applied to master, thanks. And thank you for the _excellent_ commit message!

Yes, super nice! Committed to 2023.11.x, thanks.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot