On 09/23/2015 11:34 AM, Eli Zaretskii wrote: >> From: Petr Hracek >> Date: Wed, 23 Sep 2015 10:06:50 +0200 >> >> Is there any possibility how to suppress dumping emacs? >> Shall I add something to ./configure script or even to make? > You could try adding -DCANNOT_DUMP=1 to preprocessor command-line > switches. But it would be much better if you try figuring out why it > segfaults, then we might be able to come up with a solution that > preserves the dumping capability. Well, I will try to summarize it. And sorry for my english. I would like to build emacs also under ppc64le architecture for RHEL-7 system All other architecture seems to be working well. I have add a patch to our emacs downstream package which comments row http://git.savannah.gnu.org/cgit/emacs.git/tree/src/unexelf.c?h=emacs-24#n869 so that I did not see message like: Dumping under the name emacs emacs: Program segment above .bss in /builddir/build/BUILD/emacs-24.3/build-gtk/src/temacs make[2]: *** [bootstrap-emacs] Error 1 Patch looks like: |diff --git a/src/unexelf.c b/src/unexelf.c index d365940..69b0237 100644 --- a/src/unexelf.c +++ b/src/unexelf.c @@ -853,11 +853,15 @@ unexec (const char *new_name, const char *old_name) when the executable doesn't have an sbss section. */ if (old_sbss_index != -1) #endif /* __sgi */ - if (NEW_PROGRAM_H (n).p_vaddr + NEW_PROGRAM_H (n).p_filesz + // This was commented out because we are not able to build it + // under PPC64LE. + /*if (NEW_PROGRAM_H (n).p_vaddr + NEW_PROGRAM_H (n).p_filesz > (old_sbss_index == -1 ? old_bss_addr : round_up (old_bss_addr, alignment))) fatal ("Program segment above .bss in %s\n", old_name, 0); + */ + if (NEW_PROGRAM_H (n).p_type == PT_LOAD && (round_up ((NEW_PROGRAM_H (n)).p_vaddr @@ -866,8 +870,8 @@ unexec (const char *new_name, const char *old_name) == round_up (old_bss_addr, alignment))) break; } - if (n < 0) - fatal ("Couldn't find segment next to .bss in %s\n", old_name, 0); + //if (n < 0) + //fatal ("Couldn't find segment next to .bss in %s\n", old_name, 0); /* Make sure that the size includes any padding before the old .bss section. */| And I KNOW that this is TOTALLY wrong and weird workaround, though. 1) binutils-2.23.52.0.1-30.ael7b.ppc64le all works fine and emacs is packaged on ppc64le architecture gcc-4.8.3-9.el7.ppc64le glibc-2.17-102.el7.ppc64le 2) binutils-2.23.52.0.1-44.el7.ppc64le with "weird" patch I am able to packaged emacs on ppc64le architecture gcc-4.8.3-9.el7.ppc64le glibc-2.17-85.ael7b.ppc64le Nowadays with binutils-2.23.52.0.1-54 I am not able to build emacs at all. What I can do is to add several tracking information like traces which can be added to source code during the build. Any advice would be welcome and I will do it really soon. Question from my side, how to add traces so that I am able to see data? I have seen that there were several patches done by Paul Eggert like: http://git.savannah.gnu.org/cgit/emacs.git/commit/src/unexelf.c?h=emacs-24&id=f269bc61c10320cf020e0751e6643fbbb5f059a2 http://git.savannah.gnu.org/cgit/emacs.git/commit/src/unexelf.c?h=emacs-24&id=5ee94506f6ee4f5142bfeabc9409f95e370d38e3 But I don't think that there are relevant. Unfortunately I don't have a deep knowledge about ELF and .data or .bss segments which are mentioned in file unexelf.c My colleagues told me if there is any possibility to remove unexelf.c file and replace them with "mapping a file with pre-compiled byte code." But I don't understand it at all. Sorry folks. I would like to send a patch to upstream for solving it but I don't have an idea how. -- Petr Hracek Software Engineer Developer Experience Red Hat, Inc Mob: +420777056169 email: phracek@redhat.com