On Sun, Aug 11 2019, adr <a...@sdf.org> wrote: >> Switching a bunch of ports to gcc is not the answer. > > The answer is to talk with the developers of each of these ports > and show them the problems they'll find with llvm, so maybe they > re-implement the assembly optimization following the ARM conventions. > That was my advice to the ffmpeg and x264 maintainer. Or study each > of these ports and rewrite yourself the code, if you like.
> Meanwhile, > the only thing you can do is to disable the assembly if that is > possible, Looks like the sanest alternative indeed. > or try to compile it with gcc. That was the case of mupdf. --8<-- revision 1.89 date: 2019/07/30 15:59:48; author: sthen; state: Exp; lines: +7 -5; commitid: a8XfL4d8h3TFscT1; build MuPDF with gcc on armv7, problem reported by adr at sdf.org in https://marc.info/?l=openbsd-ports&m=156448467232400&w=2 - Bus error at runtime - suspect possible alignment issue? -->8-- It's not clear to me that assembly code is the culprit here. > If that is for you "Switching a bunch of ports to gcc"... good for you. > > I'm been using OpenBSD for two weeks or so. I'm just reporting > things that I found wrong. If what I receive in response is this > kind of pedantic statements, don't worry, I will not report anything > more. I agree with Stuart's statement. It may be terse but I don't find it pedantic. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
