similar to: run libvirt API on arm hardware platform

Hi, peter green wrote: > On 18/05/16 04:50, Tim Northover wrote: > If you don't need/want the various Sanitizer runtimes (e.g. you don't > support sanitizers or already have versions provided with GCC) then > it's as easy as not downloading compiler-rt or removing it from the > projects/ directory before running CMake. The build should carry on > quite happily

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

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, 1:20 PM, Tim Northover wrote: [...] > You should probably be specifying a triple directly, and making it an > AAPCS-VFP one for good measure: "armv7-linux-gnueabihf" for example, > or "thumbv7-none-eabihf". You shouldn't even need to set FloatABI for > those two. How do I do this? (I can't find any examples, and the API is decidedly unclear...)

tags 618616 pending stop On Wed, 16 Mar 2011, Lo?c Minier wrote: > I've fixed this in Ubuntu with the attached patch, but didn't find > where to upstream it; since you're a klibc upstream developer and since > it probably already affects Debian, I figured it was probably best to > send it here :-) thank you applied after review by hpa and pushed out to klibc git.

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

hi, recently i've been busy with libvirt(d) v1.2.0 on armhf and i see, even if selinux sec driver is enabled on the configure stage, the driver is not finally created. these configure parameters are: --with-selinux --with-secdriver-selinux --with-selinux-mount=/sys/fs/selinux the /sys/fs/selinux is valid, selinux is running in permissive mode, got also libselinux DEV package installed, so

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 r-base-core package for R 3.6.3, but not R 4.0.2, built for ARM.) If there

On 01/13/2014 04:50 PM, Michal Privoznik wrote: > On 13.01.2014 16:10, Ivan Gooten wrote: >> hi, >> >> recently i've been busy with libvirt(d) v1.2.0 on armhf and i see, even >> if selinux sec driver is enabled on the configure stage, the driver is >> not finally created. these configure parameters are: >> >> --with-selinux >>

On some cpu's optimized chacha implementation in openssl (1.1.0+) is notably faster (and on others it is just faster) than generic C implementation in openssh. Sadly, openssl's chacha20-poly1305 (EVP_chacha20_poly1305) uses different scheme (with padding/etc - see rfc8439) and it looks it is not possible to use in openssh. OpenSSL 1.1.1+ also exports "raw" poly1305 primitive,

Hi, things are progressing slowly, but I feel that eventually I'll be getting there: supermin can be built on all Linux-based architectures that are part of Debian/unstable[1] -- (except for sparc, but I'll ignore that for now.) libguestfs on the other hand currently fails launching the appliance (necessary for running tests) on everything but x86 and mips. Apparently, qemu-system-arm

I have several devices, mostly amd64 and armhf architectures, all of which updated samba to 4.17.6 without any problems. But one which is armel architecture failed to update; instead I get the following when I try to update: root at goflex:~# samba -V Version 4.17.5-Debian root at goflex:~# apt update Hit:1 http://ftp.uk.debian.org/debian bullseye InRelease Get:2 http://ftp.uk.debian.org/debian

The obvious difference is that you're using --enable-optimized and implicitly --disable-assertions. If you run the tests with make check-all VERBOSE=1 'LIT_ARGS=-v ' > logfile and grep for FAILED in logfile, does what's listed there give any more details? (Quite possible in a Release-Asserts build it might not.) Cheers, Dave -----Original Message----- From: cfe-dev-bounces

On 17/05/16 18:07, Tim Northover wrote: > Yes, it looks like we'd need to conditionally compile these functions > in ARM mode and use the v6 barrier instead of dmb ("mcr p15, #0, r0, > c7, c10, #5" I believe) to support the ARM1176JZF-S in RPi. You'd > probably also want the build system to use an explicit -march=armv6 or > something so you're not at the mercy

Add the possibility to choose which architecture use to build the wanted image (--arch). Since this implies that running commands on the guest is usually not possible when the architecture is different than the host one, another new option (--allow-foreign-arch-ops) allows to run commands nevertheless. The caching scheme is adapted to account for the architecture (with --print-cache showing the

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

IMPORTANT! IMPORTANT! IMPORTANT! We will be branching for the 3.1 release on April 16th! :-) This gives us a little over two weeks to get the trees into the most stable condition we can. What this means for you: All major features for the 3.1 release should be finished or near completion by the April 16th. After April 16th, we will accept only bug fixes and patches which do not change the

On Fri, 2019-07-12 at 15:54 +1000, Damien Miller wrote: > On Thu, 17 Jan 2019, Yuriy M. Kaminskiy wrote: > > > On some cpu's optimized chacha implementation in openssl (1.1.0+) > > is > > notably faster (and on others it is just faster) than generic C > > implementation in openssh. > > > > Sadly, openssl's chacha20-poly1305

On Tue, Feb 18, 2014 at 09:10:58AM +0100, Martin Kletzander wrote: > On Mon, Feb 17, 2014 at 05:01:05PM +0100, Niccolo Rigacci wrote: > > Hi, > > > > I'm trying to use libvirt for an armel virtual machine hosted > > into an x86_64 box. > > > > I know the command line to start qemu-system-arm directly, but I > > cannot figure a proper .xml

This patch series fixes the way supermin sorts the list of installed packages when resolving a name, picking the right package for the host architecture. Pino Toscano (5): rpm: do not unpack parameters rpm: fix version comparison rpm: query the RPM architecture rpm: fix package sorting (RHBZ#1696822) utils: remove unused 'compare_architecture' function src/librpm-c.c | 10