Le mardi 09 septembre 2025 à 09:39 +0200, Rafael Laboissière a écrit : > * Sébastien Villemot <sebastien@debian.org> [2025-09-08 21:01]: > > > Le lundi 08 septembre 2025 à 19:43 +0200, Sébastien Villemot a écrit : > > > Le lundi 08 septembre 2025 à 19:25 +0200, Rafael Laboissière a écrit : > > > > * Sébastien Villemot <sebastien@debian.org> [2025-09-07 18:44]: > > > > > > > > > Source: vlfeat > > > > > Version: 0.9.21+full-2.1 > > > > > Severity: important > > > > > Tags: ftbfs sid forky > > > > > X-Debbugs-Cc: debian-octave@lists.debian.org > > > > > User: debian-octave@lists.debian.org > > > > > Usertags: octave-10 > > > > > > > > > > Dear Maintainer, > > > > > > > > > > vlfeat FTBFS against octave 10 (which currently stands in experimental). > > > > > > > > > > A build log is attached. > > > > > > > > There are loads of error messages like the following one: > > > > > > > > dpkg-shlibdeps: error: cannot find library liboctmex.so.1 needed by debian/octave-vlfeat/usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/vlfeat/toolbox/vl_twister.mex (ELF format: 'elf64-x86-64' abi: 'ELF:64:l:amd64:0'; RPATH: '') > > > > > > > > This is strange, because "-L/usr/lib/x86_64-linux-gnu/octave/10.2.0 > > > > -loctmex" is passed to g++ when the .mex files are compiled through > > > > mkoctfile, like in the following example: > > > > > > > > CFLAGS="-g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/build/reproducible-path/vlfeat-0.9.21+full=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -g -Wdate-time -D_FORTIFY_SOURCE=2 -std=c99 -Wall -Wextra -Wno-unused-function -Wno-long-long -Wno-variadic-macros -DNDEBUG -O3 -D_GNU_SOURCE -fno-stack-protector" \ > > > > LDFLAGS="-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -lpthread -lm" \ > > > > /usr/bin/mkoctfile \ > > > > --mex -v \ > > > > --output "toolbox/mex/octave/mexglx/vl_slic.mex" \ > > > > -DVL_DISABLE_SSE2 -DVL_DISABLE_AVX -I. -Itoolbox -I. "./toolbox/slic/vl_slic.c" \ > > > > -Lbin/debian -lvl -lm > > > > gcc -c -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/octave-10.2.0/octave/.. -I/usr/include/octave-10.2.0/octave -pthread -fopenmp -fexceptions -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/build/reproducible-path/vlfeat-0.9.21+full=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -g -Wdate-time -D_FORTIFY_SOURCE=2 -std=c99 -Wall -Wextra -Wno-unused-function -Wno-long-long -Wno-variadic-macros -DNDEBUG -O3 -D_GNU_SOURCE -fno-stack-protector -I. -I. -Itoolbox -I. -DVL_DISABLE_SSE2 -DVL_DISABLE_AVX -DMEX_DEBUG ./toolbox/slic/vl_slic.c -o /tmp/oct-7QRLV6.o > > > > gcc -c -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/octave-10.2.0/octave/.. -I/usr/include/octave-10.2.0/octave -pthread -fopenmp -fexceptions -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/build/reproducible-path/vlfeat-0.9.21+full=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -g -Wdate-time -D_FORTIFY_SOURCE=2 -std=c99 -Wall -Wextra -Wno-unused-function -Wno-long-long -Wno-variadic-macros -DNDEBUG -O3 -D_GNU_SOURCE -fno-stack-protector -I. -I. -Itoolbox -I. -DVL_DISABLE_SSE2 -DVL_DISABLE_AVX -DMEX_DEBUG /tmp/oct-kEsu4D.c -o /tmp/oct-uNoD3P.o > > > > g++ -I/usr/include/octave-10.2.0/octave/.. -I/usr/include/octave-10.2.0/octave -pthread -fopenmp -g -O2 -ffile-prefix-map=/build/reproducible-path/vlfeat-0.9.21+full=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -o toolbox/mex/octave/mexglx/vl_slic.mex /tmp/oct-7QRLV6.o /tmp/oct-uNoD3P.o -Lbin/debian -lvl -lm -shared -Wl,-Bsymbolic -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -lpthread -lm -L/usr/lib/x86_64-linux-gnu/octave/10.2.0 -loctmex -flto=auto -ffat-lto-objects -Wl,-z,relro > > > > > > > > Any ideas? > > > > > > The problem is that liboctmex.so.1 appears in the dynamic dependencies > > > of the generated MEX file (technically in the DT_NEEDED ELF section), > > > but the library is not in a location searched by the dynamic linker > > > (because it is installed in a private directory, as the other Octave > > > libraries). > > > > > > This probably needs to be solved at the mkoctfile level. > > > > > > Note that there are many other similar bugs. Once we have found the > > > correct fix, and assuming that the fix is in src:octave, we’ll reassign > > > these bugs to octave-dev and merge them. > > > > Actually fixing #1061644 would fix the present FTBFS bug and all the > > similar ones. > > > > Should I go ahead? > > If the fix consists in adding a file to /etc/ld.so.conf.d/, like the > torsocks package does¹, I guess it will make Lintian unhappy.² Yes, that would be the plan. And that would make dpkg-shlibdeps happy. > What about installing the liboctmex.so* files in /usr/lib/? We used to do that for liboctave, liboctinterp and liboctgui. That was painful because we had to maintain a separate library package (liboctaveNN), which was creating various problems. Then mkoctfile stopped linking against those libraries, so we could easily drop the liboctaveNN package and move back those libraries to a private directory (which is the default behaviour of upstream build system). Since the .oct and .mex files are loaded from within octave, those libraries are in any case already present in memory, so there is no dynamic linking issue. The only problem happens when creating a stand-alone executable from mkoctfile, which is #1061644 is initially about. With Octave 10, liboctmex was introduced and .mex files generated by mkoctfile are linked against it, hence the present issue. My feeling is that the easiest fix is to drop something into /etc/ld.so.conf.d/. Otherwise we will have to diverge from upstream in some way (either patch mkoctfile so that it does not link against liboctmex, or moving that library to /usr/lib/$MULTIARCH_TRIPLET with the problems that come with that). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part