Hi, On Fri, Jan 11, 2019 at 5:29 PM <cal...@cmpct.info> wrote: > > I don't think I've seen anything like this - maybe when I was trying to > get Boehm-GC working? I'll note that I haven't really poked ppc32 *or* > Linux either. I'm considering cc'ing another person who knows more > ppc32/linux than I do.
I remember that sgen vs boehm was an issue in the past. I'll try to go through the diff and check what was the old patch doing. > Reading the code, (and the fact that the stack trace is truncated...) > CreatePointerOperatorsTable is in between a bunch of other methods like > it. Unlike say, CreateStandardOperatorsTable, it *does* have nulls in > it, but you'd see issue son other platforms is this was problematic, > no? Feels almost like a JIT issue or memory (like heap corruption?) > > Wait, I just got another email as I was writing this one. SIGILL? It > looks like it just jumped to the middle of nowhere. (which on AIX, I'd > get disturbingly often because 0x0 is both mapped and RWX, which is > explicitly invalid on PPC - for that I slapped down explicit null > checking, which isn't the problem here) > > -----Original Message----- > From: Jo Shields <direct...@apebox.org> > Sent: January 11, 2019 11:34 AM > To: Mathieu Malaterre <ma...@debian.org> > Cc: 918...@bugs.debian.org; Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>; > Calvin Buckley <cal...@cmpct.info> > Subject: Re: Bug#918976: include/openssl/base.h:107:2: error: #error "Unknown > target CPU" > > > On 11/01/2019 10:22, Mathieu Malaterre wrote: > > However the build failed for me later on, reporting a failure to find > > 'mcs' (*). My G4 is rather slow so let me try again to check there are > > no other build failure later on. Mark do you have a faster ppc machine > > ? > > > > (*)if test -w /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs; then > > :; else chmod -R +w > > /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs; fi > > cd /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs && make > > --no-print-directory -s NO_DIR_CHECK=1 > > PROFILES='binary_reference_assemblies net_4_x xbuild_12 xbuild_14 > > ' CC='gcc' all-profiles > > mkdir -p -- build/deps > > make[7]: mcs: Command not found > > > The class library needs a C# compiler, so first it checks whether you > have one in $PATH it can use. It is normal that you wouldn't have one > (and it would likely be too out of date anyway, and get rejected) > > > > make[7]: *** [build/profiles/basic.make:118: > > build/deps/basic-profile-check.exe] Error 127 > > *** The runtime 'mono' doesn't appear to be usable. > > *** Trying the 'monolite-linux/1051600014' directory. > > > Now it's looking at the bootstrap compiler bundled into the source > package, and checking the version on it. > > > > Unhandled Exception: > > System.NullReferenceException: Object reference not set to an instance > > of an object > > at Mono.CSharp.Binary.CreatePointerOperatorsTable > > (Mono.CSharp.BuiltinTypes types) [0x0006b] in > > <9d70195405974ada92fc07fda5c6d57c>:0 > > [ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: > > Object reference not set to an instance of an object > > at Mono.CSharp.Binary.CreatePointerOperatorsTable > > (Mono.CSharp.BuiltinTypes types) [0x0006b] in > > <9d70195405974ada92fc07fda5c6d57c>:0 > > > Here's a real problem - the runtime is totally screwing up the basic > compiler check. Looping in Calvin (HI CALVIN!) - does the above look > familiar, in any of your PowerPC tinkering? > > > > make[9]: *** [build/profiles/basic.make:118: > > build/deps/basic-profile-check.exe] Error 1 > > *** The contents of your 'monolite-linux/1051600014' directory may be > > out-of-date > > *** You may want to try 'make get-monolite-latest' > > > The build system gives up as it can't find a viable compiler to use. > >
