emacs24/25 FTBFS since a long time on GNU/Hurd

emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

Hello,

I'm not subscribed to emacs-devel, but hope to get this mail through anyway.

Since a long time emacs FTBFS due to unknown reasons. The latest version
building was Debian 24.5+1-5, from 27 Nov 2015. Even before successful builds
were by pure luck. One suspicious issue is that emacs use sbrk() for memory
allocation, right? Notably sbrk() is not fool-proof as implemented for Hurd in
glibc. Use of sbrk is found in files alloc.c, unexelf.c and gmalloc.c, which are
all compiled. Avoiding compilation of ralloc.c with 0001-Default-REL_ALLOC-to-
no.patch did not improve the situation.

First time I compiled emacs 25.1 from upstream it passed, second time not.
Compiling Debian versions almost always fail. Moslty the build fails with temacs
failing to execute: Killed. In my opionion it's a real loss not to gave a modern
version of emacs25 available for use in GNU/Hurd (not everybody use vi).

Do anybody of you have an idea on how to solve this problem? Are there patches
available already to try with?

Thanks in advance :)

Re: emacs24/25 FTBFS since a long time on GNU/Hurd

[Paul Eggert]

I created Bug#24857 for this and plan to follow up there 
<http://bugs.gnu.org/24857>.

Re: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Date: Wed, 02 Nov 2016 15:16:54 +0100
> 
> First time I compiled emacs 25.1 from upstream it passed, second time not.
> Compiling Debian versions almost always fail. Moslty the build fails with temacs
> failing to execute: Killed. In my opionion it's a real loss not to gave a modern
> version of emacs25 available for use in GNU/Hurd (not everybody use vi).
> 
> Do anybody of you have an idea on how to solve this problem?

My suggestion is to run the failing temacs command line under GDB and
see where it crashes.

The best way to communicate this information is to file a bug report,
using "M-x report-emacs-bug RET" (in some version of Emacs you have
that is operable; if not, just email the details to
bug-gnu-emacs@gnu.org).

Re: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

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

On Wed, 2016-11-02 at 17:39 +0200, Eli Zaretskii wrote:
> > 
> > From: Svante Signell <svante.signell@gmail.com>
> > Date: Wed, 02 Nov 2016 15:16:54 +0100
> > 
> > First time I compiled emacs 25.1 from upstream it passed, second time not.
> > Compiling Debian versions almost always fail. Moslty the build fails with
> > temacs
> > failing to execute: Killed. In my opionion it's a real loss not to gave a
> > modern
> > version of emacs25 available for use in GNU/Hurd (not everybody use vi).
> > 
> > Do anybody of you have an idea on how to solve this problem?
> My suggestion is to run the failing temacs command line under GDB and
> see where it crashes.

Hi, attached is a traceback from gdb. Edited to remove thousands of loops, as
indicated in that file.

> The best way to communicate this information is to file a bug report,
> using "M-x report-emacs-bug RET" (in some version of Emacs you have
> that is operable; if not, just email the details to
> bug-gnu-emacs@gnu.org).

A bug was already filed by Paul Eggert, https://debbugs.gnu.org/cgi/bugreport.cg
i?bug=24857

Thanks anyway.

[-- Attachment #2: gdb_edited.txt --]
[-- Type: text/plain, Size: 15677 bytes --]

gdb ./temacs
(gdb) run --batch --load loadup bootstrap
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/srs/DEBs/emacs/emacs25-25.1+1/debian/build-x/src/temacs --batch --load loadup bootstrap

Thread 4 received signal ?, Unknown signal.
0x051dcc63 in __vm_allocate (target_task=1, address=0x2d03c, size=12288, anywhere=0)
    at /home/srs/DEBs/glibc/2.24/glibc-2.24/build-tree/hurd-i386-libc/mach/vm_allocate.c:54
54      /home/srs/DEBs/glibc/2.24/glibc-2.24/build-tree/hurd-i386-libc/mach/vm_allocate.c: No such file or directory.
(gdb) thread apply all bt full

Thread 4 (Thread 25492.4):
#0  0x051dcc63 in __vm_allocate (target_task=1, address=0x2d03c, size=12288, anywhere=0)
    at /home/srs/DEBs/glibc/2.24/glibc-2.24/build-tree/hurd-i386-libc/mach/vm_allocate.c:54
        err = <optimized out>
#1  0x052ef5f2 in _hurd_set_brk (addr=139247616) at ../sysdeps/mach/hurd/brk.c:116
        alloc_start = 139235328
        err = <optimized out>
        pagend = 139247616
        pagebrk = 139235328
        rlimit = <optimized out>
#2  0x052efaaf in __sbrk (increment=12288) at ../sysdeps/mach/hurd/sbrk.c:33
        result = 0x84c9000
#3  0x0820202c in __default_morecore (increment=12288) at gmalloc.c:1532
        result = <optimized out>
#4  0x08201e35 in align (size=size@entry=12288) at gmalloc.c:445
        result = <optimized out>
        adj = <optimized out>
#5  0x08201fa3 in malloc_initialize_1 () at gmalloc.c:571
No locals.
#6  0x082020fd in __malloc_initialize () at gmalloc.c:597
No locals.
#7  gmalloc (size=100) at gmalloc.c:934
        hook = <optimized out>
#8  0x082033d5 in malloc (size=100) at gmalloc.c:1822
No locals.
#9  0x05262c8c in _IO_vasprintf (result_ptr=0x2d228, 
    format=0x5369100 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    args=0x2d1f8 "\377A6\005\377A6\005\027\317\026\005\034") at vasprintf.c:47
        string = <optimized out>
        sf = {_sbf = {_f = {_flags = 0, _IO_read_ptr = 0x0, 
              _IO_read_end = 0x84cc000 "\340", <incomplete sequence \302>, 
              _IO_read_base = 0x84c9000 "\177ELF\001\001\001", 
              _IO_write_base = 0x43 <error: Cannot access memory at address 0x43>, 
              _IO_write_ptr = 0x0, 
              _IO_write_end = 0x51f9f29 <__hurd_sigstate_lock+9> "\201\303\327\300\035", 
              _IO_buf_base = 0x51dd116 <__mach_msg+54> "\203\304 \205\300tF\366D$4@tj\367D$4", _IO_buf_end = 0x2d1b0 "", 
              _IO_save_base = 0x3 <error: Cannot access memory at address 0x3>, 
              _IO_backup_base = 0x30 <error: Cannot access memory at address 0x30>, 
              _IO_save_end = 0x20 <error: Cannot access memory at address 0x20>, 
              _markers = 0x253, _chain = 0x0, _fileno = 0, _flags2 = 1667393900, 
              _old_offset = 7302446, _cur_column = 23165, _vtable_offset = 54 '6', 
              _shortbuf = "\005", _lock = 0x521d525 <__current_locale_name+5>, 
              _offset = 375144790433592650, _codecvt = 0x53d86b4 <root>, 
              _wide_data = 0x51dd0e9 <__mach_msg+9>, _freeres_list = 0x7fd9000, 
              _freeres_buf = 0x516cf2c <__PRETTY_FUNCTION__.9369>, __pad5 = 134505880, 
              _mode = 16961000, 
              _unused2 = "\230\271\374\a\260\321\002\000\003\000\000\000\060\000\000\000\253\271\374\aS\002\000\000\000\000\000\000\000\000\000\000l\271\374\ap\321\002"}, 
            vtable = 0x40000009}, _s = {_allocate_buffer = 0x0, _free_buffer = 0x0}}
        ret = <optimized out>
        needed = <optimized out>
        allocated = <optimized out>
#10 0x05244694 in ___asprintf (string_ptr=0x2d228, 
    format=0x5369100 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n") at asprintf.c:35
        arg = 0x2d1f8 "\377A6\005\377A6\005\027\317\026\005\034"
        done = 184380
#11 0x0521d64c in __assert_fail_base (
    fmt=0x5369100 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=0x516cc49 "__pthread_threads", file=0x516cf17 "./pthread/pt-self.c", 
    line=28, function=0x516cf2c <__PRETTY_FUNCTION__.9369> "__pthread_self") at assert.c:57
        str = 0x0
        total = 86103528
#12 0x0521d75a in __assert_fail (assertion=0x516cc49 "__pthread_threads", 
    file=0x516cf17 "./pthread/pt-self.c", line=28, 
    function=0x516cf2c <__PRETTY_FUNCTION__.9369> "__pthread_self") at assert.c:101
No locals.
#13 0x05168696 in __pthread_self () at ./pthread/pt-self.c:28
        thread = <optimized out>
        self = <optimized out>
        self = <optimized out>
#14 0x05224e8e in raise (signo=6) at ../sysdeps/../libpthread/sysdeps/generic/raise.c:37
        err = <optimized out>
#15 0x052276cf in abort () at abort.c:89
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0x5369100, sa_sigaction = 0x5369100}, 
          sa_mask = 87441919, sa_flags = 87908352}
        sigs = 32
#16 0x0521d6f4 in __assert_fail_base (
    fmt=0x5369100 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=0x516cc49 "__pthread_threads", file=0x516cf17 "./pthread/pt-self.c", 
    line=28, function=0x516cf2c <__PRETTY_FUNCTION__.9369> "__pthread_self") at assert.c:92
        str = 0x0
        total = 86103528
#17 0x0521d75a in __assert_fail (assertion=0x516cc49 "__pthread_threads", 
    file=0x516cf17 "./pthread/pt-self.c", line=28, 
    function=0x516cf2c <__PRETTY_FUNCTION__.9369> "__pthread_self") at assert.c:101
No locals.
#18 0x05168696 in __pthread_self () at ./pthread/pt-self.c:28
        thread = <optimized out>
        self = <optimized out>
        self = <optimized out>
#19 0x05224e8e in raise (signo=6) at ../sysdeps/../libpthread/sysdeps/generic/raise.c:37
        err = <optimized out>
#20 0x052276cf in abort () at abort.c:89
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0x5369100, sa_sigaction = 0x5369100}, 
          sa_mask = 87441919, sa_flags = 87908352}
        sigs = 32
#16+17+18+19+20 loops from here
...
#374446 0x0521d6f4 in __assert_fail_base (fmt=0x5369100 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x516cc49 "__pthread_threads", file=0x516cf17 "./pthread/pt-self.c", line=28, function=0x516cf2c <__PRETTY_FUNCTION__.9369> "__pthread_self") at assert.c:92
        str = 0x0
        total = 86103528
#374447 0x0521d75a in __assert_fail (assertion=0x516cc49 "__pthread_threads", file=0x516cf17 "./pthread/pt-self.c", line=28, function=0x516cf2c <__PRETTY_FUNCTION__.9369> "__pthread_self") at assert.c:101
No locals.
#374448 0x05168696 in __pthread_self () at ./pthread/pt-self.c:28
        thread = <optimized out>
        self = <optimized out>
        self = <optimized out>
#374449 0x05224e8e in raise (signo=6) at ../sysdeps/../libpthread/sysdeps/generic/raise.c:37
        err = <optimized out>
#374450 0x052276cf in abort () at abort.c:89
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0x53d6000, sa_sigaction = 0x53d6000}, sa_mask = 85383452, sa_flags = 16959788}
        sigs = 32
#374451 0x0521d6f4 in __assert_fail_base (fmt=0x5369140 "%s%s%s:%u: %s%sUnexpected error: %s.\n", assertion=0x53646db "Cannot allocate memory", file=0x516d8f0 "../libpthread/sysdeps/mach/hurd/pt-sysdep.c", line=67, function=0x516d91c <__PRETTY_FUNCTION__.9436> "_init_routine") at assert.c:92
        str = 0x0
        total = 86103528
#374452 0x0521d7bf in __assert_perror_fail (errnum=1073741836, file=0x516d8f0 "../libpthread/sysdeps/mach/hurd/pt-sysdep.c", line=67, function=0x516d91c <__PRETTY_FUNCTION__.9436> "_init_routine") at assert-perr.c:35
        errbuf = "\001\000\000\000\300r\375\001@\311\002\001'\336\000\000\360\333\000\000Е\000\000\240\061\035\005\240\061\035\005\001\000\000\000\024\312\002\001\000 \000\000\000\000\000\000\001\000\000\000v\032i\t\000\000\000\000\000\000\000\000\251\224\000\000\000\260\002\000\f\001\034\005\330\310\350\004\236\002\000\000˝\000\000\005\000\000\000\001\000\000\000$I\034\005\020\225\000\000\310/\374\a;\316\034\005$\312\002\001 \312\002\001\000 \000\000\310\f\004\b}\000\000\000;\316\034\005\223\365\034\005j\315yy\251\224\000\000\000\260\002\000<\020\374\ax\204\336\a\375\000\000\000˝\000\000\005\000\000\000\001\000\000\000d!\374\aЕ\000\000\255\062\035\005\255\062\035\005t\312\002\001p\312\002\001\240\061\035\005"...
        e = 0x53646db "Cannot allocate memory"
#374453 0x0516bb99 in _init_routine (stack=0x0) at ../libpthread/sysdeps/mach/hurd/pt-sysdep.c:67
        thread = 0x0
        err = <optimized out>
        attr = {__schedparam = {__sched_priority = 0}, __stackaddr = 0x7, __stacksize = 1, __guardsize = 85910395, __detachstate = (unknown: 87916512), __inheritsched = (unknown: 3084914), __contentionscope = (unknown: 1866732), __schedpolicy = 85375740}
        attrp = 0x0
#374454 0x05210a33 in init (data=0x102cdf0) at ../sysdeps/mach/hurd/i386/init-first.c:213
        newsp = <optimized out>
        od = <optimized out>
        argv = 0x102cdf4
        argc = <optimized out>
        envp = 0x102ce68
        d = 0x102ce68
#374455 _dl_init_first (argc=<optimized out>) at ../sysdeps/mach/hurd/i386/init-first.c:327
No locals.
#374456 0x00001e06 in _dl_start_user () from /lib/ld.so
        audit_list = 0x0
        _dl_rtld_libname2 = {name = 0x0, next = 0x0, dont_free = 0}
        library_path = 0x0
        any_debug = 0
        tls_init_tp_called = true
        preloadlist = 0x0
        version_info = 0
        _dl_rtld_libname = {name = 0x8048154 "/lib/ld.so", next = 0x2b7ec <newname>, dont_free = 0}
        _dl_argv = 0x102cdf4
        _dl_starting_up = 1
        _dl_skip_args = 0
        _rtld_global = {_dl_ns = {{_ns_loaded = 0x2b938, _ns_nloaded = 125, _ns_main_searchlist = 0x2ba94, _ns_global_scope_alloc = 0, _ns_unique_sym_table = {lock = {lock = 0, cnt = 0, owner = 0x0}, entries = 0x86fd000, size = 251, n_elements = 98, free = 0x18740 <free>}, _ns_debug = {r_version = 0, r_map = 0x0, r_brk = 0, r_state = RT_CONSISTENT, r_ldbase = 0}}, {_ns_loaded = 0x0, _ns_nloaded = 0, _ns_main_searchlist = 0x0, _ns_global_scope_alloc = 0, _ns_unique_sym_table = {lock = {lock = 0, cnt = 0, owner = 0x0}, entries = 0x0, size = 0, n_elements = 0, free = 0x0}, _ns_debug = {r_version = 0, r_map = 0x0, r_brk = 0, r_state = RT_CONSISTENT, r_ldbase = 0}} <repeats 15 times>}, _dl_nns = 1, _dl_load_lock = {lock = 0, cnt = 0, owner = 0x0}, _dl_load_write_lock = {lock = 0, cnt = 0, owner = 0x0}, _dl_load_adds = 125, _dl_initfirst = 0x0, _dl_profile_map = 0x0, _dl_num_relocations = 25252, _dl_num_cache_relocations = 36248, _dl_all_dirs = 0x5708378, _dl_error_catch_tsd = 0x1e40 <_dl_initial_error_catch_tsd>, _dl_rtld_map = {l_addr = 4096, l_name = 0x8048154 "/lib/ld.so", l_ld = 0x2af04, l_next = 0x4e8cb90, l_prev = 0x4e8c8d8, l_real = 0x2b4bc <_rtld_global+1084>, l_ns = 0, l_libname = 0x2b808 <_dl_rtld_libname>, l_info = {0x0, 0x0, 0x2af44, 0x2af3c, 0x2af0c, 0x2af1c, 0x2af24, 0x0, 0x0, 0x0, 0x2af2c, 0x2af34, 0x0, 0x0, 0x2af04, 0x0, 0x0, 0x2af5c, 0x2af64, 0x2af6c, 0x2af4c, 0x0, 0x0, 0x2af54, 0x0 <repeats 12 times>, 0x2af7c, 0x2af74, 0x0, 0x2af8c, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2af84, 0x0 <repeats 25 times>, 0x2af14}, l_phdr = 0x1034, l_entry = 0, l_phnum = 7, l_ldnum = 0, l_searchlist = {r_list = 0x0, r_nlist = 0}, l_symbolic_searchlist = {r_list = 0x0, r_nlist = 0}, l_loader = 0x0, l_versions = 0x8043580, l_nversions = 6, l_nbuckets = 37, l_gnu_bitmask_idxbits = 7, l_gnu_shift = 8, l_gnu_bitmask = 0x12a0, {l_gnu_buckets = 0x12c0, l_chain = 0x12c0}, {l_gnu_chain_zero = 0x1350, l_buckets = 0x1350}, l_direct_opencount = 0, l_type = lt_library, l_relocated = 1, l_init_called = 0, l_global = 1, l_reserved = 0, l_phdr_allocated = 0, l_soname_added = 0, l_faked = 0, l_need_tls_init = 0, l_auditing = 0, l_audit_any_plt = 0, l_removed = 0, l_contiguous = 0, l_symbolic_in_local_scope = 0, l_free_initfini = 0, l_rpath_dirs = {dirs = 0x0, malloced = 0}, l_reloc_result = 0x0, l_versyms = 0x1982, l_origin = 0x0, l_map_start = 4096, l_map_end = 178484, l_text_end = 129229, l_scope_mem = {0x0, 0x0, 0x0, 0x0}, l_scope_max = 0, l_scope = 0x0, l_local_scope = {0x0, 0x0}, l_file_id = {dev = 0, ino = 0}, l_runpath_dirs = {dirs = 0x0, malloced = 0}, l_initfini = 0x0, l_reldeps = 0x0, l_reldepsmax = 0, l_used = 1, l_feature_1 = 0, l_flags_1 = 0, l_flags = 0, l_idx = 0, l_mach = {plt = 0, gotplt = 0, tlsdesc_table = 0x0}, l_lookup_cache = {sym = 0x157c, type_class = 1, value = 0x4e8c8d8, ret = 0x51c8024}, l_tls_initimage = 0x0, l_tls_initimage_size = 0, l_tls_blocksize = 0, l_tls_align = 0, l_tls_firstbyte_offset = 0, l_tls_offset = 0, l_tls_modid = 0, l_tls_dtor_count = 0, l_relro_addr = 171200, l_relro_size = 832, l_serial = 0, l_audit = 0x2b714 <_rtld_global+1684>}, audit_data = {{cookie = 0, bindflags = 0} <repeats 16 times>}, _dl_make_stack_executable_hook = 0x13480 <_dl_make_stack_executable>, _dl_stack_flags = 7, _dl_tls_dtv_gaps = false, _dl_tls_max_dtv_idx = 8, _dl_tls_dtv_slotinfo_list = 0x8045ad0, _dl_tls_static_nelem = 8, _dl_tls_static_size = 2248, _dl_tls_static_used = 520, _dl_tls_static_align = 4, _dl_initial_dtv = 0x80465e0, _dl_tls_generation = 1, _dl_init_static_tls = 0xbb00 <_dl_nothread_init_static_tls>, _dl_wait_lookup_done = 0x0, _dl_scope_free_list = 0x0, _dl_thread_gscope_count = 0}
        __stack_chk_guard = 4278845440
        __pointer_chk_guard_local = 4278845440
        _rtld_global_ro = {_dl_debug_mask = 0, _dl_osversion = 0, _dl_platform = 0x0, _dl_platformlen = 0, _dl_pagesize = 4096, _dl_inhibit_cache = 0, _dl_initial_searchlist = {r_list = 0x8040cc8, r_nlist = 125}, _dl_clktck = 0, _dl_verbose = 0, _dl_debug_fd = 2, _dl_lazy = 1, _dl_bind_not = 0, _dl_dynamic_weak = 0, _dl_fpu_control = 895, _dl_correct_cache_id = 3, _dl_hwcap = 0, _dl_hwcap_mask = 67141632, _dl_x86_cpu_features = {kind = arch_kind_unknown, max_cpuid = 0, cpuid = {{eax = 0, ebx = 0, ecx = 0, edx = 0}, {eax = 0, ebx = 0, ecx = 0, edx = 0}, {eax = 0, ebx = 0, ecx = 0, edx = 0}}, family = 0, model = 0, feature = {0}}, _dl_x86_cap_flags = {"fpu\000\000\000\000", "vme\000\000\000\000", "de\000\000\000\000\000", "pse\000\000\000\000", "tsc\000\000\000\000", "msr\000\000\000\000", "pae\000\000\000\000", "mce\000\000\000\000", "cx8\000\000\000\000", "apic\000\000\000", "10\000\000\000\000\000", "sep\000\000\000\000", "mtrr\000\000\000", "pge\000\000\000\000", "mca\000\000\000\000", "cmov\000\000\000", "pat\000\000\000\000", "pse36\000\000", "pn\000\000\000\000\000", "clflush", "20\000\000\000\000\000", "dts\000\000\000\000", "acpi\000\000\000", "mmx\000\000\000\000", "fxsr\000\000\000", "sse\000\000\000\000", "sse2\000\000\000", "ss\000\000\000\000\000", "ht\000\000\000\000\000", "tm\000\000\000\000\000", "ia64\000\000\000", "pbe\000\000\000\000"}, _dl_x86_platforms = {"i386", "i486", "i586", "i686"}, _dl_inhibit_rpath = 0x0, _dl_origin_path = 0x102e6d7 "/home/srs/DEBs/emacs/emacs25-25.1+1/debian/build-x/src", _dl_use_load_bias = 4294967295, _dl_profile = 0x0, _dl_profile_output = 0x1f8e0 "/var/tmp", _dl_trace_prelink = 0x0, _dl_trace_prelink_map = 0x0, _dl_init_all_dirs = 0x5708378, _dl_hwcap2 = 0, _dl_debug_printf = 0x10d50 <_dl_debug_printf>, _dl_catch_error = 0xfca0 <_dl_catch_error>, _dl_signal_error = 0xfa30 <_dl_signal_error>, _dl_mcount = 0x11f60 <_dl_mcount>, _dl_lookup_symbol_x = 0xa250 <_dl_lookup_symbol_x>, _dl_check_caller = 0x134f0 <_dl_check_caller>, _dl_open = 0x13ad0 <_dl_open>, _dl_close = 0x15e40 <_dl_close>, _dl_tls_get_addr_soft = 0x13180 <_dl_tls_get_addr_soft>, _dl_audit = 0x0, _dl_naudit = 0}
        _dl_argc = 5
#374457 0x00000005 in ?? ()
No symbol table info available.
#374458 0x0102d000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Re: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Wed, 2016-11-02 at 16:51 +0100, Svante Signell wrote:
> On Wed, 2016-11-02 at 17:39 +0200, Eli Zaretskii wrote:
> > > 
> > > From: Svante Signell <svante.signell@gmail.com>
> > > Date: Wed, 02 Nov 2016 15:16:54 +0100
> > > 
> > > First time I compiled emacs 25.1 from upstream it passed, second time not.
> > > Compiling Debian versions almost always fail. Moslty the build fails with
> > > temacs
> > > failing to execute: Killed. In my opionion it's a real loss not to gave a
> > > modern
> > > version of emacs25 available for use in GNU/Hurd (not everybody use vi).
> > > 
> > > Do anybody of you have an idea on how to solve this problem?
> > My suggestion is to run the failing temacs command line under GDB and
> > see where it crashes.
> 
> Hi, attached is a traceback from gdb. Edited to remove thousands of loops, as
> indicated in that file.

<follow ups to the bug #24857 showed an inability to allocate memory>

> > The best way to communicate this information is to file a bug report,
> > using "M-x report-emacs-bug RET" (in some version of Emacs you have
> > that is operable; if not, just email the details to
> > bug-gnu-emacs@gnu.org).
> 
> A bug was already filed by
> Paul Eggert, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24857

Hi, again. Irrespective of the discussion ongoing of a C or Lisp implementation
of dump, I'd like to try the patch supplied by Daniel Colascione. Does it still
apply without problems to the main repo git://git.sv.gnu.org/emacs.git?

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Paul Eggert]

On 12/02/2016 02:35 AM, Svante Signell wrote:
> Irrespective of the discussion ongoing of a C or Lisp implementation
> of dump, I'd like to try the patch supplied by Daniel Colascione. Does it still
> apply without problems to the main repo git://git.sv.gnu.org/emacs.git?

I doubt it. However, Daniel indicated here:

http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00081.html

that he would create a branch for that patch this weekend, and I suggest 
trying that branch. As a Savannah upgrade is in progress, you may have 
to wait before it's available; see:

http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00095.html

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Fri, 2016-12-02 at 16:02 -0800, Paul Eggert wrote:
> On 12/02/2016 02:35 AM, Svante Signell wrote:
> > Irrespective of the discussion ongoing of a C or Lisp implementation
> > of dump, I'd like to try the patch supplied by Daniel Colascione. Does it
> > still
> > apply without problems to the main repo git://git.sv.gnu.org/emacs.git?
> 
> I doubt it. However, Daniel indicated here:
> 
> http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00081.html
> 
> that he would create a branch for that patch this weekend, and I suggest 
> trying that branch. As a Savannah upgrade is in progress, you may have 
> to wait before it's available; see:
> 
> http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00095.html

Daniel,

What is the status of your branch containing the portable dumper? Nothing so far
in http://git.savannah.gnu.org/cgit/emacs.git
Emacs still FTBFS miserably on GNU/Hurd, both old (previously building) versions
as new ones. The latest successful build was for Debian version 2.24+1-5, in Nov
28 2015, more than a year ago :(

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Daniel Colascione]

On 12/07/2016 02:40 PM, Svante Signell wrote:
> On Fri, 2016-12-02 at 16:02 -0800, Paul Eggert wrote:
>> On 12/02/2016 02:35 AM, Svante Signell wrote:
>>> Irrespective of the discussion ongoing of a C or Lisp implementation
>>> of dump, I'd like to try the patch supplied by Daniel Colascione. Does it
>>> still
>>> apply without problems to the main repo git://git.sv.gnu.org/emacs.git?
>>
>> I doubt it. However, Daniel indicated here:
>>
>> http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00081.html
>>
>> that he would create a branch for that patch this weekend, and I suggest
>> trying that branch. As a Savannah upgrade is in progress, you may have
>> to wait before it's available; see:
>>
>> http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00095.html
>
> Daniel,
>
> What is the status of your branch containing the portable dumper? Nothing so far
> in http://git.savannah.gnu.org/cgit/emacs.git
> Emacs still FTBFS miserably on GNU/Hurd, both old (previously building) versions
> as new ones. The latest successful build was for Debian version 2.24+1-5, in Nov
> 28 2015, more than a year ago :(
>

Sorry for the delay --- I've been a bit held up in some personal 
business. I recently fixed some bugs in the unexec-mode-in-pdumper-build 
case, and I want to get end-to-end installation (loading the dump after 
'make install') working before I push the branch. Shouldn't be too long.