similar to: Bug#749060: klibc: ppc64el needs static binaries as well

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

Hi maks, Adding Anton in CC (who submitted klibc ppc64le support upstream [1]), in case he can help. >> The ppc64el port needs klibc's static binaries, like ppc64. > > This segfaulting is a bug in klibc that needs investigation. > >> This patch enables the ARCH=ppc64 make env var in debian/rules, in order >> for 'debian/patches/ppc64-static.patch' to take

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 Mauricio Faria de Oliveira dixit: >> [...] Effort in making shared binary >> working too is appreciated. It is probably a wrong syscall API. > > Unfortunately I don't find myself in klibc expertise area. I can try, > but maybe it's not the effective way forward (not sure I'd be able to > devote the effort/time

--- src/kernel.ml | 2 ++ src/utils.ml | 2 ++ 2 files changed, 4 insertions(+) diff --git a/src/kernel.ml b/src/kernel.ml index 356ac4b..9b0e8a2 100644 --- a/src/kernel.ml +++ b/src/kernel.ml @@ -30,6 +30,8 @@ let patt_of_cpu host_cpu = | "ppc" | "powerpc" | "powerpc64" -> ["ppc"; "powerpc"; "powerpc64"] |

Hum, at least it is not Apple, so maybe you can attach a debugger to the running process? (gdb -p process_id or something like that --- haven't actually done it for a decade). Then at least we can get a stack trace and a clue about where it is looping. Diddling optimization options can also sometimes provide a clue. -pd > On 29 Apr 2020, at 01:17 , Dirk Eddelbuettel <edd at

On 30 April 2020 at 09:11, luke-tierney at uiowa.edu wrote: | On Thu, 30 Apr 2020, Dirk Eddelbuettel wrote: | Maybe I missed something. How is the 'compiler' package involved? See the other email thread; you replied (~ 26 hours ago) to my message adding that "sysdata.rda in 'tools' hanging was wrong". It gets to the next stage, which is 'compiler'. We know by

https://bugzilla.mindrot.org/show_bug.cgi?id=3645 Bug ID: 3645 Summary: -fzero-call-used-regs=used detection seems to fail on Linux ppc64el Product: Portable OpenSSH Version: 9.6p1 Hardware: PPC64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: Build

On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <edd at debian.org> wrote: > > > On 29 April 2020 at 11:22, peter dalgaard wrote: > | Hum, at least it is not Apple, so maybe you can attach a debugger to the running process? (gdb -p process_id or something like that --- haven't actually done it for a decade). Then at least we can get a stack trace and a clue about where it is

On Thu, 30 Apr 2020, Dirk Eddelbuettel wrote: > > On 30 April 2020 at 09:42, I?aki Ucar wrote: > | On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <edd at debian.org> wrote: > | > And to keep the list abreast, this appears to be related to the long double > | > issue on powerpc where needed an extra #define to ensure compilation. That > [...] > | Which reminds me

The R 4.0.0 package migration on Debian is being held back by a failed build on ppc64el [1]. We can see from the history of builds logs [2] that it used to build, briefly failed, worked again and then failed leading to R 4.0.0's release. (And my bad for missing how the alpha1/alpha2/beta/rc builds failed.) I have however neither changed anything, nor did I ever have to accomodate ppc64el (as

On 29 April 2020 at 11:22, peter dalgaard wrote: | Hum, at least it is not Apple, so maybe you can attach a debugger to the running process? (gdb -p process_id or something like that --- haven't actually done it for a decade). Then at least we can get a stack trace and a clue about where it is looping. Diddling optimization options can also sometimes provide a clue. (Missed this earlier as

On 30 April 2020 at 09:42, I?aki Ucar wrote: | On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <edd at debian.org> wrote: | > And to keep the list abreast, this appears to be related to the long double | > issue on powerpc where needed an extra #define to ensure compilation. That [...] | Which reminds me that [1] was required for v3.6.2. Could be related? Yes, that is what I refered

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

( Posting again. Correct subject line now! ) Hello, I'm trying to use macvtap on Debian Wheezy. Actually, I've installed a recent version of libvirt and qemu from Jessie, using wheezy-backports. $ virsh version Compiled against library: libvirt 1.2.1 Using library: libvirt 1.2.1 Using API: QEMU 1.2.1 Running hypervisor: QEMU 1.7.0 I'm trying to configure a macvtap interface like

Hai...   Finaly im passed all errors, some problem with meself.. , some the code. ..    Lots of thank to the samba devs, that gave the clue to fix the last parts. :-)) whoehoe..   Its still in the stretch-experimental repo, and if the feedback is ok, i'll make the final build tomorrow. Testing can be done with Debian Stretch or Ubuntu 18.04 amd64 or Devuan ASCII AMD64 only.   #setup: get

V4 of the patch, incorporating Bastian's suggestions. Jon --- xen/debian/patches/series | 1 + xen/debian/patches/tools-ocaml-fix-build.diff | 81 +++++++++++++++++++++++++ xen/debian/rules | 5 ++ xen/debian/rules.real | 39 ++++++++++++ xen/debian/templates/control.main.in | 16 +++++

Hi, I have been trying to catch up my Debian packages to the current 1.27 branch of libguestfs (and uploaded those packages to experimental), but apparently the build was broken for architectures where no native OCaml compiler is available because make wanted to build .cmx files -- see <https://buildd.debian.org/status/package.php?p=libguestfs&suite=experimental>. So far mips[1],

Hi, it seems that even after commit df5bd5741b37da9cf97d7a76ac2805557aa630db Author: Richard W.M. Jones <rjones@redhat.com> Date: Tue Apr 29 15:43:20 2014 +0100 builder: Fix parallel builds of index-parse.o. there is a small chance that a build may go wrong with the described symtom, missing "do_parse" symbol. It just happened to me on Debian's ppc64el buildd[1] and

As you may know, I look after the R package for Debian. My fellow Debianers make me follow a specific protocol -- a so-called "transition" in which all dependent packages on an identified potential breakge are rebuilt under the new (potentially breaking) change. We started adding an r-api-3.4 tag last (major) release. Now it is r-api-3.5 and the transition got started with the green

Hi Lists, I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform. It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu when starting an instance, as without that, it will only use one thread and hence of limited/no use. The problem is, that libvirt itself, passes “-machine q35,accel=tcg” to qemu, which is a different parameter, that