| Message ID | 20240106131026.127457-1-ju.o@free.fr |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [v2,1/1] package/octave: add libreadline search prefix | expand |
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! Regards, Arnout > --- > Changes v1 -> v2: > - Rewrote the commit log to include the full analysis. > The root cause was more complex that initially thought, > and the issue was not reproduced in Buildroot reference > docker image. > The patch content is exactly the same as v1. > --- > 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
>>>>> "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.
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
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> --- Changes v1 -> v2: - Rewrote the commit log to include the full analysis. The root cause was more complex that initially thought, and the issue was not reproduced in Buildroot reference docker image. The patch content is exactly the same as v1. --- package/octave/octave.mk | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)