Emacs 25 from GIT build issue under Ubuntu 16.10

Emacs 25 from GIT build issue under Ubuntu 16.10

[Tim Cross]

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

After upgrade to ubuntu gnome 16.10, attempts to build from fresh git clone
of emacs repo gives an seg fault error when trying to run dumped image. All
was working fine under Ubuntu 16.04.

Loading /home/tcross/git/emacs/lisp/electric.el (source)...
Loading /home/tcross/git/emacs/lisp/emacs-lisp/eldoc.el (source)...
Loading /home/tcross/git/emacs/lisp/cus-start.el (source)...
Loading /home/tcross/git/emacs/lisp/tooltip.el (source)...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name emacs
20812288 of 33554432 static heap bytes used
Makefile:749: recipe for target 'bootstrap-emacs' failed
make[1]: *** [bootstrap-emacs] Segmentation fault (core dumped)
make[1]: Leaving directory '/home/tcross/git/emacs/src'
Makefile:398: recipe for target 'src' failed
make: *** [src] Error 2


-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 1231 bytes --]

Re: Emacs 25 from GIT build issue under Ubuntu 16.10

[Tim Cross]

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

Just FYI, switched to git master branch and tried to build from there with
the same error, so issue is not restricted to just emacs-25 release.

On 15 October 2016 at 10:06, Tim Cross <theophilusx@gmail.com> wrote:

> After upgrade to ubuntu gnome 16.10, attempts to build from fresh git
> clone of emacs repo gives an seg fault error when trying to run dumped
> image. All was working fine under Ubuntu 16.04.
>
> Loading /home/tcross/git/emacs/lisp/electric.el (source)...
> Loading /home/tcross/git/emacs/lisp/emacs-lisp/eldoc.el (source)...
> Loading /home/tcross/git/emacs/lisp/cus-start.el (source)...
> Loading /home/tcross/git/emacs/lisp/tooltip.el (source)...
> Finding pointers to doc strings...
> Finding pointers to doc strings...done
> Dumping under the name emacs
> 20812288 of 33554432 static heap bytes used
> Makefile:749: recipe for target 'bootstrap-emacs' failed
> make[1]: *** [bootstrap-emacs] Segmentation fault (core dumped)
> make[1]: Leaving directory '/home/tcross/git/emacs/src'
> Makefile:398: recipe for target 'src' failed
> make: *** [src] Error 2
>
>
> --
> regards,
>
> Tim
>
> --
> Tim Cross
>
>


-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 2074 bytes --]

Re: Emacs 25 from GIT build issue under Ubuntu 16.10

[Paul Eggert]

Does plain Emacs 24.5 build OK on Ubuntu 16.10?

Which Emacs version ships with Ubuntu 16.10? Emacs 24.5 or 25.1? Either 
way, do Ubuntu's patches to Emacs seem relevant to your problem?

Others are reporting similar problems. See:

http://askubuntu.com/questions/836690/seg-fault-building-emacs25-in-ubuntu-16-10

Re: Emacs 25 from GIT build issue under Ubuntu 16.10

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 14 Oct 2016 23:09:50 -0500
> 
> Does plain Emacs 24.5 build OK on Ubuntu 16.10?
> 
> Which Emacs version ships with Ubuntu 16.10? Emacs 24.5 or 25.1? Either 
> way, do Ubuntu's patches to Emacs seem relevant to your problem?
> 
> Others are reporting similar problems. See:
> 
> http://askubuntu.com/questions/836690/seg-fault-building-emacs25-in-ubuntu-16-10

Let's maintain all the relevant information about this problem in the
bug tracker, there's a bug about this, bug#24682.

bug#24682: 26.0.50; Bootstrap failed

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 14 Oct 2016 23:09:50 -0500
> 
> Does plain Emacs 24.5 build OK on Ubuntu 16.10?
> 
> Which Emacs version ships with Ubuntu 16.10? Emacs 24.5 or 25.1? Either 
> way, do Ubuntu's patches to Emacs seem relevant to your problem?
> 
> Others are reporting similar problems. See:
> 
> http://askubuntu.com/questions/836690/seg-fault-building-emacs25-in-ubuntu-16-10

But since a very similar problem happens with building our master
branch, I guess the Ubuntu's patches to Emacs are off the hook?

I'm guessing this is some problem with the new Ubuntu that is outside
Emacs, perhaps the kernel or the Binutils.

Re: Emacs 25 from GIT build issue under Ubuntu 16.10

[Óscar Fuentes]

Tim Cross <theophilusx@gmail.com> writes:

> After upgrade to ubuntu gnome 16.10, attempts to build from fresh git clone
> of emacs repo gives an seg fault error when trying to run dumped image. All
> was working fine under Ubuntu 16.04.

(gdb) bt full
#0  __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:130
No locals.
#1  0x00005555557a3635 in unexec (
    new_name=0x55555702c248 <bss_sbrk_buffer+18876520> "/home/oscar/dev/emacs/build/src/emacs", 
    old_name=0x55555702c278 <bss_sbrk_buffer+18876568> "/home/oscar/dev/emacs/build/src/temacs") at ../../emacs/src/unexelf.c:406
        new_file = 6
        old_file = 5
        new_file_size = 1479866440
        new_break = 0x555557e2d000
        old_base = 0x7fffed274000 "\177ELF\002\001\001"
        new_base = 0x7fff94f24000 "\177ELF\002\001\001"
        old_file_h = 0x7fffed274000
        new_file_h = 0x7fff94f24000
        old_program_h = 0x7fffed274040
        new_program_h = 0x7fff94f24040
        old_section_h = 0x7fffedfe0588
        new_section_h = 0x7fffed272d88
        old_section_names = 0x7fffedfe0401 ""
        new_section_names = 0x0
        old_bss_seg = 0x7fffed2740e8
        new_bss_seg = 0x7fff94f240e8
        old_bss_addr = 8693760
        new_bss_addr = 93825035063296
        old_bss_size = 34134184
        bss_size_growth = 1465788416
        new_data2_size = 1465788416
        old_bss_offset = 6596608
        new_data2_offset = 6596608
        n = 0
        old_bss_index = 31
        stat_buf = {
          st_dev = 2050, 
          st_ino = 68041472, 
          st_nlink = 1, 
          st_mode = 33277, 
          st_uid = 1000, 
          st_gid = 1000, 
          __pad0 = 0, 
          st_rdev = 0, 
          st_size = 14078024, 
          st_blksize = 4096, 
          st_blocks = 27504, 
          st_atim = {
            tv_sec = 1476504568, 
            tv_nsec = 228299327
          }, 
          st_mtim = {
            tv_sec = 1476504568, 
            tv_nsec = 140297521
          }, 
          st_ctim = {
            tv_sec = 1476504568, 
            tv_nsec = 152297767
          }, 
          __glibc_reserved = {0, 0, 0}
        }
        old_file_size = 14078024
#2  0x00005555556b947e in Fdump_emacs (filename=93825019976356, symfile=93825019976324)
    at ../../emacs/src/emacs.c:2157
        tem = 0
        symbol = 14125536
        count = 20
#3  0x000055555575c6bf in eval_sub (form=93825005401091) at ../../emacs/src/eval.c:2190
        i = 2
        maxargs = 2
        args_left = 0
        numargs = 10
        fun = 93824997693589
        val = 0
        original_fun = 678816
        original_args = 93825006680323
        funcar = 93825001905715
        count = 19
        argvals = {93825020173636, 93825020173604, 93825001379152, 3914156642820, 0, 
          140737488345440, 93825001379152, 4294957424}
#4  0x0000555555758b6b in Fprogn (body=93825006680259) at ../../emacs/src/eval.c:432
        val = 0
#5  0x000055555575c2ad in eval_sub (form=93825005891267) at ../../emacs/src/eval.c:2140
        args_left = 93825006143363
        numargs = 26
        fun = 93825000899485
        val = 93825001905731
        original_fun = 37776
        original_args = 93825006143363
        funcar = 0
        count = 18
        argvals = {93825002017284, 93825001905747, 93825001379152, 93824994561541, 0, 
          140737488345776, 93825001379152, 23760}
#6  0x0000555555758a6b in Fif (args=93825005891283) at ../../emacs/src/eval.c:389
        cond = 93825001905731
#7  0x000055555575c2ad in eval_sub (form=93825001905987) at ../../emacs/src/eval.c:2140
        args_left = 93825005891283
        numargs = 10
        fun = 93825000899389
        val = 140737488346120
        original_fun = 26112
        original_args = 93825005891283
        funcar = 23760
        count = 17
        argvals = {140737488346144, 93824994375251, 0, 17, 140737488346144, 0, 
          93825001379152, 38352}
#8  0x000055555578c701 in readevalloop (readcharfun=23760, 
    stream=0x555555e65b80 <bss_sbrk_buffer+237984>, sourcename=93825002194596, 
    printflag=false, unibyte=0, readfun=0, start=0, end=0) at ../../emacs/src/lread.c:1929
        count1 = 17
        c = 40
        val = 93825001905987
        count = 13
        b = 0x0
        continue_reading_p = true
        lex_bound = 0
        whole_buffer = false
        first_sexp = false
        macroexpand = 0
#9  0x000055555578aef1 in Fload (file=93825002194340, noerror=0, nomessage=0, nosuffix=0, 
    must_suffix=0) at ../../emacs/src/lread.c:1334
        stream = 0x555555e65b80 <bss_sbrk_buffer+237984>
        fd = 4
        fd_index = 5
        count = 5
        found = 93825002194532
        efound = 46416
        hist_file_name = 93825002194596
        newer = false
        compiled = false
        handler = 93825000894935
        safe_p = true
        fmode = 0x55555583facf "r"
        version = 0
        is_elc = 0
#10 0x000055555575c755 in eval_sub (form=93825001898435) at ../../emacs/src/eval.c:2201
        i = 5
        maxargs = 5
        args_left = 0
        numargs = 6
        fun = 93825000908661
        val = 93825001889920
        original_fun = 30624
        original_args = 93825001898419
        funcar = 27696
        count = 4
        argvals = {93825002194340, 0, 0, 0, 0, 93824994374216, 0, 27696}
#11 0x000055555575bd3b in Feval (form=93825001898435, lexical=0)
    at ../../emacs/src/eval.c:2009
        count = 3
#12 0x00005555556bb435 in top_level_2 () at ../../emacs/src/keyboard.c:1127
No locals.
#13 0x000055555575a79a in internal_condition_case (bfun=0x5555556bb412 <top_level_2>, 
    handlers=18240, hfun=0x5555556bae9e <cmd_error>) at ../../emacs/src/eval.c:1314
        val = 93824993666832
        c = 0x555555ed6a00 <bss_sbrk_buffer+700448>
#14 0x00005555556bb47a in top_level_1 (ignore=0) at ../../emacs/src/keyboard.c:1135
No locals.
#15 0x000055555575a0a5 in internal_catch (tag=45120, func=0x5555556bb437 <top_level_1>, 
    arg=0) at ../../emacs/src/eval.c:1080
        val = 93824993666832
        c = 0x555555ed6c00 <bss_sbrk_buffer+700960>
#16 0x00005555556bb364 in command_loop () at ../../emacs/src/keyboard.c:1096
No locals.
#17 0x00005555556baa7d in recursive_edit_1 () at ../../emacs/src/keyboard.c:703
        count = 1
        val = 93824994374291
#18 0x00005555556babf6 in Frecursive_edit () at ../../emacs/src/keyboard.c:774
        count = 0
        buffer = 0
#19 0x00005555556b8768 in main (argc=5, argv=0x7fffffffe398) at ../../emacs/src/emacs.c:1659
        dummy = 140737304496000
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = true
        dumping = true
        skip_args = 3
        no_loadup = false
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0
        original_pwd = 0x0
        disable_aslr = true
        rlim = {
          rlim_cur = 8720384, 
          rlim_max = 18446744073709551615
        }
        sockfd = -1

Lisp Backtrace:
"dump-emacs" (0xffffd920)
"progn" (0xffffd9e8)
"if" (0xffffdb38)
"load" (0xffffdfa0)

Re: Emacs 25 from GIT build issue under Ubuntu 16.10

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 15 Oct 2016 06:15:04 +0200
> 
> Tim Cross <theophilusx@gmail.com> writes:
> 
> > After upgrade to ubuntu gnome 16.10, attempts to build from fresh git clone
> > of emacs repo gives an seg fault error when trying to run dumped image. All
> > was working fine under Ubuntu 16.04.
> 
> (gdb) bt full
> #0  __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:130
> No locals.
> #1  0x00005555557a3635 in unexec (
>     new_name=0x55555702c248 <bss_sbrk_buffer+18876520> "/home/oscar/dev/emacs/build/src/emacs", 
>     old_name=0x55555702c278 <bss_sbrk_buffer+18876568> "/home/oscar/dev/emacs/build/src/temacs") at ../../emacs/src/unexelf.c:406
>         new_file = 6
>         old_file = 5
>         new_file_size = 1479866440
>         new_break = 0x555557e2d000
>         old_base = 0x7fffed274000 "\177ELF\002\001\001"
>         new_base = 0x7fff94f24000 "\177ELF\002\001\001"
>         old_file_h = 0x7fffed274000
>         new_file_h = 0x7fff94f24000
>         old_program_h = 0x7fffed274040
>         new_program_h = 0x7fff94f24040
>         old_section_h = 0x7fffedfe0588
>         new_section_h = 0x7fffed272d88
>         old_section_names = 0x7fffedfe0401 ""
>         new_section_names = 0x0
>         old_bss_seg = 0x7fffed2740e8
>         new_bss_seg = 0x7fff94f240e8
>         old_bss_addr = 8693760
>         new_bss_addr = 93825035063296
>         old_bss_size = 34134184
>         bss_size_growth = 1465788416

Yes, exactly as reported in bug#24682.

Re: Emacs 25 from GIT build issue under Ubuntu 16.10

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Date: Sat, 15 Oct 2016 10:06:13 +1100
> 
> After upgrade to ubuntu gnome 16.10, attempts to build from fresh git clone of emacs repo gives an seg fault
> error when trying to run dumped image. All was working fine under Ubuntu 16.04.
> 
> Loading /home/tcross/git/emacs/lisp/electric.el (source)...
> Loading /home/tcross/git/emacs/lisp/emacs-lisp/eldoc.el (source)...
> Loading /home/tcross/git/emacs/lisp/cus-start.el (source)...
> Loading /home/tcross/git/emacs/lisp/tooltip.el (source)...
> Finding pointers to doc strings...
> Finding pointers to doc strings...done
> Dumping under the name emacs
> 20812288 of 33554432 static heap bytes used
> Makefile:749: recipe for target 'bootstrap-emacs' failed
> make[1]: *** [bootstrap-emacs] Segmentation fault (core dumped)
> make[1]: Leaving directory '/home/tcross/git/emacs/src'
> Makefile:398: recipe for target 'src' failed
> make: *** [src] Error 2

This is bug#24682, please follow up there.

bug#24682: Emacs 25 from GIT build issue under Ubuntu 16.10

[Paul Eggert]

On 10/15/2016 12:56 AM, Eli Zaretskii wrote:
> This is bug#24682, please follow up there. 

configure.ac on emacs-25 knows about this problem, and attempts to build 
Emacs with -nopie. Please investigate why this is not working on Ubuntu 
16.10. I assume './configure' is outputting a string like "checking 
whether gcc accepts -nopie... no"; why is that? Try looking in 
config.log near the string "accepts -nopie".

As noted in configure.ac, this problem has occurred before; see 
Bug#18784 and Bug#20338. Possibly we merely need to tweak configure.ac 
to pacify Ubuntu's variant of GCC.

bug#24682: Emacs 25 from GIT build issue under Ubuntu 16.10

[Cesar Quiroz]

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

-no-pie versus -nopie

There was something in the release notes about -no-pie being the standard
negation of -pie, while -nopie was introduced (by Debian?) to deal with the
issue.

Relevant snippet from config.log:

configure:31624: checking whether gcc accepts -nopie
configure:31644: gcc -o conftest -no-pie      -nopie conftest.c   >&5
gcc: error: unrecognized command line option '-nopie'; did you mean
'-no-pie'?
configure:31644: $? = 1


--César

On Sat, Oct 15, 2016 at 9:51 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 10/15/2016 12:56 AM, Eli Zaretskii wrote:
>
>> This is bug#24682, please follow up there.
>>
>
> configure.ac on emacs-25 knows about this problem, and attempts to build
> Emacs with -nopie. Please investigate why this is not working on Ubuntu
> 16.10. I assume './configure' is outputting a string like "checking whether
> gcc accepts -nopie... no"; why is that? Try looking in config.log near the
> string "accepts -nopie".
>
> As noted in configure.ac, this problem has occurred before; see Bug#18784
> and Bug#20338. Possibly we merely need to tweak configure.ac to pacify
> Ubuntu's variant of GCC.
>

[-- Attachment #2: Type: text/html, Size: 2257 bytes --]

bug#24682: Emacs 25 from GIT build issue under Ubuntu 16.10

[Eli Zaretskii]

> From: Cesar Quiroz <cesar.quiroz@gmail.com>
> Date: Sat, 15 Oct 2016 22:31:46 -0700
> Cc: Michael Albinus <michael.albinus@gmx.de>, 24682@debbugs.gnu.org, 
> 	Óscar Fuentes <ofv@wanadoo.es>, Eli Zaretskii <eliz@gnu.org>, 
> 	Tim Cross <theophilusx@gmail.com>
> 
> -no-pie versus -nopie
> 
> There was something in the release notes about -no-pie being the standard negation of -pie, while -nopie was
> introduced (by Debian?) to deal with the issue.
> 
> Relevant snippet from config.log:
> 
> configure:31624: checking whether gcc accepts -nopie
> configure:31644: gcc -o conftest -no-pie -nopie conftest.c >&5 
> gcc: error: unrecognized command line option '-nopie'; did you mean '-no-pie'?
> configure:31644: $? = 1

I guess the fix, whatever it is, should be backported to the release
branch?

bug#24682: Emacs 25 from GIT build issue under Ubuntu 16.10

[Cesar Quiroz]

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

Probably just clone the -nopie AC check macro with -no-pie, and just pass
whichever, if any, wins.

--César

On Sat, Oct 15, 2016 at 11:54 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Cesar Quiroz <cesar.quiroz@gmail.com>
> > Date: Sat, 15 Oct 2016 22:31:46 -0700
> > Cc: Michael Albinus <michael.albinus@gmx.de>, 24682@debbugs.gnu.org,
> >       Óscar Fuentes <ofv@wanadoo.es>, Eli Zaretskii <eliz@gnu.org>,
> >       Tim Cross <theophilusx@gmail.com>
> >
> > -no-pie versus -nopie
> >
> > There was something in the release notes about -no-pie being the
> standard negation of -pie, while -nopie was
> > introduced (by Debian?) to deal with the issue.
> >
> > Relevant snippet from config.log:
> >
> > configure:31624: checking whether gcc accepts -nopie
> > configure:31644: gcc -o conftest -no-pie -nopie conftest.c >&5
> > gcc: error: unrecognized command line option '-nopie'; did you mean
> '-no-pie'?
> > configure:31644: $? = 1
>
> I guess the fix, whatever it is, should be backported to the release
> branch?
>

[-- Attachment #2: Type: text/html, Size: 1845 bytes --]

bug#24682: Emacs 25 from GIT build issue under Ubuntu 16.10

[Paul Eggert]

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

Cesar Quiroz wrote:
> There was something in the release notes about -no-pie being the standard
> negation of -pie, while -nopie was introduced (by Debian?) to deal with the
> issue.

Which release notes?

I installed the attached into the Emacs master branch; does it fix the problem? 
If so, I'll backport it to emacs-25 and ask you to test that.

[-- Attachment #2: 0001-Port-to-Ubuntu-16.10-which-needs-gcc-nopie.patch --]
[-- Type: text/x-diff, Size: 2613 bytes --]

From e5f26dd7f1af4bf54091a52adc3587f6a228e641 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 16 Oct 2016 16:25:47 -0700
Subject: [PATCH] Port to Ubuntu 16.10, which needs gcc -nopie

* configure.ac (emacs_cv_prog_cc_no_pie): Rename from
emacs_cv_prog_cc_nopie.  All usages changed.  Check for -no-pie in
preference to -nopie (Bug#24682).
---
 configure.ac | 32 ++++++++++++++++++--------------
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/configure.ac b/configure.ac
index cd11b10..3f06eff 100644
--- a/configure.ac
+++ b/configure.ac
@@ -5123,25 +5123,29 @@ AC_DEFUN
   *) LD_SWITCH_SYSTEM_TEMACS= ;;
 esac
 
-# -nopie fixes a temacs segfault on Gentoo, OpenBSD, and other systems
-# with "hardened" GCC configurations for some reason (Bug#18784).
-# We don't know why -nopie works, but not segfaulting is better than
-# segfaulting.  Use ac_c_werror_flag=yes when trying -nopie, otherwise
-# clang keeps warning that it does not understand -nopie, and pre-4.6
-# GCC has a similar problem (Bug#20338).
-AC_CACHE_CHECK([whether $CC accepts -nopie],
-  [emacs_cv_prog_cc_nopie],
+# -no-pie or -nopie fixes a temacs segfault on Gentoo, OpenBSD,
+# Ubuntu, and other systems with "hardened" GCC configurations for
+# some reason (Bug#18784).  We don't know why this works, but not
+# segfaulting is better than segfaulting.  Use ac_c_werror_flag=yes
+# when trying the option, otherwise clang keeps warning that it does
+# not understand it, and pre-4.6 GCC has a similar problem
+# (Bug#20338).  Prefer -no-pie to -nopie, as -no-pie is the
+# spelling used by GCC 6.1.0 and later (Bug#24682).
+AC_CACHE_CHECK(
+  [for $CC option to disable position independent executables],
+  [emacs_cv_prog_cc_no_pie],
   [emacs_save_c_werror_flag=$ac_c_werror_flag
    emacs_save_LDFLAGS=$LDFLAGS
    ac_c_werror_flag=yes
-   LDFLAGS="$LDFLAGS -nopie"
-   AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])],
-     [emacs_cv_prog_cc_nopie=yes],
-     [emacs_cv_prog_cc_nopie=no])
+   for emacs_cv_prog_cc_no_pie in -no-pie -nopie no; do
+     test $emacs_cv_prog_cc_no_pie = no && break
+     LDFLAGS="$emacs_save_LDFLAGS $emacs_cv_prog_cc_no_pie"
+     AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])], [break])
+   done
    ac_c_werror_flag=$emacs_save_c_werror_flag
    LDFLAGS=$emacs_save_LDFLAGS])
-if test "$emacs_cv_prog_cc_nopie" = yes; then
-  LD_SWITCH_SYSTEM_TEMACS="$LD_SWITCH_SYSTEM_TEMACS -nopie"
+if test "$emacs_cv_prog_cc_no_pie" != no; then
+  LD_SWITCH_SYSTEM_TEMACS="$LD_SWITCH_SYSTEM_TEMACS $emacs_cv_prog_cc_no_pie"
 fi
 
 if test x$ac_enable_profiling != x ; then
-- 
2.7.4

bug#24682: Emacs 25 from GIT build issue under Ubuntu 16.10

[Cesar Quiroz]

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

--César

On Sun, Oct 16, 2016 at 4:56 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:

> Cesar Quiroz wrote:
>
>> There was something in the release notes about -no-pie being the standard
>> negation of -pie, while -nopie was introduced (by Debian?) to deal with
>> the
>> issue.
>>
>
> Which release notes?
>

I meant 16.10:  https://wiki.ubuntu.com/YakketyYak/ReleaseNotes, and from
there specifically:

https://wiki.ubuntu.com/SecurityTeam/PIE


> I installed the attached into the Emacs master branch; does it fix the
> problem? If so, I'll backport it to emacs-25 and ask you to test that.
>

Works for master; ready to test emacs-25.

For reference, I did a 'git clean -fdx' in the git workdir, autogen, and
then I configured the build area with

$ ./config.status --config
'--with-x-toolkit=gtk3' '--with-file-notification=yes' '--with-modules'
$

[-- Attachment #2: Type: text/html, Size: 1866 bytes --]

bug#24682: Emacs 25 from GIT build issue under Ubuntu 16.10

[Cesar Quiroz]

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

I applied the patch to my local copy of emacs-25, and it built fine.  Will
test the official port when available.

Going back to the master branch build, the log shows a warning, unrelated
to the -no-pie issue:

  CC       gmalloc.o
/work/emacs/master/src/gmalloc.c:1760:1: warning: no previous prototype for
‘hybrid_aligned_alloc’ [-Wmissing-prototypes]
 hybrid_aligned_alloc (size_t alignment, size_t size)
 ^~~~~~~~~~~~~~~~~~~~

This is not happening in the emacs-25 branch. Maybe the conditional
compilation is hiding a prototype in master but not in emacs-25. I will
take another look, and report it tomorrow if I can confirm the difference.


--César

On Sun, Oct 16, 2016 at 8:04 PM, Cesar Quiroz <cesar.quiroz@gmail.com>
wrote:

>
>
> --César
>
> On Sun, Oct 16, 2016 at 4:56 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
>
>> Cesar Quiroz wrote:
>>
>>> There was something in the release notes about -no-pie being the standard
>>> negation of -pie, while -nopie was introduced (by Debian?) to deal with
>>> the
>>> issue.
>>>
>>
>> Which release notes?
>>
>
> I meant 16.10:  https://wiki.ubuntu.com/YakketyYak/ReleaseNotes, and from
> there specifically:
>
> https://wiki.ubuntu.com/SecurityTeam/PIE
>
>
>> I installed the attached into the Emacs master branch; does it fix the
>> problem? If so, I'll backport it to emacs-25 and ask you to test that.
>>
>
> Works for master; ready to test emacs-25.
>
> For reference, I did a 'git clean -fdx' in the git workdir, autogen, and
> then I configured the build area with
>
> $ ./config.status --config
> '--with-x-toolkit=gtk3' '--with-file-notification=yes' '--with-modules'
> $
>
>
>

[-- Attachment #2: Type: text/html, Size: 3426 bytes --]

bug#24682: Emacs 25 from GIT build issue under Ubuntu 16.10

[Paul Eggert]

Cesar Quiroz wrote:
> I applied the patch to my local copy of emacs-25, and it built fine.  Will
> test the official port when available.

Thanks, I have installed the patch into the emacs-25 branch and am marking this 
bug as done.

bug#24682: Emacs 25 from GIT build issue under Ubuntu 16.10

[Cesar Quiroz]

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

Paul, thanks to you. I just rechecked after a pull, and all looks fine
still.

--César

On Sun, Oct 16, 2016 at 11:18 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:

> Cesar Quiroz wrote:
>
>> I applied the patch to my local copy of emacs-25, and it built fine.  Will
>> test the official port when available.
>>
>
> Thanks, I have installed the patch into the emacs-25 branch and am marking
> this bug as done.
>

[-- Attachment #2: Type: text/html, Size: 949 bytes --]