Bug#1114618: FTBFS against Octave 10

[Rafael Laboissière]

* Sébastien Villemot <sebastien at 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 at 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 at lists.debian.org
>>>> User: debian-octave at 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.²

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