On Thu, Oct 16, 2014 at 1:38 PM, Thorsten Glaser <[email protected]> wrote:
> Package: eatmydata
> Version: 82-2
> Severity: important
>
> When I run cowbuilder --update on a wheezy chroot, I now get
> dozens of messages like:
>
> ERROR: ld.so: object '/usr/lib/x86_64-linux-gnux32/libeatmydata.so' from
> LD_PRELOAD cannot be preloaded: ignored.
>
> This is apparently because the eatmydata sets LD_PRELOAD from
> outside the chroot, which gets inherited, but cannot be solved
> from inside the chroot (especially as the M-A paths differ, as
> I have x32, i386 *and* amd64 chroots).
This is not strictly related to the M-A, but more than the move of the
library, from /usr/lib/libeatmydata/libeatmydata.so to
/usr/lib/<triplet>/libeatmydata.so....
In particular I didn't though about wheezy chroots. While I this of a
fix for this, you can install the sid package in the chroot (it
works... in fact I didn't note this because I did so many many month
ago...).
> To add insult to injury, eatmydata is *still* not M-A safe, as
It is.
> can easily be seen here:
>
> tglase@tglase:~ $ eatmydata bzip2 -h 2>&1 | head -2
> ERROR: ld.so: object '/usr/lib/x86_64-linux-gnux32/libeatmydata.so' from
> LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
> bzip2, a block-sorting file compressor. Version 1.0.6, 6-Sept-2010.
>
> ii bzip2 1.0.6-7 i386 high-quality
> block-sorting file compressor - ut
> ii eatmydata 82-2 all Library and
> utilities designed to disable fsync
> ii libeatmydata1:i386 82-2 i386 Library and
> utilities to disable fsync and frie
> ii libeatmydata1:x32 82-2 x32 Library and
> utilities to disable fsync and frie
>
> (My host system is x32.)
mattia@chase ~ % eatmydata bzip2 -h 2>&1 | head -2
bzip2, a block-sorting file compressor. Version 1.0.6, 6-Sept-2010.
mattia@chase ~ % dpkg -l | egrep (eatmydata|bzip2)
ii bzip2 1.0.6-7
amd64 high-quality block-sorting file compressor -
utilities
ii eatmydata 82-1
all Library and utilities designed to disable fsync
and friends
ii libeatmydata1:amd64 82-1
amd64 Library and utilities to disable fsync and friends
- shared library
ii libeatmydata1:armel 82-1
armel Library and utilities to disable fsync and friends
- shared library
ii libeatmydata1:armhf 82-1
armhf Library and utilities to disable fsync and friends
- shared library
ii libeatmydata1:i386 82-1
i386 Library and utilities to disable fsync and friends
- shared library
ii libeatmydata1:s390x 82-1
s390x Library and utilities to disable fsync and friends
- shared library
ii pbzip2 1.1.9-1
amd64 parallel bzip2 implementation
mattia@chase ~ %
(host amd64)
I really don't understand why you got that message, if you have
completely installed the package (as dpkg says)
> So, running “eatmydata foo” *still* does not properly load the
> libeatmydata.so required for foo’s architecture. (Even if it did,
> “foo” may run “bar”, which can be yet *another* architecture, in
> a subshell.)
Maybe with the `eatmydata` command, but not if you preload the library
as I can show you:
mattia@chase /tmp/coreutils/bin % eatmydata ./cat /tmp/foo
ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libeatmydata.so' from
LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
hello
mattia@chase /tmp/coreutils/bin %
LD_PRELOAD="${LD_PRELOAD:+$LD_PRELOAD:}libeatmydata.so" ./cat /tmp/foo
hello
mattia@chase /tmp/coreutils/bin % file ./cat
./cat: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=191f9fcaebd6ceb37b64a8d3222a67b8a59720e5, stripped
(host amd64)
Ideally I can fix the eatmydata script removing the path, but I'm not
sure of it's really the correct fix.
> To make things short, the M-A changes do not help anything but
> add breakage. Sorry about that.
I have here a bunch of pbuilder chroots, for amd64 arm64 armel armhf
i386 s390x, all of them using libeatmydata. And I use this very
package since quite a year or so.
Now, of course I never tried x32, I don't know if it's something
arch-specific (but I don't think so)
Maybe it does not offer a very very very clean upgrade path (as
#765572 pointed out) and can break scripts where people hard-coded
paths (but we both know it shouldn't be done, even if it looks like
two package did so, I'm going to file bugs), but it does not break
everything as seems to you (and in fact look)
Summing up, the issues you reported are:
1) does not work a sid host (82-2) <-> wheezy chroot (26-1) → I'll
think about a solution
2) your system doesn't preload the library in x32, even if it is
installed → can you tell me if other systems give you the same issue?
--
regards,
Mattia Rizzolo
GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
