Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1260550 > unrolled thread

Bug#1114618: FTBFS against Octave 10

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1114618: FTBFS against Octave 10 Rafael Laboissière <rafael@debian.org> - 2025-09-08 19:30 +0200
    Bug#1114618: FTBFS against Octave 10 Sébastien Villemot <sebastien@debian.org> - 2025-09-08 20:00 +0200
      Bug#1114618: FTBFS against Octave 10 Sébastien Villemot <sebastien@debian.org> - 2025-09-08 21:10 +0200
        Bug#1114618: FTBFS against Octave 10 Rafael Laboissière <rafael@debian.org> - 2025-09-09 09:50 +0200
          Bug#1114618: FTBFS against Octave 10 Sébastien Villemot <sebastien@debian.org> - 2025-09-09 10:30 +0200
            Bug#1114618: FTBFS against Octave 10 Rafael Laboissière <rafael@debian.org> - 2025-09-09 11:30 +0200
              Bug#1114618: FTBFS against Octave 10 Sébastien Villemot <sebastien@debian.org> - 2025-09-09 11:50 +0200
                Bug#1114618: FTBFS against Octave 10 Rafael Laboissière <rafael@debian.org> - 2025-09-09 16:20 +0200
                  Bug#1114618: FTBFS against Octave 10 Sébastien Villemot <sebastien@debian.org> - 2025-09-09 17:10 +0200
                    Bug#1114618: FTBFS against Octave 10 Rafael Laboissière <rafael@debian.org> - 2025-09-09 21:00 +0200
                      Bug#1114618: FTBFS against Octave 10 Rafael Laboissière <rafael@debian.org> - 2025-09-10 11:00 +0200
                    Bug#1114618: FTBFS against Octave 10 Rafael Laboissière <rafael@debian.org> - 2025-09-11 11:20 +0200

#1260550 — Bug#1114618: FTBFS against Octave 10

* 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?

Best,

Rafael Laboissière

[toc] | [next] | [standalone]

#1260558

[Multipart message — attachments visible in raw view] — view raw

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.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  https://www.debian.org

[toc] | [prev] | [next] | [standalone]

#1260572

[Multipart message — attachments visible in raw view] — view raw

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?

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  https://www.debian.org

[toc] | [prev] | [next] | [standalone]

#1260628

* 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.²

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

[toc] | [prev] | [next] | [standalone]

#1260634

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1260641

* Sébastien Villemot <sebastien@debian.org> [2025-09-09 10:20]:

> 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 :
>>>
>>> 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.

Lintian classifies the package-modifies-ld.so-search-path tag as 
"type: error". Does this qualify the issue as release-critical?

Best,

Rafael

[toc] | [prev] | [next] | [standalone]

#1260646

[Multipart message — attachments visible in raw view] — view raw

Le mardi 09 septembre 2025 à 11:25 +0200, Rafael Laboissière a écrit :
> * Sébastien Villemot <sebastien@debian.org> [2025-09-09 10:20]:
> 
> > 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 :
> > > > 
> > > > 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.
> 
> Lintian classifies the package-modifies-ld.so-search-path tag as 
> "type: error". Does this qualify the issue as release-critical?
> 
I see. So adding a drop-in file under /etc/ld.so.conf.d/ is considered
bad practice and is discouraged.

Actually there is no real need to tell the dynamic linker to look for
this additional directory, because as I said before, the .mex files are
being loaded from within Octave and liboctmex is already in memory.

So an alternative fix is just to tell dpkg-shlibdeps to stop
complaining, by passing it the -l option.

Ideally this would be done by dh-octave, so that we don’t have to
modify all individual packages, but I don’t know whether this is
possible.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  https://www.debian.org

[toc] | [prev] | [next] | [standalone]

#1260678

* Sébastien Villemot <sebastien@debian.org> [2025-09-09 11:40]:

> Le mardi 09 septembre 2025 à 11:25 +0200, Rafael Laboissière a écrit :
>> * Sébastien Villemot <sebastien@debian.org> [2025-09-09 10:20]:
>>
>>> 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 :
>>>>>
>>>>> 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.
>>
>> Lintian classifies the package-modifies-ld.so-search-path tag as 
>> "type: error". Does this qualify the issue as release-critical?
>>
> I see. So adding a drop-in file under /etc/ld.so.conf.d/ is considered 
> bad practice and is discouraged.
>
> Actually there is no real need to tell the dynamic linker to look for 
> this additional directory, because as I said before, the .mex files are 
> being loaded from within Octave and liboctmex is already in memory.
>
> So an alternative fix is just to tell dpkg-shlibdeps to stop 
> complaining, by passing it the -l option.

Ok, I implemented the idea in vlfeat:

https://salsa.debian.org/science-team/vlfeat/-/commit/451505636550205a60c362aed32c0dc8c324f1fa 
https://salsa.debian.org/science-team/vlfeat/-/commit/5dba6d243590025e59a078f25462ceb5e1cd5abc

> Ideally this would be done by dh-octave, so that we don’t have to 
> modify all individual packages, but I don’t know whether this is 
> possible.

I implemented a solution in dh-octave: 
https://salsa.debian.org/pkg-octave-team/dh-octave/-/commit/e7497ed114bcf89ccde18ef97ed20f064f17d26f

It seems to be working correctly.

How should we proceed? I could release the package with the above fix to 
experimental. Once the tests are complet, you can merge the bug reports 
that are related to the dpkg-shlibdeps issue and release a new version of 
dh-octave to unstable, and close the bugs. Is this an acceptable plan?

Best,

Rafael Laboissière

[toc] | [prev] | [next] | [standalone]

#1260681

[Multipart message — attachments visible in raw view] — view raw

Le mardi 09 septembre 2025 à 16:14 +0200, Rafael Laboissière a écrit :
> * Sébastien Villemot <sebastien@debian.org> [2025-09-09 11:40]:
> 
> > Le mardi 09 septembre 2025 à 11:25 +0200, Rafael Laboissière a écrit :
> > > * Sébastien Villemot <sebastien@debian.org> [2025-09-09 10:20]:
> > > 
> > > > 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 :
> > > > > > 
> > > > > > 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.
> > > 
> > > Lintian classifies the package-modifies-ld.so-search-path tag as 
> > > "type: error". Does this qualify the issue as release-critical?
> > > 
> > I see. So adding a drop-in file under /etc/ld.so.conf.d/ is considered 
> > bad practice and is discouraged.
> > 
> > Actually there is no real need to tell the dynamic linker to look for 
> > this additional directory, because as I said before, the .mex files are 
> > being loaded from within Octave and liboctmex is already in memory.
> > 
> > So an alternative fix is just to tell dpkg-shlibdeps to stop 
> > complaining, by passing it the -l option.
> 
> Ok, I implemented the idea in vlfeat:
> 
> https://salsa.debian.org/science-team/vlfeat/-/commit/451505636550205a60c362aed32c0dc8c324f1fa 
> https://salsa.debian.org/science-team/vlfeat/-/commit/5dba6d243590025e59a078f25462ceb5e1cd5abc

Sounds good. But does that mean that vlfeat cannot take advantage of
your fix in dh-octave?

> > Ideally this would be done by dh-octave, so that we don’t have to 
> > modify all individual packages, but I don’t know whether this is 
> > possible.
> 
> I implemented a solution in dh-octave: 
> https://salsa.debian.org/pkg-octave-team/dh-octave/-/commit/e7497ed114bcf89ccde18ef97ed20f064f17d26f
> 
> It seems to be working correctly.
> 
> How should we proceed? I could release the package with the above fix to 
> experimental. Once the tests are complet, you can merge the bug reports 
> that are related to the dpkg-shlibdeps issue and release a new version of 
> dh-octave to unstable, and close the bugs. Is this an acceptable plan?

Thanks for making the change in dh-octave!

I suggest that you upload the new dh-octave directly to unstable. This
should not break anything with Octave 9, unless I’m missing something.

Then we will review bugs individually to check whether they are fixed
or not by this upload (I think that dynare will need a custom fix,
maybe vlfeat also if I understand your above commits correctly), and
directly close those that are indeed fixed by the new dh-octave. So we
should probably not merge all the bugs.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  https://www.debian.org

[toc] | [prev] | [next] | [standalone]

#1260731

* Sébastien Villemot <sebastien@debian.org> [2025-09-09 16:51]:

> Le mardi 09 septembre 2025 à 16:14 +0200, Rafael Laboissière a écrit :
>> * Sébastien Villemot <sebastien@debian.org> [2025-09-09 11:40]:
>>
>>> Le mardi 09 septembre 2025 à 11:25 +0200, Rafael Laboissière a écrit :
>>>> * Sébastien Villemot <sebastien@debian.org> [2025-09-09 10:20]:
>>>>
>>>>> 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 :
>>>>>>>
>>>>>>> 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.
>>>>
>>>> Lintian classifies the package-modifies-ld.so-search-path tag as 
>>>> "type: error". Does this qualify the issue as release-critical?
>>>>
>>> I see. So adding a drop-in file under /etc/ld.so.conf.d/ is considered 
>>> bad practice and is discouraged.
>>>
>>> Actually there is no real need to tell the dynamic linker to look for 
>>> this additional directory, because as I said before, the .mex files are 
>>> being loaded from within Octave and liboctmex is already in memory.
>>>
>>> So an alternative fix is just to tell dpkg-shlibdeps to stop 
>>> complaining, by passing it the -l option.
>>
>> Ok, I implemented the idea in vlfeat:
>>
>> https://salsa.debian.org/science-team/vlfeat/-/commit/451505636550205a60c362aed32c0dc8c324f1fa 
>> https://salsa.debian.org/science-team/vlfeat/-/commit/5dba6d243590025e59a078f25462ceb5e1cd5abc
>
> Sounds good. But does that mean that vlfeat cannot take advantage of 
> your fix in dh-octave?

No, vlfeat cannot take advantage of the fix in dh-octave because it 
does not use the Octave sequence of Debhelper.

>>> Ideally this would be done by dh-octave, so that we don’t have to 
>>> modify all individual packages, but I don’t know whether this is 
>>> possible.
>>
>> I implemented a solution in dh-octave: 
>> https://salsa.debian.org/pkg-octave-team/dh-octave/-/commit/e7497ed114bcf89ccde18ef97ed20f064f17d26f
>>
>> It seems to be working correctly.
>>
>> How should we proceed? I could release the package with the above fix to 
>> experimental. Once the tests are complet, you can merge the bug reports 
>> that are related to the dpkg-shlibdeps issue and release a new version of 
>> dh-octave to unstable, and close the bugs. Is this an acceptable plan?
>
> Thanks for making the change in dh-octave!
>
> I suggest that you upload the new dh-octave directly to unstable. This 
> should not break anything with Octave 9, unless I’m missing something.
>
> Then we will review bugs individually to check whether they are fixed 
> or not by this upload (I think that dynare will need a custom fix, 
> maybe vlfeat also if I understand your above commits correctly), and 
> directly close those that are indeed fixed by the new dh-octave. So we 
> should probably not merge all the bugs.

Ok, I will upload a new version of dh-octave to unstable as soon as 
possible (probably tomorrow).

I will also take care of vlfeat.

Best,

Rafael

[toc] | [prev] | [next] | [standalone]

#1260816

* Rafael Laboissière <rafael@debian.org> [2025-09-09 20:49]:

> * Sébastien Villemot <sebastien@debian.org> [2025-09-09 16:51]:
>
>> Le mardi 09 septembre 2025 à 16:14 +0200, Rafael Laboissière a écrit :
>>>
>>> I implemented a solution in dh-octave: https://salsa.debian.org/pkg-octave-team/dh-octave/-/commit/e7497ed114bcf89ccde18ef97ed20f064f17d26f
>>>
>>> It seems to be working correctly.
>>>
>>> How should we proceed? I could release the package with the above 
>>> fix to experimental. Once the tests are complet, you can merge the 
>>> bug reports that are related to the dpkg-shlibdeps issue and 
>>> release a new version of dh-octave to unstable, and close the 
>>> bugs. Is this an acceptable plan?
>>
>> Thanks for making the change in dh-octave!
>>
>> I suggest that you upload the new dh-octave directly to unstable. 
>> This should not break anything with Octave 9, unless I’m missing 
>> something.
>>
>> Then we will review bugs individually to check whether they are 
>> fixed or not by this upload (I think that dynare will need a custom 
>> fix, maybe vlfeat also if I understand your above commits 
>> correctly), and directly close those that are indeed fixed by the 
>> new dh-octave. So we should probably not merge all the bugs.
>
> Ok, I will upload a new version of dh-octave to unstable as soon as 
> possible (probably tomorrow).

Done!

> I will also take care of vlfeat.

Also done!

Best,

Rafael Laboissière

[toc] | [prev] | [next] | [standalone]

#1260931

* Sébastien Villemot <sebastien@debian.org> [2025-09-09 16:51]:
>
> Then we will review bugs individually to check whether they are fixed 
> or not by this upload (I think that dynare will need a custom fix, 
> maybe vlfeat also if I understand your above commits correctly), and 
> directly close those that are indeed fixed by the new dh-octave. So we 
> should probably not merge all the bugs.

How should we close the bugs fixed by dh-octave? Would the following be 
enough?

     To: <nnnnnnn>-done@bugs.debian.org

     Control: fixed -1 <current-version-in-unstable>

     The package builds correctly against dh-octave 1.10.3.

Best,

Rafael Laboissière

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web