^ gmalloc.c: At top level: gmalloc.c:1203:16: error: conflicting types for 'sbrk' #define __sbrk sbrk ^ gmalloc.c:1210:16: note: in expansion of macro '__sbrk' ----------------------------------------------------------------- This is an unstable amd64 chroot image (named gnome-systemd-unstable_20170203-101641) at a hardened host acting as a tinderbox. ----------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-5.4.0 * llvm-config --version: 3.9.1 Available Java Virtual Machines: [1] icedtea-bin-7 [2] icedtea-bin-8 system-vm [3] jamvm Available Python interpreters, in order of preference: [1] python3.4 [2] python2.7 (fallback) [3] pypy3 (fallback) Available Ruby profiles: [1] ruby21 (with Rubygems) * java-config: The following VMs are available for generation-2: 1) IcedTea JDK 7.2.6.8 [icedtea-bin-7] *) IcedTea JDK 3.3.0 [icedtea-bin-8] 3) JamVM JDK 2.0.0 [jamvm]
Created attachment 463440 [details] emerge-info.txt
Created attachment 463442 [details] app-editors:xemacs-21.5.34-r4:20170212-135933.log
Created attachment 463444 [details] config.log
Created attachment 463446 [details] emerge-history.txt
Created attachment 463448 [details] environment
Created attachment 463450 [details] etc.portage.tbz2
If I read the logs correctly this is a build with glibc 2.25. In that version malloc_get_state and malloc_set_state functions have been removed which seems to convince configure to use the malloc supplied with xemacs which I fear might not have seen the day of light in a few years. I suspect simply using the system malloc could be a simple and better choice. I'll investigate.
(In reply to Mats Lidell from comment #7) >If I read the logs correctly this is a build with glibc 2.25. Yes, I keyworded it at the tinderbox for unstable images
xemacs-21.5.34-r4.ebuild is updated to use the system malloc. That should fix this issue and is probably generally good anyway. Please try it.
same at the tinderbox image plasma-systemd-abi32+64_20170325-221422
Created attachment 468830 [details] emerge-info.txt
Created attachment 468832 [details] app-editors:xemacs-21.5.34-r4:20170401-015017.log
Created attachment 468834 [details] config.log.tbz2
Created attachment 468836 [details] emerge-history.txt
Created attachment 468838 [details] environment
Created attachment 468840 [details] etc.portage.tbz2
Created attachment 468842 [details] temp.tbz2
(In reply to Toralf Förster from comment #10) > same at the tinderbox image plasma-systemd-abi32+64_20170325-221422 The crash now is not the same as before. It is now a segmentation error in a later stage.
Running into this myself with xemacs-21.5.34-r5.
FWIW I set up emacs overlay, and received 21.5.34-r5 in the first place, because I was also running into a segfault at a later stage ("dump ELC stage 2" or so) with 21.5.34-r1 in stock portage.
Huh, is layman/emacs/app-editors/xemacs outdated by portage/app-editors/xemacs?
(In reply to Mats Lidell from comment #18) > (In reply to Toralf Förster from comment #10) > > same at the tinderbox image plasma-systemd-abi32+64_20170325-221422 > > The crash now is not the same as before. It is now a segmentation error in a > later stage. This must be duplicate of https://bugs.gentoo.org/639642 which is solved. I now realize that this might be what your bug report has been about all the time but I read it more like a request to have a build respecting PIE? We already have that request in ticket: https://bugs.gentoo.org/75028. The title might not be clear but is about xemacs builds working with PIE. Can we consider this ticket either as solved or as duplicate of https://bugs.gentoo.org/75028?
(In reply to vsync from comment #21) > Huh, is layman/emacs/app-editors/xemacs outdated by > portage/app-editors/xemacs? I haven't updated xemacs in the emacs overlay for a long period mostly because upstream development has been very slow or non existing so there has not been anything to experiment with. In addition to that, 21.5, which is what upstream is working on, is in testing in gentoo so updates there are more relaxed. I don't know if this is considered a problem. Overlays are experimental. If upstream will be more active the overlay might prove useful again.
(In reply to Mats Lidell from comment #22) > (In reply to Mats Lidell from comment #18) > > (In reply to Toralf Förster from comment #10) > > > same at the tinderbox image plasma-systemd-abi32+64_20170325-221422 > > > > The crash now is not the same as before. It is now a segmentation error in a > > later stage. > > This must be duplicate of https://bugs.gentoo.org/639642 which is solved. > > I now realize that this might be what your bug report has been about all the > time but I read it more like a request to have a build respecting PIE? We > already have that request in ticket: https://bugs.gentoo.org/75028. The > title might not be clear but is about xemacs builds working with PIE. Can we > consider this ticket either as solved or as duplicate of > https://bugs.gentoo.org/75028? After giving this some time I take the freedom to consider this as solved. Feel free to reopen if I have misunderstood the issue.
