bug#42891: 28.0.50; High Sierra Macos build failure

bug#42891: 28.0.50; High Sierra Macos build failure

[Lars Ingebrigtsen]

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?

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



In GNU Emacs 28.0.50 (build 11, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
 of 2020-08-13 built on xo
Repository revision: 1bed252ae9109493133a0cc3e9aad9e9a5ddde37
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Debian GNU/Linux bullseye/sid

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

bug#42891: 28.0.50; High Sierra Macos build failure

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> 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?

Let's see...

Larss-iMac:~ larsi$ df -h .
Filesystem     Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk2s2   49Gi   26Gi   23Gi    53%  533003 4294434276    0%   /

I haven't done a full XCode install on this machine -- just the "command
line" stuff.  Could that be the problem -- that that's broken somehow?

That seemed to work fine in mojave and catalina, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#42891: 28.0.50; High Sierra Macos build failure

[Lars Ingebrigtsen]

I reinstalled the command line tools...

And now I'm getting a completely different range of errors when building
temacs.


Undefined symbols for architecture x86_64:
  "_mp_set_memory_functions", referenced from:
      _init_bignum in bignum.o
  "_mpz_abs", referenced from:
      _rounddiv_q in floatfns.o
  "_mpz_add", referenced from:
      _arith_driver in data.o
      _integer_remainder in data.o
      _decode_time_components in timefns.o
      _Fencode_time in timefns.o
      _lispint_arith in timefns.o
  "_mpz_add_ui", referenced from:
      _Fadd1 in data.o
      _rounddiv_q in floatfns.o
      _Fencode_time in timefns.o
      _lispint_arith in timefns.o
      _decode_ticks_hz in timefns.o

So this is some kind of problem on my VM, I think, and not related to
Emacs at all.  So I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no