Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Issues installing libc6:arm64 on amd64
1,997 views
Skip to first unread message
Witold Baryluk
Nov 20, 2020, 10:10:03 AM11/20/20
to
Hi,
I am not sure if this is the best mailing list, but couldn't find
anything fitting better.
I am using Debian testing on amd64.
I am interested in testing qemu-user-aarch64 on my amd64 machine, so
instead of setting up chroots, I decided to just try to use multi-arch
and install some libraries and linkers, and then see from there.
Unfortunately, it didn't work well for arm64.
$ dpkg --add-architecture arm64
$ apt update
$ apt install libc6:arm64 libgcc-s1:arm64 gcc-10-base:arm64
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
adduser : Depends: passwd
Depends: debconf (>= 0.5) but it is not going to be installed or
debconf-2.0
emacs-nox : Depends: emacs-bin-common (= 1:27.1+1-3) but it is not
going to be installed
Depends: emacs-common (= 1:27.1+1-3) but it is not going
to be installed
Depends: libacl1 (>= 2.2.23) but it is not going to be installed
Depends: libasound2 (>= 1.0.16)
Depends: libdbus-1-3 (>= 1.9.14) but it is not going to
be installed
Depends: libgmp10 (>= 2:6.0.0) but it is not going to be installed
Depends: libgnutls30 (>= 3.6.14) but it is not going to
be installed
Depends: libgpm2 (>= 1.20.7) but it is not going to be installed
Depends: libjansson4 (>= 2.7) but it is not going to be installed
Depends: liblcms2-2 (>= 2.2+git20110628) but it is not
going to be installed
Depends: libselinux1 (>= 3.1~) but it is not going to be installed
Depends: libxml2 (>= 2.7.4) but it is not going to be installed
erlang-crypto : Depends: libssl1.1 (>= 1.1.1) but it is not going to
be installed
hunspell-fr : Depends: hunspell-fr-classical but it is not going to
be installed or
hunspell-fr-modern but it is not going to be
installed or
hunspell-fr-revised but it is not going to be
installed or
hunspell-fr-comprehensive but it is not going
to be installed
libc6 : Depends: libgcc-s1 but it is not installable
Depends: libcrypt1 but it is not going to be installed
Depends: libnss-nis but it is not going to be installed
Depends: libnss-nisplus but it is not going to be installed
Recommends: libidn2-0 (>= 2.0.5~) but it is not going to be installed
libssl1.1:arm64 : Depends: debconf:arm64 (>= 0.5) or
debconf-2.0:arm64
libsystemd0 : PreDepends: libgcrypt20 (>= 1.8.0) but it is not going
to be installed
PreDepends: liblz4-1 (>= 0.0~r122) but it is not going
to be installed
PreDepends: liblzma5 (>= 5.1.1alpha+20120614) but it is
not going to be installed
PreDepends: libzstd1 (>= 1.4.0) but it is not going to
be installed
procps : Depends: libncurses6 (>= 6) but it is not going to be installed
Depends: libncursesw6 (>= 6) but it is not going to be installed
Depends: libprocps8 (>= 2:3.3.16-1) but it is not going to
be installed
Depends: init-system-helpers (>= 1.29~) but it is not going
to be installed
Recommends: psmisc
E: Error, pkgProblemResolver::Resolve generated breaks, this may be
caused by held packages.
$
I tried the same with `armhf`, and apt install libc6:armhf
libgcc-s1:armhf gcc-10-base:armhf , installed without issues.
Any help? Is this some transient issue with the repository?
Cheers,
Witold
I am not sure if this is the best mailing list, but couldn't find
anything fitting better.
I am using Debian testing on amd64.
I am interested in testing qemu-user-aarch64 on my amd64 machine, so
instead of setting up chroots, I decided to just try to use multi-arch
and install some libraries and linkers, and then see from there.
Unfortunately, it didn't work well for arm64.
$ dpkg --add-architecture arm64
$ apt update
$ apt install libc6:arm64 libgcc-s1:arm64 gcc-10-base:arm64
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
adduser : Depends: passwd
Depends: debconf (>= 0.5) but it is not going to be installed or
debconf-2.0
emacs-nox : Depends: emacs-bin-common (= 1:27.1+1-3) but it is not
going to be installed
Depends: emacs-common (= 1:27.1+1-3) but it is not going
to be installed
Depends: libacl1 (>= 2.2.23) but it is not going to be installed
Depends: libasound2 (>= 1.0.16)
Depends: libdbus-1-3 (>= 1.9.14) but it is not going to
be installed
Depends: libgmp10 (>= 2:6.0.0) but it is not going to be installed
Depends: libgnutls30 (>= 3.6.14) but it is not going to
be installed
Depends: libgpm2 (>= 1.20.7) but it is not going to be installed
Depends: libjansson4 (>= 2.7) but it is not going to be installed
Depends: liblcms2-2 (>= 2.2+git20110628) but it is not
going to be installed
Depends: libselinux1 (>= 3.1~) but it is not going to be installed
Depends: libxml2 (>= 2.7.4) but it is not going to be installed
erlang-crypto : Depends: libssl1.1 (>= 1.1.1) but it is not going to
be installed
hunspell-fr : Depends: hunspell-fr-classical but it is not going to
be installed or
hunspell-fr-modern but it is not going to be
installed or
hunspell-fr-revised but it is not going to be
installed or
hunspell-fr-comprehensive but it is not going
to be installed
libc6 : Depends: libgcc-s1 but it is not installable
Depends: libcrypt1 but it is not going to be installed
Depends: libnss-nis but it is not going to be installed
Depends: libnss-nisplus but it is not going to be installed
Recommends: libidn2-0 (>= 2.0.5~) but it is not going to be installed
libssl1.1:arm64 : Depends: debconf:arm64 (>= 0.5) or
debconf-2.0:arm64
libsystemd0 : PreDepends: libgcrypt20 (>= 1.8.0) but it is not going
to be installed
PreDepends: liblz4-1 (>= 0.0~r122) but it is not going
to be installed
PreDepends: liblzma5 (>= 5.1.1alpha+20120614) but it is
not going to be installed
PreDepends: libzstd1 (>= 1.4.0) but it is not going to
be installed
procps : Depends: libncurses6 (>= 6) but it is not going to be installed
Depends: libncursesw6 (>= 6) but it is not going to be installed
Depends: libprocps8 (>= 2:3.3.16-1) but it is not going to
be installed
Depends: init-system-helpers (>= 1.29~) but it is not going
to be installed
Recommends: psmisc
E: Error, pkgProblemResolver::Resolve generated breaks, this may be
caused by held packages.
$
I tried the same with `armhf`, and apt install libc6:armhf
libgcc-s1:armhf gcc-10-base:armhf , installed without issues.
Any help? Is this some transient issue with the repository?
Cheers,
Witold
Gene Heskett
Nov 20, 2020, 10:30:03 AM11/20/20
to
On Friday 20 November 2020 09:44:04 Witold Baryluk wrote:
> Hi,
>
> I am not sure if this is the best mailing list, but couldn't find
> anything fitting better.
>
>
> I am using Debian testing on amd64.
>
> I am interested in testing qemu-user-aarch64 on my amd64 machine, so
> instead of setting up chroots, I decided to just try to use multi-arch
> and install some libraries and linkers, and then see from there.
>
> Unfortunately, it didn't work well for arm64.
Whatever gave you the idea that arm (aarch64) software, any version,
> Hi,
>
> I am not sure if this is the best mailing list, but couldn't find
> anything fitting better.
>
>
> I am using Debian testing on amd64.
>
> I am interested in testing qemu-user-aarch64 on my amd64 machine, so
> instead of setting up chroots, I decided to just try to use multi-arch
> and install some libraries and linkers, and then see from there.
>
> Unfortunately, it didn't work well for arm64.
compiled for arm would run on amd64 hardware? Different cpu's and
architectures at the machine code level and they don't speak a
compatible dialect of native language. Compilers are generally smart
emough to make the src code work on either platform, but the binaries
output will be incompatible. At best it will crash.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Witold Baryluk
Nov 20, 2020, 11:30:03 AM11/20/20
to
> Whatever gave you the idea that arm (aarch64) software, any version,
> compiled for arm would run on amd64 hardware? Different cpu's and
> architectures at the machine code level and they don't speak a
> compatible dialect of native language. Compilers are generally smart
> emough to make the src code work on either platform, but the binaries
> output will be incompatible. At best it will crash.
This is totally off topic, and not what I am trying to do.
> compiled for arm would run on amd64 hardware? Different cpu's and
> architectures at the machine code level and they don't speak a
> compatible dialect of native language. Compilers are generally smart
> emough to make the src code work on either platform, but the binaries
> output will be incompatible. At best it will crash.
Here is an example of what I want to do, just with an example of
installing armhf libraries and binaries.
It works for running armhf on amd64.
$ uname -a
Linux debian 5.7.0-1-amd64 #1 SMP Debian 5.7.6-1 (2020-06-24) x86_64 GNU/Linux
$
$ sudo apt install zstd:armhf liblz4-1:armhf liblzma5:armhf
zlib1g:armhf libstdc++6:armhf
$ file /usr/bin/zstd
/usr/bin/zstd: ELF 32-bit LSB pie executable, ARM, EABI5 version 1
(SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3,
BuildID[sha1]=27f2fcd70757d9607d08566d82284817add19695, for GNU/Linux
3.2.0, stripped
$ qemu-arm /usr/bin/zstd -b /var/log/Xorg.0.log
3#Xorg.0.log : 78670 -> 10447 (7.530), 98.3 MB/s , 246.3 MB/s
$
totally works, with binfmt package, it works even more transparent:
$ /usr/bin/zstd -b /var/log/Xorg.0.log
3#Xorg.0.log : 78670 -> 10447 (7.530), 97.5 MB/s , 244.5 MB/s
$ file /usr/bin/zstd
/usr/bin/zstd: ELF 32-bit LSB pie executable, ARM, EABI5 version 1
(SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3,
BuildID[sha1]=27f2fcd70757d9607d08566d82284817add19695, for GNU/Linux
3.2.0, stripped
$
The issue is that, for some dependency / packaging reasons, I can't do
the same with arm64.
Also, I never claimed to want to run binaries from arm64 on amd64. I
want to INSTALL multi-arch libraries of arm64 on amd64. Different
things.
Cheers,
Witold
PS. I am now subscribed to the list, so I will be able to properly
respond in the same thread in the future.
Witold Baryluk
Nov 20, 2020, 12:10:04 PM11/20/20
to
This is just a follow up.
It was a repository having incompatible versions of packages for a
moment due to gcc-10-base rebuild.
arm64 had version 10.2.0-18
but
amd64 and i386 had version 10.2.0-17.
So it was not possible to install them at the same time.
They are now in sync, and installing libraries and binaries from arm64
on amd64 works. They execute correctly too.
user@debian:~$ uname -m
x86_64
user@debian:~$ file /usr/bin/zstd
/usr/bin/zstd: ELF 64-bit LSB pie executable, ARM aarch64, version 1
(SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1,
BuildID[sha1]=f7ae7d8114094829a26bb4f24ac992d58df1c5bb, for GNU/Linux
3.7.0, stripped
user@debian:~$ /usr/bin/zstd -b /var/log/Xorg.0.log
3#Xorg.0.log : 78787 -> 10456 (7.535), 157.2 MB/s , 355.0 MB/s
user@debian:~$
Nice!
It was a repository having incompatible versions of packages for a
moment due to gcc-10-base rebuild.
arm64 had version 10.2.0-18
but
amd64 and i386 had version 10.2.0-17.
So it was not possible to install them at the same time.
They are now in sync, and installing libraries and binaries from arm64
on amd64 works. They execute correctly too.
user@debian:~$ uname -m
x86_64
user@debian:~$ file /usr/bin/zstd
/usr/bin/zstd: ELF 64-bit LSB pie executable, ARM aarch64, version 1
(SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1,
BuildID[sha1]=f7ae7d8114094829a26bb4f24ac992d58df1c5bb, for GNU/Linux
3.7.0, stripped
user@debian:~$ /usr/bin/zstd -b /var/log/Xorg.0.log
3#Xorg.0.log : 78787 -> 10456 (7.535), 157.2 MB/s , 355.0 MB/s
user@debian:~$
Nice!
John Paul Adrian Glaubitz
Nov 20, 2020, 12:20:03 PM11/20/20
to
Hello Witold!
On 11/20/20 3:44 PM, Witold Baryluk wrote:
> I tried the same with `armhf`, and apt install libc6:armhf
> libgcc-s1:armhf gcc-10-base:armhf , installed without issues.
>
>
> Any help? Is this some transient issue with the repository?
I assume that you are doing this on Debian unstable as the package versions
indicate - posting your sources.list would help clarifying this question.
In unstable, package versions are constantly changing and for MultiArch to
work, the version numbers of library packages that are being co-installed
have to match.
I have not looked into the versions of the packages in question right now,
but the problem will simply be that any of the packages you are trying to
install, directly or through dependencies, are out of sync, either because
the arm64 buildds have not kept up with amd64 for any of the packages yet
or one of the packages in question failed to build from source.
So, to resolve this problem, use either stable or testing where packages can
not become out of sync or just wait for this transient situation to settle.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 11/20/20 3:44 PM, Witold Baryluk wrote:
> I tried the same with `armhf`, and apt install libc6:armhf
> libgcc-s1:armhf gcc-10-base:armhf , installed without issues.
>
>
> Any help? Is this some transient issue with the repository?
indicate - posting your sources.list would help clarifying this question.
In unstable, package versions are constantly changing and for MultiArch to
work, the version numbers of library packages that are being co-installed
have to match.
I have not looked into the versions of the packages in question right now,
but the problem will simply be that any of the packages you are trying to
install, directly or through dependencies, are out of sync, either because
the arm64 buildds have not kept up with amd64 for any of the packages yet
or one of the packages in question failed to build from source.
So, to resolve this problem, use either stable or testing where packages can
not become out of sync or just wait for this transient situation to settle.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Witold Baryluk
Nov 20, 2020, 12:30:03 PM11/20/20
to
Yes, you are right.
I am on unstable. And indeed it was package version mismatch in the repository. I wish apt was clear what is wrong :)
It works now!
I will switch to testing probably to have less issues with version mismatch.
Thanks!
Andrei POPESCU
Nov 20, 2020, 3:00:03 PM11/20/20
to
On Vi, 20 nov 20, 10:20:39, Gene Heskett wrote:
> On Friday 20 November 2020 09:44:04 Witold Baryluk wrote:
>
> > Hi,
> >
> > I am not sure if this is the best mailing list, but couldn't find
> > anything fitting better.
> >
> >
> > I am using Debian testing on amd64.
> >
> > I am interested in testing qemu-user-aarch64 on my amd64 machine, so
> > instead of setting up chroots, I decided to just try to use multi-arch
> > and install some libraries and linkers, and then see from there.
> >
> > Unfortunately, it didn't work well for arm64.
>
> Whatever gave you the idea that arm (aarch64) software, any version,
> compiled for arm would run on amd64 hardware? Different cpu's and
> architectures at the machine code level and they don't speak a
> compatible dialect of native language.
Unless I'm mistaken that's what qemu-user-aarch64 is for.
> On Friday 20 November 2020 09:44:04 Witold Baryluk wrote:
>
> > Hi,
> >
> > I am not sure if this is the best mailing list, but couldn't find
> > anything fitting better.
> >
> >
> > I am using Debian testing on amd64.
> >
> > I am interested in testing qemu-user-aarch64 on my amd64 machine, so
> > instead of setting up chroots, I decided to just try to use multi-arch
> > and install some libraries and linkers, and then see from there.
> >
> > Unfortunately, it didn't work well for arm64.
>
> Whatever gave you the idea that arm (aarch64) software, any version,
> compiled for arm would run on amd64 hardware? Different cpu's and
> architectures at the machine code level and they don't speak a
> compatible dialect of native language.
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Paul Wise
Nov 20, 2020, 9:00:03 PM11/20/20
to
On Fri, Nov 20, 2020 at 3:28 PM Gene Heskett wrote:
> Whatever gave you the idea that arm (aarch64) software, any version,
> compiled for arm would run on amd64 hardware?
It is pretty clear that is not what the poster was asking about, but
> Whatever gave you the idea that arm (aarch64) software, any version,
> compiled for arm would run on amd64 hardware?
there are two ways this can happen:
When your CPU supports multiple architectures at the same time. I
recently learned of a couple of vendors of CPUs that have a MIPSish
native ISA but also support MIPS, ARM, x86 and RISC-V (with the latter
3 being slower than the native ISA and MIPS).
When you install qemu-user-static and run the binaries on an amd64
system, or create an emulated machine using qemu-system-* and install
a full ARM OS in them.
--
bye,
pabs
https://wiki.debian.org/PaulWise
0 new messages