similar to: Binary packages or R 3.4.2 for armhf and arm64 (Debian stretch)

Hi, we?re currently seeing trouble with klibc on several architectures, cf. http://www.zytor.com/pipermail/klibc/2012-May/003277.html and armhf is being one of them, when using klibc to compile mksh-static with it. I can look into it (asked zumbi for build-deps in a sid chroot on harris already), but not 100% sure I?ll find it, so more eyes on klibc would not be unwelcome ;-) maks, does klibc

On 7/23/14, 3:30 PM, Tim Northover wrote: [...] > It looks like it's a case of calling Module::setTargetTriple. As with > most JIT setup questions, though, often the best way to find out is to > get something working in lli and then look at what it does > (tools/lli/lli.cpp). Well, it's *almost* working --- hardfloat code is now being generated, and it even seems to be right

I'm using the Debian LLVM package to try and do JIT on a Linux armhf device. Unfortunately it seems to be generating armel code rather than armhf code, and since the ABIs don't match nothing works. I've tried overriding the triple to arm-unknown-linux-gnueabihf and arm-linux-gnueabihf (via module->setTargetTriple), and while the triples are accepted, the actual generated code

This one's for maks' git, not for hpa's. Tell klibc what the compiler defaults already require: armhf is thumb. Signed-off-by: Thorsten Glaser <tg at mirbsd.org> --- debian/rules | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/rules b/debian/rules index 1fb4c44..ec55d7d 100755 --- a/debian/rules +++ b/debian/rules @@ -10,7 +10,7 @@ ifeq

Hello, Last year I tried --- and failed --- to generate float-heavy ARM code via the JIT on an armhf platform. No matter what I did, it would always generate armel code instead. This was on LLVM 3.2, which was all that was available then. Now I'm running into a requirement to do this again: while it's much less crashy than it was, I still can't seem to persuade the JIT to generate

Source: systemd Version: 257.1-5 Severity: normal Tags: patch X-Debbugs-Cc: maxi at daemonizer.de, xen at packages.debian.org Control: affects -1 + src:xen Starting with version 4.19, the xen package in Debian stopped building xen on the armhf architecture. Your package currently depends on libxen-dev on the armhf architecture, please remove that dependency as the armhf package is going away

llvm-toolchain-3.8 seems to have problems on debian armel and raspbian. On raspbian it builds but our armv7 contamination checker blocked it from entering the repo. Further investigation showed that "compiler-rt" was being built with -march=armv7 . I was able to remove the -march with some build-system hacker but then I got a failure on

On 15 July 2020 at 14:03, Paul Teetor wrote: | Dear R-SIG-Debian folks, | | I seem to be chasing my tail, despite having a simple goal: | | - Install R 4.0.2 | - On Ubuntu 20.04 | - For an ARM processor (not Intel/AMD). | | Can someone please suggest a Debian/Ubuntu repository of the required packages (e.g., r-base-core) built for ARM? I can't seem to find one. | | (I can find the

On 7/24/14, 7:18 AM, Tim Northover wrote: [...] > Which triple are you using? And is the correct code used when you run > the same IR through "llc -mtriple=whatever"? armv7-linux-gnueabihf, as suggested; and if I use llc -mtriple then the code compiles to: vstr s0, [r0] bx lr ...which I would consider correct. (What's more interesting is *without* specifying the triple

Hi, requests regarding the backports in the official Debian backport repositories (like jessie-backports) should go to the debian-science list. For stretch, I uploaded a backport of R 3.4.3 including the armhf architecture to CRAN https://cran.r-project.org/bin/linux/debian/#supported platforms but I don't know if you are looking for arm64? Kind regards, Johannes Am Donnerstag, 4.

Thank you very much, Dirk. That nudge solved the problem, of course. I am embarrassed. I was so fixated on Ubuntu repositories that I neglected to check the Debian 'testing' world! Regarding the RPi: The RPi 4 uses the 'arm64' architecture, the full 64-bit one. I stopped using dedicated distros, such as Raspian, when Ubuntu went all-in on RPi support, which happened in their

Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.8 Date: Sat, 30 Aug 2014 13:34:04 +0200 Source: xen Binary: libxen-4.4 libxenstore3.0 libxen-dev xenstore-utils xen-utils-common xen-utils-4.4 xen-hypervisor-4.4-amd64 xen-system-amd64 xen-hypervisor-4.4-arm64 xen-system-arm64 xen-hypervisor-4.4-armhf xen-system-armhf Architecture: source all Version: 4.4.0-4 Distribution:

Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.8 Date: Sun, 21 Sep 2014 10:45:47 +0200 Source: xen Binary: libxen-4.4 libxenstore3.0 libxen-dev xenstore-utils xen-utils-common xen-utils-4.4 xen-hypervisor-4.4-amd64 xen-system-amd64 xen-hypervisor-4.4-arm64 xen-system-arm64 xen-hypervisor-4.4-armhf xen-system-armhf Architecture: source all Version: 4.4.1-1 Distribution:

Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.8 Date: Wed, 24 Sep 2014 20:23:14 +0200 Source: xen Binary: libxen-4.4 libxenstore3.0 libxen-dev xenstore-utils xen-utils-common xen-utils-4.4 xen-hypervisor-4.4-amd64 xen-system-amd64 xen-hypervisor-4.4-arm64 xen-system-arm64 xen-hypervisor-4.4-armhf xen-system-armhf Architecture: source all Version: 4.4.1-2 Distribution:

Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Format: 1.8 Date: Tue, 19 Jan 2016 14:43:54 +0000 Source: xen Binary: libxen-4.6 libxenstore3.0 libxen-dev xenstore-utils xen-utils-common xen-utils-4.6 xen-hypervisor-4.6-amd64 xen-system-amd64 xen-hypervisor-4.6-arm64 xen-system-arm64 xen-hypervisor-4.6-armhf xen-system-armhf Architecture: source Version: 4.6.0-1+nmu1 Distribution:

Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Format: 1.8 Date: Tue, 09 Feb 2016 16:41:16 +0000 Source: xen Binary: libxen-4.6 libxenstore3.0 libxen-dev xenstore-utils xen-utils-common xen-utils-4.6 xen-hypervisor-4.6-amd64 xen-system-amd64 xen-hypervisor-4.6-arm64 xen-system-arm64 xen-hypervisor-4.6-armhf xen-system-armhf Architecture: source Version: 4.6.0-1+nmu2 Distribution:

Mapping stable-security to proposed-updates. Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Tue, 19 Apr 2016 20:42:09 +0200 Source: xen Binary: libxen-4.4 libxenstore3.0 libxen-dev xenstore-utils xen-utils-common xen-utils-4.4 xen-hypervisor-4.4-amd64 xen-system-amd64 xen-hypervisor-4.4-arm64 xen-system-arm64 xen-hypervisor-4.4-armhf xen-system-armhf Architecture:

Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Tue, 19 Apr 2016 20:42:09 +0200 Source: xen Binary: libxen-4.4 libxenstore3.0 libxen-dev xenstore-utils xen-utils-common xen-utils-4.4 xen-hypervisor-4.4-amd64 xen-system-amd64 xen-hypervisor-4.4-arm64 xen-system-arm64 xen-hypervisor-4.4-armhf xen-system-armhf Architecture: all source Version: 4.4.1-9+deb8u5

Mapping stable-security to proposed-updates. Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Sat, 31 Oct 2015 06:53:56 +0100 Source: xen Binary: libxen-4.4 libxenstore3.0 libxen-dev xenstore-utils xen-utils-common xen-utils-4.4 xen-hypervisor-4.4-amd64 xen-system-amd64 xen-hypervisor-4.4-arm64 xen-system-arm64 xen-hypervisor-4.4-armhf xen-system-armhf Architecture:

Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Sat, 31 Oct 2015 06:53:56 +0100 Source: xen Binary: libxen-4.4 libxenstore3.0 libxen-dev xenstore-utils xen-utils-common xen-utils-4.4 xen-hypervisor-4.4-amd64 xen-system-amd64 xen-hypervisor-4.4-arm64 xen-system-arm64 xen-hypervisor-4.4-armhf xen-system-armhf Architecture: all source Version: 4.4.1-9+deb8u2