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.
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 <[email protected]> Sent: January 11, 2019 11:34 AM To: Mathieu Malaterre <[email protected]> Cc: [email protected]; Mark Cave-Ayland <[email protected]>; Calvin Buckley <[email protected]> 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.
