bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Peter Dyballa]

At revno: 118128

Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.8.0
Thread model: posix

Mac OS X 10.6.8; this is the Clang compiler coming with Apple's Developer Tools (Xcode 4.2 (4C199)).


	fns.c:1929:16: error: read-only variable is not assignable
	          *dest++ = *a++;
	                     ~^

GCC 4.8 accepts this construct, but fails when dumping emacs:

	Dumping under the name emacs
	--- List of All Regions ---
	   address     size prot maxp
	--- List of Regions to be Dumped ---
	   address     size prot maxp
	--- Header Information ---
	Magic = 0xfeedfacf
	CPUType = 16777223
	CPUSubType = -2147483645
	FileType = 0x2
	NCmds = 48
	SizeOfCmds = 4664
	Flags = 0x00000085
	Highest address of load commands in input file: 0x100656000
	Lowest offset of all sections in __TEXT segment:   0x2f58
	--- List of Load Commands in Input File ---
	# cmd              cmdsize name                address     size
	0 LC_SEGMENT_64          72 __PAGEZERO                0 0x100000000
	1 LC_SEGMENT_64         712 __TEXT           0x100000000 0x1e7000
	                           __text           0x100002f58 0x17a878
	                           __text_cold      0x10017d7d0    0x2b2
	                           __text_startup   0x10017da82   0x1394
	                           __stubs          0x10017ee16   0x10aa
	                           __stub_helper    0x10017fec0   0x1bd6
	                           __cstring        0x100181a98  0x18b68
	                           __const          0x10019a600    0xad0
	                           __eh_frame       0x10019b0d0  0x4bf28
	2 LC_SEGMENT_64        1272 __DATA           0x1001e7000 0x398000
	                           __program_vars   0x1001e7000     0x28
	                           __got            0x1001e7028     0xe0
	                           __nl_symbol_ptr  0x1001e7108     0x10
	                           __la_symbol_ptr  0x1001e7118   0x1638
	                           __data           0x1001e8760 0x2f1338
	                           __static_data    0x1004d9a98     0x26
	                           __const          0x1004d9ac0   0x49d0
	                           __bss2           0x1004de490    0x150
	                           __pu_bss2        0x1004de5e0     0x64
	                           __bss            0x1004de660    0x105
	                           __bss4           0x1004de770  0x89650
	                           __common         0x100567dc0      0x4
	                           __bss3           0x100567dc8   0x1f28
	                           __pu_bss4        0x100569cf0  0x12e28
	                           __pu_bss3        0x10057cb18   0x1678
	3 LC_SEGMENT_64          72 __LINKEDIT       0x10057f000  0xd7000
	4 LC_DYLD_INFO_ONLY      48
	5 LC_SYMTAB              24
	6 LC_DYSYMTAB            80
	7 LC_LOAD_DYLINKER       32
	8 LC_UUID                24
	9 LC_VERSION_MIN_MACOSX      16
	10 LC_UNIXTHREAD         184
	11 LC_LOAD_DYLIB          56
	12 LC_LOAD_DYLIB          56
	13 LC_LOAD_DYLIB          64
	14 LC_LOAD_DYLIB          56
	15 LC_LOAD_DYLIB          56
	16 LC_LOAD_DYLIB          56
	17 LC_LOAD_DYLIB          56
	18 LC_LOAD_DYLIB          56
	19 LC_LOAD_DYLIB          56
	20 LC_LOAD_DYLIB          56
	21 LC_LOAD_DYLIB          56
	22 LC_LOAD_DYLIB          56
	23 LC_LOAD_DYLIB          64
	24 LC_LOAD_DYLIB          56
	25 LC_LOAD_DYLIB          64
	26 LC_LOAD_DYLIB          64
	27 LC_LOAD_DYLIB          72
	28 LC_LOAD_DYLIB          64
	29 LC_LOAD_DYLIB          64
	30 LC_LOAD_DYLIB          56
	31 LC_LOAD_DYLIB          56
	32 LC_LOAD_DYLIB          64
	33 LC_LOAD_DYLIB          64
	34 LC_LOAD_DYLIB          64
	35 LC_LOAD_DYLIB          56
	36 LC_LOAD_DYLIB          64
	37 LC_LOAD_DYLIB          64
	38 LC_LOAD_DYLIB          64
	39 LC_LOAD_DYLIB          64
	40 LC_LOAD_DYLIB          56
	41 LC_LOAD_DYLIB          56
	42 LC_LOAD_DYLIB          56
	43 LC_LOAD_DYLIB          64
	44 LC_LOAD_DYLIB          56
	45 LC_LOAD_DYLIB          64
	46 LC_FUNCTION_STARTS      16
	47 LC_DATA_IN_CODE        16
	0x101efc080 (sz:   0x3f24/  0x3f28)
	0x101e00000 (sz:  0x8c3e5/ 0xfc080)
	0x101bfc080 (sz:   0x3f25/  0x3f28)
	0x101b00000 (sz:  0xfc07f/ 0xfc080)
	0x1037f8000 (sz:   0x20ca/  0x7fa0)
	0x103000000 (sz: 0x20a3fd/0x7f8000)
	0x102ff8000 (sz:   0x7f97/  0x7fa0)
	0x102800000 (sz: 0x7f7fff/0x7f8000)
	0x101977000 (sz:        0/  0x1000)
	--- Load Commands written to Output File ---
	Writing segment __PAGEZERO       @        0 (       0/0x100000000 @          0)
	Writing segment __TEXT           @        0 (0x1e7000/0x1e7000 @ 0x100000000)
	Writing segment __DATA           @ 0x1e7000 (0x398000/0x398000 @ 0x1001e7000)
	        section __program_vars   at 0x1e7000 - 0x1e7028 (sz:     0x28)
	        section __got            at 0x1e7028 - 0x1e7108 (sz:     0xe0)
	        section __nl_symbol_ptr  at 0x1e7108 - 0x1e7118 (sz:     0x10)
	        section __la_symbol_ptr  at 0x1e7118 - 0x1e8750 (sz:   0x1638)
	        section __data           at 0x1e8760 - 0x4d9a98 (sz: 0x2f1338)
	        section __static_data    at 0x4d9a98 - 0x4d9abe (sz:     0x26)
	        section __const          at 0x4d9ac0 - 0x4de490 (sz:   0x49d0)
	        section __bss2           at 0x4de490 - 0x4de5e0 (sz:    0x150)
	        section __pu_bss2        at 0x4de5e0 - 0x4de644 (sz:     0x64)
	unexec: my_endbss_static is not in section __bss
	make[1]: *** [bootstrap-emacs] Error 1
	make: *** [src] Error 2


There are no problems with GCC 4.2.

--
Greetings

  Pete                                           0
                                           %-/\_//
                                            (*)(*)

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Alan Third]

Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:

> At revno: 118128
>
> Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
> Target: x86_64-apple-darwin10.8.0
> Thread model: posix
>
> Mac OS X 10.6.8; this is the Clang compiler coming with Apple's Developer Tools (Xcode 4.2 (4C199)).
>
>
> 	fns.c:1929:16: error: read-only variable is not assignable
> 	          *dest++ = *a++;
> 	                     ~^

Hi Peter,

I'm guessing this must have been fixed as I have no problem compiling
emacs with Clang. Are you still seeing this problem?
-- 
Alan Third

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Peter Dyballa]

Am 25.05.2016 um 22:47 schrieb Alan Third:

> I'm guessing this must have been fixed as I have no problem compiling
> emacs with Clang. Are you still seeing this problem?

Hello!

With Clang 3.0 I still get this error:

	fns.c:1929:16: error: read-only variable is not assignable
	          *dest++ = *a++;
	                     ~^

Other versions of Clang build GNU Emacs.

--
Greetings

  Pete

Windows, c'est un peu comme le beaujolais nouveau: à chaque nouvelle cuvée on sait que ce sera dégueulasse, mais on en prend quand même, par masochisme.

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Noam Postavsky]

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

Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:

> With Clang 3.0 I still get this error:

> Other versions of Clang build GNU Emacs.

So only 3.0 fails with this, while both earlier and later versions
succeed?

> 	fns.c:1929:16: error: read-only variable is not assignable
> 	          *dest++ = *a++;
> 	                     ~^
>

I guess the following should fix it, though I'm not sure if it's worth
doing.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 1372 bytes --]

From b7e08e341c19e1d2c8b1105ea1d94979577dbd02 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Tue, 28 Nov 2017 20:54:00 -0500
Subject: [PATCH] Don't increment array (Bug#18743)

* src/fns.c (merge_vectors): Use integer indexes instead of
incrementing pointers.
---
 src/fns.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/src/fns.c b/src/fns.c
index 9db9bea9f7..e4ff0924b9 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -1812,27 +1812,26 @@ merge_vectors (Lisp_Object pred,
 	       Lisp_Object dest[VLA_ELEMS (alen + blen)])
 {
   eassume (0 < alen && 0 < blen);
-  Lisp_Object const *alim = a + alen;
-  Lisp_Object const *blim = b + blen;
 
+  ptrdiff_t ai = 0, bi = 0, di = 0;
   while (true)
     {
-      if (inorder (pred, a[0], b[0]))
+      if (inorder (pred, a[ai], b[bi]))
 	{
-	  *dest++ = *a++;
-	  if (a == alim)
+          dest[di++] = a[ai++];
+	  if (ai >= alen)
 	    {
 	      if (dest != b)
-		memcpy (dest, b, (blim - b) * sizeof *dest);
+		memcpy (&dest[di], &b[bi], (blen - bi) * sizeof *dest);
 	      return;
 	    }
 	}
       else
 	{
-	  *dest++ = *b++;
-	  if (b == blim)
+	  dest[di++] = b[bi++];
+	  if (bi >= blen)
 	    {
-	      memcpy (dest, a, (alim - a) * sizeof *dest);
+	      memcpy (&dest[di], &a[ai], (alen - ai) * sizeof *dest);
 	      return;
 	    }
 	}
-- 
2.11.0

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Andreas Schwab]

On Dez 03 2017, Noam Postavsky <npostavs@users.sourceforge.net> wrote:

> From b7e08e341c19e1d2c8b1105ea1d94979577dbd02 Mon Sep 17 00:00:00 2001
> From: Noam Postavsky <npostavs@gmail.com>
> Date: Tue, 28 Nov 2017 20:54:00 -0500
> Subject: [PATCH] Don't increment array (Bug#18743)
>
> * src/fns.c (merge_vectors): Use integer indexes instead of
> incrementing pointers.

Please add a comment that this is a workaround for a compiler bug.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Peter Dyballa]

Am 3.12.2017 um 20:24 schrieb Noam Postavsky:

> So only 3.0 fails with this, while both earlier and later versions
> succeed?
> 
>> 	fns.c:1929:16: error: read-only variable is not assignable
>> 	          *dest++ = *a++;
>> 	                     ~^
>> 

Yes, obviously. Today I do not have Clang 3.0 installed on my MacBook (with Clang 3.7.1 and newer compilation succeeds) and neither on my old PowerBook. Also Clang 3.0 is not supported any more by MacPorts, a packet manager for GNU and other free software.

--
Greetings

  Pete

"Klingon function calls do not have 'parameters' - they have 'arguments' - and they ALWAYS WIN THEM."

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Noam Postavsky]

Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:

> Am 3.12.2017 um 20:24 schrieb Noam Postavsky:
>
>> So only 3.0 fails with this, while both earlier and later versions
>> succeed?
>> 
>>> 	fns.c:1929:16: error: read-only variable is not assignable
>>> 	          *dest++ = *a++;
>>> 	                     ~^
>>> 
>
> Yes, obviously.

Thanks, it was not clear to me which clang versions were current at the
time of the original report (i.e., if 3.0 represented the "latest and
greatest", or something else).

> Today I do not have Clang 3.0 installed on my MacBook
> (with Clang 3.7.1 and newer compilation succeeds) and neither on my
> old PowerBook. Also Clang 3.0 is not supported any more by MacPorts, a
> packet manager for GNU and other free software.

So I think we should just close this as wontfix; no point in working
around bugs in obsolete compiler versions.

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Peter Dyballa]

Am 3.12.2017 um 21:01 schrieb Noam Postavsky:

> it was not clear to me which clang versions were current at the
> time of the original report (i.e., if 3.0 represented the "latest and
> greatest", or something else).

Clang 3.0 was released at the end of 2011. I think in 2012 it was available with Xcode 2.0. At the time I submitted the bug Clang 3.5 was out, but not as part of an updated Xcode version. I think I was just testing my various Clang versions (due to packet dependencies) then and did not mention that just this one version had the problem.

So yes, it can be closed as a compiler bug.

--
Greetings

  Pete

From error to error, one discovers the entire truth.
				- Sigmund Freud

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Noam Postavsky]

# compiler bug, not Emacs bug
tags 18743 wontfix notabug
close 18743
quit

Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:

> Am 3.12.2017 um 21:01 schrieb Noam Postavsky:
>
>> it was not clear to me which clang versions were current at the
>> time of the original report (i.e., if 3.0 represented the "latest and
>> greatest", or something else).
>
> Clang 3.0 was released at the end of 2011. I think in 2012 it was
> available with Xcode 2.0. At the time I submitted the bug Clang 3.5
> was out, but not as part of an updated Xcode version. I think I was
> just testing my various Clang versions (due to packet dependencies)
> then and did not mention that just this one version had the problem.
>
> So yes, it can be closed as a compiler bug.

Alright, closing.

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sun, 03 Dec 2017 15:01:39 -0500
> Cc: Alan Third <alan@idiocy.org>, 18743@debbugs.gnu.org
> 
> > Today I do not have Clang 3.0 installed on my MacBook
> > (with Clang 3.7.1 and newer compilation succeeds) and neither on my
> > old PowerBook. Also Clang 3.0 is not supported any more by MacPorts, a
> > packet manager for GNU and other free software.
> 
> So I think we should just close this as wontfix; no point in working
> around bugs in obsolete compiler versions.

Agreed.

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Does the current GCC version work for dumping Emacs?

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Peter Dyballa]

Am 5.12.2017 um 00:48 schrieb Richard Stallman:

> Does the current GCC version work for dumping Emacs?

Which one is that for you?

On a few Linux distributions I work on (professionally) a few versions of GCC are the default compiler. My Mac runs Snow Leopard or Mac OS X 10.6.8, which is since years out of support (I contemplate to upgrade to a more recent version of OS X or macOS around Christmas). And I think this also means out of GNU Emacs support, i.e. GNU Emacs 26.1 will not compile. I could be wrong, having misread this, because GNU Emacs 26.0.90 could be built, which I tried with Clang 3.9. Right now I have installed:

  gcc5 @5.5.0_0 (active)
  gcc6 @6.4.0_0 (active)

and also:

  clang-3.7 @3.7.1_5+analyzer (active)
  clang-3.8 @3.8.1_9+analyzer (active)
  clang-3.9 @3.9.1_7+analyzer+libstdcxx
  clang-3.9 @3.9.1_8+analyzer+libstdcxx (active)
  clang-4.0 @4.0.1_3+analyzer+libstdcxx
  clang-4.0 @4.0.1_4+analyzer+libstdcxx (active)

GCC 7.2 and 8 are listed as available in MacPorts, and also Clang 5.0. I have some versions of GNU Emacs 25.x available too. Which checks would like to see me perform?

--
Greetings

  Pete

True happiness is knowing you're a hypocrite	– Ivor Cutler

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

   > Right now I have installed:

   >  gcc5 @5.5.0_0 (active)
   >  gcc6 @6.4.0_0 (active)

Would you please test with these.

Basically, the question is whether the problem is limited to a
many-years-old GCC version or not.  If GCC 5 and 6 don't have the
same problem, maybe 4.8 is so old it doesn't matter.
What year was GCC 5 released?

We're particularly interested in compilation with GCC because
GCC is our compiler.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Peter Dyballa]

Am 6.12.2017 um 00:13 schrieb Richard Stallman:

> What year was GCC 5 released?

According to https://www.gnu.org/software/gcc/releases.html: GCC 5.1	April 22, 2015; GCC 5.5	October 10, 2017.

--
Greetings

  Pete

A child of five could understand this!  Fetch me a child of five.

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > According to https://www.gnu.org/software/gcc/releases.html: GCC 5.1	April 22, 2015; GCC 5.5	October 10, 2017.

I think that means that GCC version 4 is still recent enough to be
worth supporting.

Can you analyze the problem dumping with GCC 4.8?

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Glenn Morris]

Richard Stallman wrote:

> Can you analyze the problem dumping with GCC 4.8?

gcc 4.8 works fine on GNU/Linux.
You are replying to a a three year old report about a problem one
person had on OS X 10.6, which was unsupported by Apple 4 years ago.
Meanwhile, there are 4000 open Emacs bug reports.

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > gcc 4.8 works fine on GNU/Linux.
  > You are replying to a a three year old report about a problem one
  > person had on OS X 10.6, which was unsupported by Apple 4 years ago.
  > Meanwhile, there are 4000 open Emacs bug reports.

I don't keep track of MacOS versions, so I didn't know this.
That makes it less important, true.  But if a MacOS user wants to
work on it, we may as well make new Emacs versions work on that platform
as well with GCC as with Clang.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Peter Dyballa]

Am 6.12.2017 um 19:13 schrieb Richard Stallman:

> Can you analyze the problem dumping with GCC 4.8?

It, the compiler, is installing…

--
Greetings

  Pete

’Twas a woman who drove me to drink, and I never had the courtesy to thank her for it.
				— W.C. Fields

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Peter Dyballa]

Am 6.12.2017 um 19:13 schrieb Richard Stallman:

> Can you analyze the problem dumping with GCC 4.8?

Configure has no problem with GIF and JPEG, but build fails with:

	"../../src/bootstrap-emacs" -batch --no-site-file --no-site-lisp -f batch-byte-compile uvs.el
	Fatal error 6: Abort trap
	Backtrace:
	0   bootstrap-emacs                     0x0000000100155ca1 emacs_backtrace + 105
	1   bootstrap-emacs                     0x000000010012f79c terminate_due_to_signal + 129
	2   bootstrap-emacs                     0x0000000100155653 deliver_fatal_signal + 0
	3   bootstrap-emacs                     0x0000000100155628 deliver_thread_signal + 146
	4   bootstrap-emacs                     0x000000010015568d deliver_fatal_thread_signal + 28
	5   libSystem.B.dylib                   0x00007fff813de1ba _sigtramp + 26
	6   bootstrap-emacs                     0x000000010306b39a next_release_must_exit + 43910710
	7   libSystem.B.dylib                   0x00007fff81384195 free + 128
	8   bootstrap-emacs                     0x00000001002828c4 rpl_putenv + 329
	9   bootstrap-emacs                     0x00000001001a84cc xputenv + 24
	10  bootstrap-emacs                     0x00000001001c0f73 set_time_zone_rule + 280
	11  bootstrap-emacs                     0x00000001001bc5ae init_editfns + 162
	12  bootstrap-emacs                     0x00000001001310b1 main + 4273
	13  bootstrap-emacs                     0x000000010000253c start + 52

Dumping succeeded before, of course, here and also with GCC 5 and 6. The recent version of GCC 4.8 is 4.8.5. Historically it could have been the same version (release date: June 23, 2015), but I have no proof.

One more difference is that MacPorts has changed. The reason is different C++ ABIs and inability to pass things between different versions (not my field of interest). On my Snow Leopard system I have to use a special one (don't know the details), switch happened in summer.

Original Mac OS X 10.6.8 supports Clang 3.0 and GCC 4.2.

--
Greetings

  Pete

Wasting time is an important part of living.

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Peter Dyballa]

Am 6.12.2017 um 00:13 schrieb Richard Stallman:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>> Right now I have installed:
> 
>> gcc5 @5.5.0_0 (active)
>> gcc6 @6.4.0_0 (active)
> 
> Would you please test with these.

With the "original" GNU Emacs 25.0.50 the first problem these two compilers have is libjpeg 9b. Configure only finds:

	configure:14428: WARNING: libjpeg found, but not version 6b or later 

Later, when "checking for EGifPutExtensionLast in -lgif," it finds:

	configure:14871: error: The following required libraries were not found:
	     libjpeg
	Maybe some development libraries/packages are missing?
	If you don't want to link with them give
	     --with-jpeg=no
	as options to configure

So, configuring with --with-jpeg=no I can build GNU Emacs – almost:

(with GCC5, known to not work correctly on Mac OS X 10.6.8)
	Fatal error 6: Abort trap
	Backtrace:
	0   bootstrap-emacs                     0x000000010015680e emacs_backtrace + 105
	1   bootstrap-emacs                     0x000000010012feb5 terminate_due_to_signal + 129
	2   bootstrap-emacs                     0x00000001001561b3 deliver_fatal_signal + 0
	3   bootstrap-emacs                     0x0000000100156184 deliver_thread_signal + 146
	4   bootstrap-emacs                     0x00000001001561ee deliver_fatal_thread_signal + 28
	5   libSystem.B.dylib                   0x00007fff813de1ba _sigtramp + 26
	6   bootstrap-emacs                     0x000000010401de86 next_release_must_exit + 60371666
	7   libSystem.B.dylib                   0x00007fff81384195 free + 128
	8   bootstrap-emacs                     0x00000001002829fe rpl_putenv + 330
	9   bootstrap-emacs                     0x00000001001a93aa xputenv + 24
	10  bootstrap-emacs                     0x00000001001c2004 set_time_zone_rule + 280
	11  bootstrap-emacs                     0x00000001001bd60a init_editfns + 166
	12  bootstrap-emacs                     0x000000010013183e main + 4344
	13  bootstrap-emacs                     0x0000000100002590 start + 52
	make[2]: *** [uvs.elc] Abort trap (core dumped)

(with GCC6)
	Fatal error 6: Abort trap
	Backtrace:
	0   bootstrap-emacs                     0x0000000100155634 emacs_backtrace + 105
	1   bootstrap-emacs                     0x000000010012edb0 terminate_due_to_signal + 129
	2   bootstrap-emacs                     0x0000000100154fd9 deliver_fatal_signal + 0
	3   bootstrap-emacs                     0x0000000100154faa deliver_thread_signal + 146
	4   bootstrap-emacs                     0x0000000100155014 deliver_fatal_thread_signal + 28
	5   libSystem.B.dylib                   0x00007fff813de1ba _sigtramp + 26
	6   bootstrap-emacs                     0x000000010401de86 next_release_must_exit + 60375762
	7   libSystem.B.dylib                   0x00007fff81384195 free + 128
	8   bootstrap-emacs                     0x00000001002817a3 rpl_putenv + 330
	9   bootstrap-emacs                     0x00000001001a830e xputenv + 24
	10  bootstrap-emacs                     0x00000001001c0ee1 set_time_zone_rule + 280
	11  bootstrap-emacs                     0x00000001001bc51a init_editfns + 166
	12  bootstrap-emacs                     0x0000000100130739 main + 4344
	13  bootstrap-emacs                     0x0000000100002f38 start + 52
	make[2]: *** [uvs.elc] Abort trap (core dumped)

The config.log files are saved. After dinner I'll check with GNU Emacs 26.0.90.

--
Greetings

  Pete

The box said "Use Windows 95 or better," so I got a Macintosh.

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

It looks like with a little more work you will finish analyzing
the problem.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

bug#18743: 25.0.50; Clang 3.0 fails to compile src/fns.c, GCC 4.8 cannot dump emacs

[Peter Dyballa]

Am 7.12.2017 um 20:52 schrieb Richard Stallman:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
> It looks like with a little more work you will finish analyzing
> the problem.

For Mac OS X 10.6.8, Snow Leopard, *and* use of MacPorts, which recommends to use as cxx_stdlib libc++, the use of GCC 6 seems to be necessary. At least I could not build GNU Emacs 26.0.90 with another GCC version (I did not try old GCC 4.2, but 4.8 and 5.5 failed).

Mac OS X's Clang 3.0 can build GNU Emacs 26.0.90.


Anyway, in a few weeks, around Christmas, I'll upgrade to El Capitan, macOS (or OS X?) 10.9, I think. (And later even further.) Too much free (and also some useful commercial) software stopped supporting Snow Leopard, so it has to be! (And one very useful free software won't run on El Capitan…)

--
Greetings

  Pete

A morning without coffee is like something without something else.