Le dimanche 28 janvier 2024 à 22:18 +0100, Rafael Laboissière a écrit : > * Antony Donovan <a...@mit.edu> [2024-01-27 15:52]: > > > Package: octave-dev > > Version: 7.3.0-2 > > Severity: normal > > Tags: patch > > > > Dear Maintainer, > > > > I installed octave-dev and after building a standalone executable with > > mkoctfile it failed to run. > > > > I realized that what was needed was an ld.so.conf fragment containing > > the directory where the shared libraries were located. > > > > I created that fragment, with the contents > > /usr/lib/x86_64-linux-gnu/octave/7.3.0, named it octave-dev.conf, > > put that file in /etc/ld.so.conf.d, and ran ldconfig. > > > > This fixed the issue of running the standalone octave executable. > > Thank you for your bug report. > > Could you please provide us with a complete example that reproduces > the bug?
I suppose that the issue appears with option --link-stand-alone of mkoctfile. I’m not sure that modifying the dynamic linker configuration for the whole system, as suggested by Antony, is the right thing to do, especially for a feature that is seldom used (mkoctfile is primarily used for building .oct and .mex files, not standalone executable). Octave libraries are private on purpose. Another solution is simply to set the rpath in the created ELF executable. I think we should ask upstream about the intended use of the --link- stand-alone option, and about the proper way of dealing with dynamic loading of private Octave libraries in that case. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
signature.asc
Description: This is a digitally signed message part
