Control: tag -1 unreproducible moreinfo On Wed, Aug 22, 2018 at 03:39:14PM +0300, Vasiliy Shlykov wrote: > script eatmydata provided by the package has a serious bug.
Please, consider that this package has been in that state for nearly 2
years; with so many users somebody else would have noticed such a
serious bug.
> The symptom: running command with eatmydata script produces message:
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded
> (cannot open shared object file): ignored.
Can't reproduce here.
mattia@warren ~ % eatmydata true
mattia@warren ~ %
> Obviously, this happens due to using wrong path and name of the library:
> LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+"$LD_LIBRARY_PATH:"}/usr/lib/libeatmydata
> LD_PRELOAD=${LD_PRELOAD:+"$LD_PRELOAD "}libeatmydata.so
>
> Dir /usr/lib/libeatmydata doesn't exists and file libeatmydata.so doesn't
> exists too.
That's false.
For starters, libeatmydata.so sure does exist, in
/usr/lib/x86_64-linux-gnu/libeatmydata.so shipped by the package
libeatmydata1, which is depended by eatmydata.
Secondly, /usr/lib/libeatmydata used to exist, and is there to support
loading the library from such legacy location (think abount having this
script wrapping around a chroot call, etc). http://bugs.debian.org/765810
Also the manpage contains this information.
And anyway, adding random directories to LD_LIBRARY_PATH wouldn't
automatically trigger such "bug".
So, I think you should check your environment and the program you are
then calling (as something programs mangle LD_LIBRARY_PATH and
LD_PRELOAD themselves).
If you can't figure what's going on, please consider sharing more
details about your situation.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
