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

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Peter Dyballa-2
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
                                           %-/\_//
                                            (*)(*)




Reply | Threaded
Open this post in threaded view
|

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

Alan Third
Peter Dyballa <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Peter Dyballa-2

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.




Reply | Threaded
Open this post in threaded view
|

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

Noam Postavsky-2
Peter Dyballa <[hidden email]> 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.


From b7e08e341c19e1d2c8b1105ea1d94979577dbd02 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <[hidden email]>
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

Reply | Threaded
Open this post in threaded view
|

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

Andreas Schwab-2
On Dez 03 2017, Noam Postavsky <[hidden email]> wrote:

> From b7e08e341c19e1d2c8b1105ea1d94979577dbd02 Mon Sep 17 00:00:00 2001
> From: Noam Postavsky <[hidden email]>
> 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, [hidden email]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."



Reply | Threaded
Open this post in threaded view
|

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

Peter Dyballa-2
In reply to this post by Noam Postavsky-2

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."




Reply | Threaded
Open this post in threaded view
|

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

Noam Postavsky-2
Peter Dyballa <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Peter Dyballa-2

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




Reply | Threaded
Open this post in threaded view
|

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

Noam Postavsky-2
# compiler bug, not Emacs bug
tags 18743 wontfix notabug
close 18743
quit

Peter Dyballa <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Noam Postavsky-2
> From: Noam Postavsky <[hidden email]>
> Date: Sun, 03 Dec 2017 15:01:39 -0500
> Cc: Alan Third <[hidden email]>, [hidden email]
>
> > 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.



Reply | Threaded
Open this post in threaded view
|

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

Richard Stallman
In reply to this post by Noam Postavsky-2
[[[ 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.




Reply | Threaded
Open this post in threaded view
|

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

Peter Dyballa-2

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






Reply | Threaded
Open this post in threaded view
|

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.




Reply | Threaded
Open this post in threaded view
|

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

Peter Dyballa-2

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.




Reply | Threaded
Open this post in threaded view
|

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.




Reply | Threaded
Open this post in threaded view
|

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

Peter Dyballa-2
In reply to this post by Richard Stallman

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.




Reply | Threaded
Open this post in threaded view
|

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

Glenn Morris-3
In reply to this post by Richard Stallman
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.



Reply | Threaded
Open this post in threaded view
|

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

Peter Dyballa-2
In reply to this post by Richard Stallman

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




Reply | Threaded
Open this post in threaded view
|

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

Peter Dyballa-2
In reply to this post by Richard Stallman

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.




Reply | Threaded
Open this post in threaded view
|

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

Richard Stallman
In reply to this post by Glenn Morris-3
[[[ 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.




12