Han Boetes <h...@boetes.org> writes: > Hi,
Hi (again), > I noticed emacs failed to build after switching to 5.3. I > discussed the matter with the emacs devs and they added some debug > code which is triggered by CFLAGS='-g3 -DUNEXELF_DEBUG' So when > it's building the main binary at "Dumping under the name emacs" I > get this output: Does that mean that *only* building with -DUNEXELF_DEBUG fails? If so, the problem is perhaps not that important... > old_bss_index 25 > old_bss_addr 0x63fca0 > old_bss_size 0x73fd8 > old_bss_offset 0x53fca0 > new_bss_addr 0x4d313aa9000 > new_data2_addr 0x63fca0 > new_data2_size 0x13469360 > new_data2_offset 0x53fca0 > new_data2_incr 0x13469360 > old_file_h->e_shoff 0x9a4258 > Old section count 38 > new_file_h->e_shoff 0x13e0d5b8 > New section count 39 > Segmentation fault > gmake[1]: *** [bootstrap-emacs] Error 1 > > > After which I got this comment back by email from the developer: >> > new_bss_addr 0x4d313aa9000 >> >> That looks like the problem: OpenBSD's sbrk(0) is returning a >> huge value. src/unexelf.c isn't set up for that. >> >> Fixing this will require someone who knows ELF and OpenBSD >> fairly well, which alas is not me. > > He is refering to this file: > > http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/src/unexelf.c > > What needs to be done to fix this problem? I don't have a 64 bits host to repeat it. Please make it clear that the very last version of this file doesn't solve the issue. (Commit message: unexelf.c: Don't assume ElfW (Half) fits in int.) > # Han -- Jérémie Courrèges-Anglas PGP Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
