* Sébastien Villemot <[email protected]> [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 <[email protected]> [2025-09-07 18:44]:
Source: vlfeat
Version: 0.9.21+full-2.1
Severity: important
Tags: ftbfs sid forky
X-Debbugs-Cc: [email protected]
User: [email protected]
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.²
What about installing the liboctmex.so* files in /usr/lib/?
Best,
Rafael
¹
https://salsa.debian.org/pkg-privacy-team/torsocks/-/blob/master/debian/rules?ref_type=heads
²
https://udd.debian.org/lintian-tag/package-modifies-ld.so-search-path?affected=yes
