bug#42891: 28.0.50; High Sierra Macos build failure

[Alan Third]

On Sun, Aug 16, 2020 at 05:57:45PM +0200, Lars Ingebrigtsen wrote:
> 
> I set up a bunch of VMs with different Macos versions, and Emacs builds
> fine on Mojave and Catalina, but not High Sierra (which is the oldest of
> the supported Macos versions).
> 
> It fails with
> 
> /Library/Developer/CommandLineTools/usr/bin/make -C ../lisp update-subdirs
> cp -f temacs bootstrap-emacs
> rm -f bootstrap-emacs.pdmp
> ./temacs --batch  -l loadup --temacs=pbootstrap
> make[2]: *** [bootstrap-emacs.pdmp] Segmentation fault: 11 (core dumped)
> make[1]: *** [src] Error 2
> make: *** [bootstrap] Error 2
> 
> Larss-iMac:trunk larsi$ gcc --version
> Configured with: --prefix=/Library/Developer/CommandLineTools/usr 
> --with-gxx-include-dir=/usr/include/c++/4.2.1
> Apple LLVM version 10.0.0 (clang-1000.10.44.4)
> Target: x86_64-apple-darwin17.7.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
> 
> I don't know whether we care about this system or not?  Is that a
> too-old clang version for us to worry about this?

As far as I'm aware we should be able to build on anything back to
10.6, so it should work fine on High Sierra. I've never come across
this problem, though.

> I'm completely unfamiliar with how lldb works...  this backtrace doesn't
> looke very useful?
> 
> Larss-iMac:trunk larsi$ lldb src/temacs --core /cores/core.36630 
> (lldb) target create "src/temacs" --core "/cores/core.36630"
> warning: (x86_64) /cores/core.36630 load command 200 LC_SEGMENT_64 has a 
> fileoff + filesize (0x4ead2000) that extends beyond the end of the file 
> (0x4ead1000), the segment will be truncated to match
> warning: (x86_64) /cores/core.36630 load command 201 LC_SEGMENT_64 has a 
> fileoff (0x4ead2000) that extends beyond the end of the file (0x4ead1000), 
> ignoring this section
> Core file '/cores/core.36630' (x86_64) was loaded.
> (lldb) bt all
> * thread #1, stop reason = signal SIGSTOP
>   * frame #0: 0x00007fff50f81993 
> libsystem_platform.dylib`_platform_memmove$VARIANT$Base + 1875
>   thread #2, stop reason = signal SIGSTOP
>     frame #0: 0x00007fff50dc028a libsystem_kernel.dylib`__workq_kernreturn + 
> 10
>     frame #1: 0x00007fff50f8720e libsystem_pthread.dylib`_pthread_wqthread + 
> 1552
>     frame #2: 0x00007fff50f86be9 libsystem_pthread.dylib`start_wqthread + 13
>   thread #3, stop reason = signal SIGSTOP
>     frame #0: 0x00007fff50dc028a libsystem_kernel.dylib`__workq_kernreturn + 
> 10
>     frame #1: 0x00007fff50f87009 libsystem_pthread.dylib`_pthread_wqthread + 
> 1035
>     frame #2: 0x00007fff50f86be9 libsystem_pthread.dylib`start_wqthread + 13

No, it looks like it crashed before it even got to our code as I would
expect to see main() or something listed in thread #1's backtrace. My
first suspicion would be there's something wrong with the build
environment. *grasping at straws* It didn't run out of disk space or
something?
-- 
Alan Third