Emacs 28.1 doesn't compile on Mac OS 10.7.5

Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Werner LEMBERG]

Compiling emacs 28.1 fails if built with MacPorts on Mac OS 10.7.5
(Lion).  The error messages start with

```
/usr/bin/clang -c -isystem/opt/local/include/LegacySupport \
  -I/opt/local/include -Demacs -I. -I. -I../lib -I../lib \
  -I/opt/local/include/libxml2 -MMD -MF deps/coding.d -MP \
  -I/opt/local/include/p11-kit-1 -Wno-switch -Wno-pointer-sign \
  -Wno-string-plus-int -Wno-initializer-overrides \
  -Wno-tautological-compare -pipe -Os -arch x86_64
  coding.c
coding.c:2632:10: error: type name requires a specifier or qualifier
                code = ENCODE_CHAR (charset, c);
                       ^
./charset.h:432:4: note: expanded from macro 'ENCODE_CHAR'
  (verify_expr                                                          \
   ^
../lib/verify.h:262:5: note: expanded from macro 'verify_expr'
   (_GL_VERIFY_TRUE (R, "verify_expr (" #R ", " #E ")") ? (E) : (E))
    ^
../lib/verify.h:177:15: note: expanded from macro '_GL_VERIFY_TRUE'
   (!!sizeof (_GL_VERIFY_TYPE (R, DIAGNOSTIC)))
              ^
../lib/verify.h:192:7: note: expanded from macro '_GL_VERIFY_TYPE'
      _Static_assert (R, DIAGNOSTIC);          \
      ^
```

A complete failure log can be found at

  https://build.macports.org/builders/ports-10.7_x86_64-builder/builds/95632/steps/install-port/logs/stdio

Note that `/usr/bin/clang -v` on this ancient Mac gives the following
output.

```
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix
```


    Werner

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Mattias Engdegård]

15 apr. 2022 kl. 13.55 skrev Werner LEMBERG <wl@gnu.org>:

> Compiling emacs 28.1 fails if built with MacPorts on Mac OS 10.7.5
> (Lion).

> A complete failure log can be found at
> 
>  https://build.macports.org/builders/ports-10.7_x86_64-builder/builds/95632/steps/install-port/logs/stdio
> 
> Note that `/usr/bin/clang -v` on this ancient Mac gives the following
> output.
> 
> ```
> Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)

Would you please post the output from

  /usr/bin/clang -E -dM - </dev/null

to help us get started?

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Mattias Engdegård]

[-- Attachment #1: Type: text/plain, Size: 241 bytes --]

> Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)

It seems likely that this version has __clang_major__ = 4 despite begin based on 3.2; if so, then the attached change may be the right solution. Would you give it a try?


[-- Attachment #2: old-apple-clang.diff --]
[-- Type: application/octet-stream, Size: 491 bytes --]

diff --git a/lib/verify.h b/lib/verify.h
index 07b2f4866f..c2d2a56670 100644
--- a/lib/verify.h
+++ b/lib/verify.h
@@ -34,7 +34,7 @@ #define _GL_VERIFY_H
 #ifndef __cplusplus
 # if (201112L <= __STDC_VERSION__ \
       || (!defined __STRICT_ANSI__ \
-          && (4 < __GNUC__ + (6 <= __GNUC_MINOR__) || 4 <= __clang_major__)))
+          && (4 < __GNUC__ + (6 <= __GNUC_MINOR__) || 5 <= __clang_major__)))
 #  define _GL_HAVE__STATIC_ASSERT 1
 # endif
 # if (202000L <= __STDC_VERSION__ \

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Werner LEMBERG]

> It seems likely that this version has __clang_major__ = 4 despite
> begin based on 3.2; if so, then the attached change may be the right
> solution.  Would you give it a try?

This helps, thanks.  However, it is not sufficient.  Here's the next
compilation error (omitting the follow-up ones).

```
sysdep.c:4133:3: error: use of undeclared identifier 'rusage_info_current'
  rusage_info_current ri;
  ^
sysdep.c:4134:7: warning: implicit declaration of function
                 'proc_pid_rusage' is invalid in C99
                 [-Wimplicit-function-declaration]
  if (proc_pid_rusage(proc_id, RUSAGE_INFO_CURRENT, (rusage_info_t *) &ri) == 0)
      ^
  ...
```


    Werner

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Eli Zaretskii]

> Date: Fri, 15 Apr 2022 15:23:01 +0000 (UTC)
> From: Werner LEMBERG <wl@gnu.org>
> Cc: dports@macports.org, emacs-devel@gnu.org
> 
> ```
> sysdep.c:4133:3: error: use of undeclared identifier 'rusage_info_current'
>   rusage_info_current ri;
>   ^
> sysdep.c:4134:7: warning: implicit declaration of function
>                  'proc_pid_rusage' is invalid in C99
>                  [-Wimplicit-function-declaration]
>   if (proc_pid_rusage(proc_id, RUSAGE_INFO_CURRENT, (rusage_info_t *) &ri) == 0)
>       ^
>   ...
> ```

Can you please look in your system headers and tell where is
rusage_info_current declared?

Thanks.

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Mattias Engdegård]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

15 apr. 2022 kl. 17.23 skrev Werner LEMBERG <wl@gnu.org>:

>> It seems likely that this version has __clang_major__ = 4 despite
>> begin based on 3.2; if so, then the attached change may be the right
>> solution.  Would you give it a try?
> 
> This helps, thanks.

Thanks for testing. Paul, would you consider something like that patch (repeated here) for gnulib?
This is likely a regression in Emacs 28.1 for Werner's build environment.


[-- Attachment #2: old-apple-clang.diff --]
[-- Type: application/octet-stream, Size: 491 bytes --]

diff --git a/lib/verify.h b/lib/verify.h
index 07b2f4866f..c2d2a56670 100644
--- a/lib/verify.h
+++ b/lib/verify.h
@@ -34,7 +34,7 @@ #define _GL_VERIFY_H
 #ifndef __cplusplus
 # if (201112L <= __STDC_VERSION__ \
       || (!defined __STRICT_ANSI__ \
-          && (4 < __GNUC__ + (6 <= __GNUC_MINOR__) || 4 <= __clang_major__)))
+          && (4 < __GNUC__ + (6 <= __GNUC_MINOR__) || 5 <= __clang_major__)))
 #  define _GL_HAVE__STATIC_ASSERT 1
 # endif
 # if (202000L <= __STDC_VERSION__ \

[-- Attachment #3: Type: text/plain, Size: 411 bytes --]


> sysdep.c:4133:3: error: use of undeclared identifier 'rusage_info_current'
>  rusage_info_current ri;


This appears to be a consequence of 6d51805154 (bug#48548) which uses an interface that was introduced in macOS 10.9. It should be possible to unify the old and new code to get something that works on your system as well. I'll write a patch.

This, too, seems to be a regression in Emacs 28.1.

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Mattias Engdegård]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

15 apr. 2022 kl. 18.22 skrev Mattias Engdegård <mattiase@acm.org>:

> This appears to be a consequence of 6d51805154 (bug#48548) which uses an interface that was introduced in macOS 10.9. It should be possible to unify the old and new code to get something that works on your system as well. I'll write a patch.

Please try this (not tested on your macOS version).


[-- Attachment #2: old-macos-proced.diff --]
[-- Type: application/octet-stream, Size: 2360 bytes --]

diff --git a/src/sysdep.c b/src/sysdep.c
index 1e630835ad..b184c8e7a7 100644
--- a/src/sysdep.c
+++ b/src/sysdep.c
@@ -4027,6 +4027,9 @@ system_process_attributes (Lisp_Object pid)
 
 #elif defined DARWIN_OS
 
+#define HAVE_PROC_PID_RUSAGE (MAC_OS_X_VERSION_MIN_REQUIRED >= 1090)
+#define HAVE_PROC_PIDINFO (MAC_OS_X_VERSION_MIN_REQUIRED >= 1050)
+
 Lisp_Object
 system_process_attributes (Lisp_Object pid)
 {
@@ -4130,6 +4133,7 @@ system_process_attributes (Lisp_Object pid)
   attrs = Fcons (Fcons (Qtpgid, INT_TO_INTEGER (proc.kp_eproc.e_tpgid)),
 		 attrs);
 
+#if HAVE_PROC_PID_RUSAGE
   rusage_info_current ri;
   if (proc_pid_rusage(proc_id, RUSAGE_INFO_CURRENT, (rusage_info_t *) &ri) == 0)
     {
@@ -4143,6 +4147,24 @@ system_process_attributes (Lisp_Object pid)
 
       attrs = Fcons (Fcons (Qmajflt, INT_TO_INTEGER (ri.ri_pageins)), attrs);
   }
+#else  /* !HAVE_PROC_PID_RUSAGE */
+  struct rusage *rusage = proc.kp_proc.p_ru;
+  if (rusage)
+    {
+      attrs = Fcons (Fcons (Qminflt, INT_TO_INTEGER (rusage->ru_minflt)),
+		     attrs);
+      attrs = Fcons (Fcons (Qmajflt, INT_TO_INTEGER (rusage->ru_majflt)),
+		     attrs);
+
+      attrs = Fcons (Fcons (Qutime, make_lisp_timeval (rusage->ru_utime)),
+		     attrs);
+      attrs = Fcons (Fcons (Qstime, make_lisp_timeval (rusage->ru_stime)),
+		     attrs);
+      struct timespec t = timespec_add (timeval_to_timespec (rusage->ru_utime),
+					timeval_to_timespec (rusage->ru_stime));
+      attrs = Fcons (Fcons (Qtime, make_lisp_time (t)), attrs);
+    }
+#endif  /* !HAVE_PROC_PID_RUSAGE */
 
   starttime = proc.kp_proc.p_starttime;
   attrs = Fcons (Fcons (Qnice,  make_fixnum (proc.kp_proc.p_nice)), attrs);
@@ -4152,6 +4174,7 @@ system_process_attributes (Lisp_Object pid)
   t = timespec_sub (now, timeval_to_timespec (starttime));
   attrs = Fcons (Fcons (Qetime, make_lisp_time (t)), attrs);
 
+#if HAVE_PROC_PIDINFO
   struct proc_taskinfo taskinfo;
   if (proc_pidinfo (proc_id, PROC_PIDTASKINFO, 0, &taskinfo, sizeof (taskinfo)) > 0)
     {
@@ -4159,6 +4182,7 @@ system_process_attributes (Lisp_Object pid)
       attrs = Fcons (Fcons (Qrss, make_fixnum (taskinfo.pti_resident_size / 1024)), attrs);
       attrs = Fcons (Fcons (Qthcount, make_fixnum (taskinfo.pti_threadnum)), attrs);
     }
+#endif	/* HAVE_PROC_PIDINFO */
 
 #ifdef KERN_PROCARGS2
   char args[ARG_MAX];

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Werner LEMBERG]

>> sysdep.c:4133:3: error: use of undeclared identifier 'rusage_info_current'
>>   rusage_info_current ri;
>>   ^
>> sysdep.c:4134:7: warning: implicit declaration of function
>>                  'proc_pid_rusage' is invalid in C99
>>                  [-Wimplicit-function-declaration]
>>   if (proc_pid_rusage(proc_id, RUSAGE_INFO_CURRENT, (rusage_info_t *) &ri) == 0)
>>       ^
>>   ...
>> ```
> 
> Can you please look in your system headers and tell where is
> rusage_info_current declared?

It's not defined at all on macOS 10.7.5.  According to

  https://developer.apple.com/documentation/kernel/rusage_info_current

it was introduced in macOS 10.10.


    Werner

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Werner LEMBERG]

>> sysdep.c:4133:3: error: use of undeclared identifier 'rusage_info_current'
>>  rusage_info_current ri;
> 
> This appears to be a consequence of 6d51805154 (bug#48548) which
> uses an interface that was introduced in macOS 10.9.

Probably 10.10, as mentioned in an e-mail answering Eli.

> It should be possible to unify the old and new code to get something
> that works on your system as well.  I'll write a patch.

Thanks.


    Werner

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Mattias Engdegård]

[-- Attachment #1: Type: text/plain, Size: 228 bytes --]

15 apr. 2022 kl. 18.51 skrev Werner LEMBERG <wl@gnu.org>:

> Probably 10.10, as mentioned in an e-mail answering Eli.

All right, it appears that RUSAGE_INFO_CURRENT is newer than proc_pid_rusage. I've adapted the patch.


[-- Attachment #2: old-macos-proced.diff --]
[-- Type: application/octet-stream, Size: 2378 bytes --]

diff --git a/src/sysdep.c b/src/sysdep.c
index 1e630835ad..f6d7d3920b 100644
--- a/src/sysdep.c
+++ b/src/sysdep.c
@@ -4027,6 +4027,9 @@ system_process_attributes (Lisp_Object pid)
 
 #elif defined DARWIN_OS
 
+#define HAVE_RUSAGE_INFO_CURRENT (MAC_OS_X_VERSION_MIN_REQUIRED >= 101000)
+#define HAVE_PROC_PIDINFO (MAC_OS_X_VERSION_MIN_REQUIRED >= 1050)
+
 Lisp_Object
 system_process_attributes (Lisp_Object pid)
 {
@@ -4130,6 +4133,7 @@ system_process_attributes (Lisp_Object pid)
   attrs = Fcons (Fcons (Qtpgid, INT_TO_INTEGER (proc.kp_eproc.e_tpgid)),
 		 attrs);
 
+#if HAVE_RUSAGE_INFO_CURRENT
   rusage_info_current ri;
   if (proc_pid_rusage(proc_id, RUSAGE_INFO_CURRENT, (rusage_info_t *) &ri) == 0)
     {
@@ -4143,6 +4147,24 @@ system_process_attributes (Lisp_Object pid)
 
       attrs = Fcons (Fcons (Qmajflt, INT_TO_INTEGER (ri.ri_pageins)), attrs);
   }
+#else  /* !HAVE_RUSAGE_INFO_CURRENT */
+  struct rusage *rusage = proc.kp_proc.p_ru;
+  if (rusage)
+    {
+      attrs = Fcons (Fcons (Qminflt, INT_TO_INTEGER (rusage->ru_minflt)),
+		     attrs);
+      attrs = Fcons (Fcons (Qmajflt, INT_TO_INTEGER (rusage->ru_majflt)),
+		     attrs);
+
+      attrs = Fcons (Fcons (Qutime, make_lisp_timeval (rusage->ru_utime)),
+		     attrs);
+      attrs = Fcons (Fcons (Qstime, make_lisp_timeval (rusage->ru_stime)),
+		     attrs);
+      struct timespec t = timespec_add (timeval_to_timespec (rusage->ru_utime),
+					timeval_to_timespec (rusage->ru_stime));
+      attrs = Fcons (Fcons (Qtime, make_lisp_time (t)), attrs);
+    }
+#endif  /* !HAVE_RUSAGE_INFO_CURRENT */
 
   starttime = proc.kp_proc.p_starttime;
   attrs = Fcons (Fcons (Qnice,  make_fixnum (proc.kp_proc.p_nice)), attrs);
@@ -4152,6 +4174,7 @@ system_process_attributes (Lisp_Object pid)
   t = timespec_sub (now, timeval_to_timespec (starttime));
   attrs = Fcons (Fcons (Qetime, make_lisp_time (t)), attrs);
 
+#if HAVE_PROC_PIDINFO
   struct proc_taskinfo taskinfo;
   if (proc_pidinfo (proc_id, PROC_PIDTASKINFO, 0, &taskinfo, sizeof (taskinfo)) > 0)
     {
@@ -4159,6 +4182,7 @@ system_process_attributes (Lisp_Object pid)
       attrs = Fcons (Fcons (Qrss, make_fixnum (taskinfo.pti_resident_size / 1024)), attrs);
       attrs = Fcons (Fcons (Qthcount, make_fixnum (taskinfo.pti_threadnum)), attrs);
     }
+#endif	/* HAVE_PROC_PIDINFO */
 
 #ifdef KERN_PROCARGS2
   char args[ARG_MAX];

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Werner LEMBERG]

>> Probably 10.10, as mentioned in an e-mail answering Eli.
> 
> All right, it appears that RUSAGE_INFO_CURRENT is newer than
> proc_pid_rusage. I've adapted the patch.

This compiles, thanks!  Aaand the next problem:

```
make[2]: Leaving directory
           `/opt/local/var/macports/build/_opt_macports_macports-ports_editors_emacs/emacs/work/emacs-28.1/lisp'
cp -f temacs bootstrap-emacs
rm -f bootstrap-emacs.pdmp
./temacs --batch  -l loadup --temacs=pbootstrap \
         --bin-dest /opt/local/bin/ --eln-dest /opt/local/lib/emacs/28.1/
Warning: arch-independent data dir '/opt/local/share/emacs/28.1/etc/': Invalid argument
Warning: Lisp directory
           '/opt/local/var/macports/build/_opt_macports_macports-ports_editors_emacs/emacs/work/emacs-28.1/lisp':
           Invalid argument
Error: /opt/local/share/emacs/28.1/etc/charsets: Invalid argument
Emacs will not function correctly without the character map files.
Please check your installation!
make[1]: *** [bootstrap-emacs.pdmp] Error 1
make[1]: Leaving directory
           `/opt/local/var/macports/build/_opt_macports_macports-ports_editors_emacs/emacs/work/emacs-28.1/src'
make: *** [src] Error 2
make: Leaving directory
        `/opt/local/var/macports/build/_opt_macports_macports-ports_editors_emacs/emacs/work/emacs-28.1'

Command failed:
  cd "/opt/local/var/macports/build/_opt_macports_macports-ports_editors_emacs/emacs/work/emacs-28.1" \
  && /usr/bin/make -j2 -w all NATIVE_FULL_AOT=1 
```

The first warning seems to come from file `src/callproc.c`.


    Werner

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Mattias Engdegård]

15 apr. 2022 kl. 19.40 skrev Werner LEMBERG <wl@gnu.org>:

> This compiles, thanks!

Good to hear. Eli and Lars, do you agree that the patch (to sysdep.c) is acceptable for the emacs-28 branch? It appears to be a build regression.

>  Aaand the next problem:

Looks like directory configuration issues that I know nothing about.

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Fri, 15 Apr 2022 20:34:51 +0200
> Cc: dports@macports.org, eggert@cs.ucla.edu, fgunbin@fastmail.fm,
>  emacs-devel@gnu.org
> 
> 15 apr. 2022 kl. 19.40 skrev Werner LEMBERG <wl@gnu.org>:
> 
> > This compiles, thanks!
> 
> Good to hear. Eli and Lars, do you agree that the patch (to sysdep.c) is acceptable for the emacs-28 branch?

Yes, please.

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Werner LEMBERG]

>>  Aaand the next problem:
> 
> Looks like directory configuration issues that I know nothing about.
 
Me neither, unfortunately, since I'm not a Mac user at all.  I only
use this old macOS box via ssh to prepare LilyPond Portfiles, and for
editing them I prefer the Emacs editor on the terminal.  Version 27.2
(as part of MacPorts) compiles with essentially no adjustments, so I
really wonder what has changed in 28.1 to cause those non-compilation
hiccups on my box.  Of course, this could be a local problem, however,
I haven't changed anything in the directory configuration.

Hopefully, the problem can be repeated – and eventually solved.


    Werner

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Werner LEMBERG]

>> Looks like directory configuration issues that I know nothing about.

I've now submitted a first PR for MacPorts

  https://github.com/macports/macports-ports/pull/14594

so that it can eventually be used by admins for triggering builds on
older macOS versions (this isn't done automatically AFAIK).

Lo and behold, it also reports problems with current git on recent
macOS versions (10.15 and 11.0) :-)

```
sysdep.c:4147:41: error: implicit declaration of function
  'timeval_to_timespec' is invalid in C99
  [-Werror,-Wimplicit-function-declaration]
struct timespec t = timespec_add (timeval_to_timespec (rusage->ru_utime),
```

This is from the logfiles for subports 'emacs-devel' and
'emacs-app-devel' based on emacs commit 8259e368001a6e3; the above PR
also contains links to the full logs if needed.


    Werner

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Mattias Engdegård]

16 apr. 2022 kl. 09.35 skrev Werner LEMBERG <wl@gnu.org>:

> Lo and behold, it also reports problems with current git on recent
> macOS versions (10.15 and 11.0) :-)
> 
> ```
> sysdep.c:4147:41: error: implicit declaration of function
>  'timeval_to_timespec' is invalid in C99
>  [-Werror,-Wimplicit-function-declaration]
> struct timespec t = timespec_add (timeval_to_timespec (rusage->ru_utime),
> ```

The sysdep fix has now been committed to emacs-28 and ported to master; please pull and try again.
The patch to lib/verify.h will have to be applied by hand right now (it's in gnulib).

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Werner LEMBERG]

>> Lo and behold, it also reports problems with current git on recent
>> macOS versions (10.15 and 11.0) :-)
>> 
>> ```
>> sysdep.c:4147:41: error: implicit declaration of function
>>  'timeval_to_timespec' is invalid in C99
>>  [-Werror,-Wimplicit-function-declaration]
>> struct timespec t = timespec_add (timeval_to_timespec (rusage->ru_utime),
>> ```
> 
> The sysdep fix has now been committed to emacs-28 and ported to
> master; please pull and try again.  The patch to lib/verify.h will
> have to be applied by hand right now (it's in gnulib).

Master compiles fine with both macOS 10.15 and 11.0 now, thanks.


    Werner

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 303 bytes --]

On 4/15/22 09:22, Mattias Engdegård wrote:
> Paul, would you consider something like that patch (repeated here) for gnulib?

Sure, I installed the attached into Gnulib master on Savannah.

I suppose it wouldn't hurt for an old Mac OS X expert to check the other 
uses of __clang_major__ in Emacs.

[-- Attachment #2: 0001-verify-port-to-Mac-OS-10.7.5.patch --]
[-- Type: text/x-patch, Size: 1885 bytes --]

From 0cda5beb7962f6567f0c4e377df870fa05c6d681 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 16 Apr 2022 19:18:03 -0700
Subject: [PATCH] verify: port to Mac OS 10.7.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Mac OS 10.7.5 clang sets __clang_major__ to 4 even though it was
derived from Clang 3.2.  Problem reported by Werner Lemberg in:
https://lists.gnu.org/r/emacs-devel/2022-04/msg00779.html
* lib/verify.h (_GL_HAVE__STATIC_ASSERT): Don’t define to 1
when __clang_major__ == 4 && !__cplusplus
&& __STDC_VERSION__ < 201112L && !defined __STRICT_ANSI__.
---
 ChangeLog    | 10 ++++++++++
 lib/verify.h |  2 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index a9b82a47d2..1e238d14e9 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2022-04-16  Paul Eggert  <eggert@cs.ucla.edu>
+
+	verify: port to Mac OS 10.7.5
+	Mac OS 10.7.5 clang sets __clang_major__ to 4 even though it was
+	derived from Clang 3.2.  Problem reported by Werner Lemberg in:
+	https://lists.gnu.org/r/emacs-devel/2022-04/msg00779.html
+	* lib/verify.h (_GL_HAVE__STATIC_ASSERT): Don’t define to 1
+	when __clang_major__ == 4 && !__cplusplus
+	&& __STDC_VERSION__ < 201112L && !defined __STRICT_ANSI__.
+
 2022-04-15  Bruno Haible  <bruno@clisp.org>
 
 	sigsegv: Fix compilation error on arceb CPUs.
diff --git a/lib/verify.h b/lib/verify.h
index 07b2f4866f..c2d2a56670 100644
--- a/lib/verify.h
+++ b/lib/verify.h
@@ -34,7 +34,7 @@
 #ifndef __cplusplus
 # if (201112L <= __STDC_VERSION__ \
       || (!defined __STRICT_ANSI__ \
-          && (4 < __GNUC__ + (6 <= __GNUC_MINOR__) || 4 <= __clang_major__)))
+          && (4 < __GNUC__ + (6 <= __GNUC_MINOR__) || 5 <= __clang_major__)))
 #  define _GL_HAVE__STATIC_ASSERT 1
 # endif
 # if (202000L <= __STDC_VERSION__ \
-- 
2.32.0

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Jeffrey Walton]

On Sat, Apr 16, 2022 at 10:21 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> On 4/15/22 09:22, Mattias Engdegård wrote:
> > Paul, would you consider something like that patch (repeated here) for gnulib?
>
> Sure, I installed the attached into Gnulib master on Savannah.
>
> I suppose it wouldn't hurt for an old Mac OS X expert to check the other
> uses of __clang_major__ in Emacs.

This looks like Apple Clang vs LLVM Clang. You should use
__apple_build_version__ to differentiate between the two.

Stepping back a bit, rather than doing the Clang gyrations everywhere
you use __clang_major__ , maybe you should define a couple of macros
like GNULIB_LLVM_CLANG_VER and GNULIB_APPLE_CLANG_VER in a fashion
similar to GCC_VERSION from
https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html:

    #define GCC_VERSION (__GNUC__ * 10000 \
                     + __GNUC_MINOR__ * 100 \
                     + __GNUC_PATCHLEVEL__)

Then you can check versions in the code like:

#if defined(__clang__) && defined(__apple_build_version__)
# define GNULIB_APPLE_CLANG_VER (__clang_major__ * 10000 +
__clang_minor__ * 100 + __clang_patchlevel__)
#elif defined(__clang__)
# define GNULIB_LLVM_CLANG_VER (__clang_major__ * 10000 +
__clang_minor__ * 100 + __clang_patchlevel__)
#elif defined(__GNUC__)
# define GNULIB_GCC_VER (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 +
__GNUC_PATCHLEVEL__)
#endif

#if (GNULIB_GCC_VER >= 40200) || \
    (GNULIB_APPLE_CLANG_VER >= 40200) || \
    (GNULIB_LLVM_CLANG_VER >= 30200)
   ...
#endif

Jeff

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Paul Eggert]

On 4/16/22 20:28, Jeffrey Walton wrote:
> maybe you should define a couple of macros
> like GNULIB_LLVM_CLANG_VER and GNULIB_APPLE_CLANG_VER

I hope we don't need to do that. This is software archaeology (Mac OS X 
10.7.5 is so old that neither the Subject: line nor my patch got its 
name right, and nobody mentioned the mistake :-) and these macros would 
clutter the code for little benefit. Most Clang-specific code nowadays 
shouldn't use Clang version numbers; it should use __has_builtin etc.

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Mattias Engdegård]

17 apr. 2022 kl. 04.21 skrev Paul Eggert <eggert@cs.ucla.edu>:
> 
> On 4/15/22 09:22, Mattias Engdegård wrote:
>> Paul, would you consider something like that patch (repeated here) for gnulib?
> 
> Sure, I installed the attached into Gnulib master on Savannah.

Thank you! This particular change should be back-ported to emacs-28 once master has caught up with gnulib again.

> I suppose it wouldn't hurt for an old Mac OS X expert to check the other uses of __clang_major__ in Emacs.<0001-verify-port-to-Mac-OS-10.7.5.patch>

I'm no expert, old or not, but I would prefer doing the minimum necessary to keep builds working. If that means slightly suboptimal code or diagnostics for long-obsolete OS X versions then so be it.

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Po Lu]

Mattias Engdegård <mattiase@acm.org> writes:

> Thank you! This particular change should be back-ported to emacs-28
> once master has caught up with gnulib again.

As long as someone backports the MS-DOS code at the same time.  I don't
want to update the code on the release branch for a gnulib update,
especially since I know next to nothing about MS-DOS, so someone like
Eli will probably need to go over it again, once again delaying the
prebuilts (which already happened after the 28.1 release.)

Or maybe we could just install the single change to gnulib for old
versions of Mac OS X, but I don't know if that's okay.

Thanks.

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Mattias Engdegård]

17 apr. 2022 kl. 11.32 skrev Po Lu <luangruo@yahoo.com>:

> Or maybe we could just install the single change to gnulib for old
> versions of Mac OS X, but I don't know if that's okay.

That would indeed be the plan, to address this particular build regression only.

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Werner LEMBERG]

>> maybe you should define a couple of macros like
>> GNULIB_LLVM_CLANG_VER and GNULIB_APPLE_CLANG_VER
> 
> I hope we don't need to do that. This is software archaeology (Mac
> OS X 10.7.5 is so old that neither the Subject: line nor my patch
> got its name right, and nobody mentioned the mistake :-) and these
> macros would clutter the code for little benefit. Most
> Clang-specific code nowadays shouldn't use Clang version numbers; it
> should use __has_builtin etc.

BTW, since MacPorts provides newer clang versions, it's fully OK with
me if that old clang version gets rejected, in case this would yield a
better solution.


    Werner

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Eli Zaretskii]

> Feedback-ID: mattiase@acm.or
> From: Mattias Engdegård <mattiase@acm.org>
> Date: Sun, 17 Apr 2022 11:13:43 +0200
> Cc: dports@macports.org, Gnulib bugs <bug-gnulib@gnu.org>,
>  Filipp Gunbin <fgunbin@fastmail.fm>, Emacs-Devel <emacs-devel@gnu.org>
> 
> 17 apr. 2022 kl. 04.21 skrev Paul Eggert <eggert@cs.ucla.edu>:
> > 
> > On 4/15/22 09:22, Mattias Engdegård wrote:
> >> Paul, would you consider something like that patch (repeated here) for gnulib?
> > 
> > Sure, I installed the attached into Gnulib master on Savannah.
> 
> Thank you! This particular change should be back-ported to emacs-28 once master has caught up with gnulib again.

If you are talking about a single change in lib/* files for this
particular problem, I'm fine with that.  But synchronizing with Gnulib
on the release branch is out of the question, as that will bring too
many changes.

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Mattias Engdegård]

17 apr. 2022 kl. 13.33 skrev Eli Zaretskii <eliz@gnu.org>:

>> Thank you! This particular change should be back-ported to emacs-28 once master has caught up with gnulib again.
> 
> If you are talking about a single change in lib/* files for this
> particular problem, I'm fine with that.

Yes, that's the idea.

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Ryan Schmidt]

On Apr 17, 2022, at 02:54, Paul Eggert wrote:

> On 4/16/22 20:28, Jeffrey Walton wrote:
>> maybe you should define a couple of macros
>> like GNULIB_LLVM_CLANG_VER and GNULIB_APPLE_CLANG_VER
> 
> I hope we don't need to do that. This is software archaeology (Mac OS X 10.7.5 is so old that neither the Subject: line nor my patch got its name right, and nobody mentioned the mistake :-) and these macros would clutter the code for little benefit. Most Clang-specific code nowadays shouldn't use Clang version numbers; it should use __has_builtin etc.

I agree you should detect features if you can. If you can't, and you need to look at the compiler version, you need to first establish whether you're using Apple Clang or open source clang, since the two use different version numbering schemes. If __clang__ is defined and __apple_build_version__ is defined, you're using Apple Clang and you could inspect that constant directly or you could look at __clang_major__, __clang_minor__, and/or __clang_patchlevel__ interpreted as Apple Clang version numbers. If __clang__ is defined and __apple_build_version__ is not defined, you're using open source clang and can look at the __clang_*__ defines interpreted as open source clang version numbers.


Some sample output from my system:

$ clang -dM -E - < /dev/null | egrep '__(clang|apple)'
#define __apple_build_version__ 4250028
#define __clang__ 1
#define __clang_major__ 4
#define __clang_minor__ 2
#define __clang_patchlevel__ 0
#define __clang_version__ "4.2 (clang-425.0.28)"

$ clang -v
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

$ xcodebuild -version
Xcode 4.6.3
Build version 4H1503

$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.7.5
BuildVersion:	11G63

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Jeffrey Walton]

On Sun, Apr 17, 2022 at 10:33 AM Ryan Schmidt <gnulib@ryandesign.com> wrote:
>
> On Apr 17, 2022, at 02:54, Paul Eggert wrote:
>
> > On 4/16/22 20:28, Jeffrey Walton wrote:
> >> maybe you should define a couple of macros
> >> like GNULIB_LLVM_CLANG_VER and GNULIB_APPLE_CLANG_VER
> >
> > I hope we don't need to do that. This is software archaeology (Mac OS X 10.7.5 is so old that neither the Subject: line nor my patch got its name right, and nobody mentioned the mistake :-) and these macros would clutter the code for little benefit. Most Clang-specific code nowadays shouldn't use Clang version numbers; it should use __has_builtin etc.
>
> I agree you should detect features if you can. If you can't, and you need to look at the compiler version, you need to first establish whether you're using Apple Clang or open source clang, since the two use different version numbering schemes. If __clang__ is defined and __apple_build_version__ is defined, you're using Apple Clang and you could inspect that constant directly or you could look at __clang_major__, __clang_minor__, and/or __clang_patchlevel__ interpreted as Apple Clang version numbers. If __clang__ is defined and __apple_build_version__ is not defined, you're using open source clang and can look at the __clang_*__ defines interpreted as open source clang version numbers.
>
>
> Some sample output from my system:
>
> $ clang -dM -E - < /dev/null | egrep '__(clang|apple)'
> #define __apple_build_version__ 4250028
> #define __clang__ 1
> #define __clang_major__ 4
> #define __clang_minor__ 2
> #define __clang_patchlevel__ 0
> #define __clang_version__ "4.2 (clang-425.0.28)"
>
> $ clang -v
> Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
> Target: x86_64-apple-darwin11.4.2
> Thread model: posix
>
> $ xcodebuild -version
> Xcode 4.6.3
> Build version 4H1503
>
> $ sw_vers
> ProductName:    Mac OS X
> ProductVersion: 10.7.5
> BuildVersion:   11G63

One other thing that is helpful is this cross reference for version
numbers: https://gist.github.com/yamaya/2924292

If you cut a feature in for LLVM Clang, then you can lookup the Apple
Clang version if you don't have an Apple machine with the compiler
handy.

Jeff

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

[Paul Eggert]

On 4/17/22 02:13, Mattias Engdegård wrote:
>> I suppose it wouldn't hurt for an old Mac OS X expert to check the other uses of __clang_major__ in Emacs.<0001-verify-port-to-Mac-OS-10.7.5.patch>
> I'm no expert, old or not, but I would prefer doing the minimum necessary to keep builds working. If that means slightly suboptimal code or diagnostics for long-obsolete OS X versions then so be it.
> 

Yes, quite right. My only worry was whether Emacs has incorrect uses of 
  __clang_major__ that cause incorrect user-visible behavior on some 
macOS versions. I'm not worried about suboptimal code or bogus warnings.

Perhaps I'm worrying too much. Not being an old Mac OS X expert (pun was 
intended :-) I don't know. If someone reading this email is such an 
expert and cares about old macOS ports I hope they can spare a few 
minutes to check.