11:08 p.m.
Hi,
I have received this bug report, https://bugs.gentoo.org/661592, which is about a
segmentation violation during the build process of xemacs 21.5.34. I managed to recreate
the problem once(!) on one of my machines but after that I have not been able to get it
again, sigh, although I have tried it a like 20 times or more.
I can't see that we have had this issue on the build bot either which uses the same
machine I got the error on and does a lot of builds!?
Aidan: Have you seen anything like this? (With a hope that some recent development you
have done has touched and fixed things that could cause segmentation violations in this
old code base!?)
Yours
--
%% Mats
6:29 a.m.
Ar an tríú lá is fiche de mí Iúil, scríobh Mats Lidell:
Hi,
I have received this bug report, https://bugs.gentoo.org/661592, which is about a
segmentation violation during the build process of xemacs 21.5.34. I managed to recreate
the problem once(!) on one of my machines but after that I have not been able to get it
again, sigh, although I have tried it a like 20 times or more.
I can't see that we have had this issue on the build bot either which uses the same
machine I got the error on and does a lot of builds!?
Aidan: Have you seen anything like this? (With a hope that some recent development you
have done has touched and fixed things that could cause segmentation violations in this
old code base!?)
No, nothing convincingly like this. The log file doesn’t show the usual
XEmacs “Fatal error” message.
That’s a *very* new GCC and those are some *very* aggressive optimisation
flags. Were your own crashes with a similar level of optimisation?
NEWGC currently does give segmentation violations on OS X, because (as far
as I can see) the Mach exception handler code is broken, and some of my
recent changes prompted configure to treat OS X as non-POSIX again.
--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after forty pints of stout’
(C. Moore)
10:17 p.m.
Aidan Kehoe writes:
No, nothing convincingly like this. The log file doesn’t show the usual
XEmacs “Fatal error” message.
That’s a *very* new GCC and those are some *very* aggressive optimisation
flags. Were your own crashes with a similar level of optimisation?
Yes. It was built on the machine used with the xemacs build bot "amd64 gentoo"
using the gentoo package build. But unfortunately(!?) I have only been able to
reproduce the crash once so far.
Interestingly the "cfg2" configuration (optimized build) used by the xemacs
build bot does actually use -03 as it picks the value provided by configure in
the "checking for preferred optimization flags.." check. So that is aggressive
but it seems to work.
In the gentoo build case "only" -O2 is used since the value that configure
wants is overridden by my default setting -O2. That is the same setting that
is used by the reporter. So the crash is for a -O2 compiled binary (The log
might look differently at a first glance but according to the gcc manual the
last optimization setting on the command line is the one that will be in
effect. So further down the command line you will find -O2 present.)
Would you consider -O2 to be aggressive?
NEWGC currently does give segmentation violations on OS X, because
(as far
as I can see) the Mach exception handler code is broken, and some of my
recent changes prompted configure to treat OS X as non-POSIX again.
OK. That would not be or solve the problem for the Gentoo build then.
Yours
--
%% Mats
11:18 p.m.
Hi Aidan,
Mats Lidell writes:
Yes. It was built on the machine used with the xemacs build bot "amd64 gentoo"
using the gentoo package build. But unfortunately(!?) I have only been able to
reproduce the crash once so far.
I have received yet another bug report due to build time crash:
https://bugs.gentoo.org/664292
Same thing with this bug that I can't reproduce it on my machine (same machine that is
used for the build bot) so it is very hard to do anything. Just wanted you to know and
with the hope it would trigger some idea what could be the source of this.
Yours
--
%% Mats
9:03 p.m.
Ar an séú lá is fiche de mí Lúnasa, scríobh Mats Lidell:
Hi Aidan,
> Mats Lidell writes:
> Yes. It was built on the machine used with the xemacs build bot "amd64
gentoo"
> using the gentoo package build. But unfortunately(!?) I have only been able to
> reproduce the crash once so far.
I have received yet another bug report due to build time crash:
https://bugs.gentoo.org/664292
Same thing with this bug that I can't reproduce it on my machine (same machine that
is used for the build bot) so it is very hard to do anything. Just wanted you to know and
with the hope it would trigger some idea what could be the source of this.
I still can’t reproduce it, with AMD 64, GCC 6 and most of the configure
flags of that ebuild.
That ebuild uses newgc and non-mule, and it is rare that I use either. There
is no prospect of my switching to non-mule, but I will switch to newgc
day-to-day for the next few weeks at least, to see if it comes up. My
previous comment about the Mach fault handler on OS X only applies to
non-x86/AMD64 architectures, as it turns out.
--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after forty pints of stout’
(C. Moore)
10:07 p.m.
Hi Aidan,
Aidan Kehoe writes:
I still can’t reproduce it, with AMD 64, GCC 6 and most of the configure
flags of that ebuild.
Yes. Same thing for me.
That ebuild uses newgc and non-mule, and it is rare that I use
either. There
is no prospect of my switching to non-mule, but I will switch to newgc
day-to-day for the next few weeks at least, to see if it comes up.
Thanks. Maybe I should consider deprecating non mule to reduce the number of available
build variations?
By the way - I have received another similar bug report. This time it is an assertion that
fails: https://bugs.gentoo.org/665106. I can't reproduce this problem either. Does the
assertion provide any hints to you what is going on?
Yours
--
%% Mats
11:33 p.m.
On Sun, 02 Sep 2018 23:07:27 +0200
Mats Lidell <mats.lidell(a)cag.se> wrote:
Thanks. Maybe I should consider deprecating non mule to reduce the
number of available build variations?
I build only non-mule builds and never have a problem.
I assume you know you have to delete all the *.elc in the XEmacs tree
for non-mule builds. They are built with mule and cause all sorts of
grief :(
My config is basically:
CFLAGS="-O2" \
./configure \
--prefix=/usr \
--without-error-checking \
--without-mule \
--with-default-eol-detection \
--with-xft \
$ARCH-slackware-linux
I also build without xft. I do apply a few patches.
If you are interested in looking at the patches, they are here:
https://github.com/smaclennan/dot-xemacs/tree/master/slackware/
The patches are in the patches directory and the main script is
make-xemacs.sh (no xft in this script).
Cheers,
Sean
8:03 a.m.
Ar an dara lá de mí Méan Fómhair, scríobh Sean MacLennan:
On Sun, 02 Sep 2018 23:07:27 +0200
Mats Lidell <mats.lidell(a)cag.se> wrote:
> Thanks. Maybe I should consider deprecating non mule to reduce the
> number of available build variations?
I build only non-mule builds and never have a problem.
No-one said you have a problem, the point is that non-Mule support adds
support work from our perspective.
It does have the upside that sometimes you can narrow down a problem better
if it happens on a Mule build but not a non-Mule build, and when debugging
performance problems it is a help to drop the O(N) byte-char conversion
code.
I assume you know you have to delete all the *.elc in the XEmacs
tree
for non-mule builds. They are built with mule and cause all sorts of
grief :(
They error on load, at least, right?
[...] If you are interested in looking at the patches, they are
here:
https://github.com/smaclennan/dot-xemacs/tree/master/slackware/
Thanks!
--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after forty pints of stout’
(C. Moore)
7:58 a.m.
Ar an dara lá de mí Méan Fómhair, scríobh Mats Lidell:
> Aidan Kehoe writes:
> I still can’t reproduce it, with AMD 64, GCC 6 and most of the configure
> flags of that ebuild.
Yes. Same thing for me.
> That ebuild uses newgc and non-mule, and it is rare that I use either.
> There is no prospect of my switching to non-mule, but I will switch to
> newgc day-to-day for the next few weeks at least, to see if it comes
> up.
Thanks. Maybe I should consider deprecating non mule to reduce the number of available
build variations?
By the way - I have received another similar bug report. This time it is an assertion
that fails: https://bugs.gentoo.org/665106. I can't reproduce this problem either.
Does the assertion provide any hints to you what is going on?
Yes, as do a few crashes in day-to-day use.
My initial crashes were in part because I set
gc-incremental-traversal-treshold to 10000, under the misunderstanding that
it did what gc-cons-incremental-threshold does. Its default value is 400000,
and with the lower value the kkcc_gc_stack grew uncontrollably large,
realloc fails, and XEmacs crashed. (And then crashed again while crashing,
because memory_full() calls GC recursively.)
But; that shouldn’t have happened. The object that was being traversed as
the realloc failed was a struct display_line that, as far as I can see, was
garbage, all its values were inconsistent. Your documented crash also seems
likely to be from traversal of a garbage object.
I wonder is it just as simple as the redisplay structures being
inconsistently marked as GC roots through the kkcc descriptions? That might
fit with my never seeing the crash on this TTY-only NEWGC build. Though it
should provoke the same crashes on a KKCC non-NEWGC build, which we don’t
see.
--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after forty pints of stout’
(C. Moore)
9:49 a.m.
Aidan Kehoe writes:
I wonder is it just as simple as the redisplay structures being
inconsistently marked as GC roots through the kkcc descriptions? That might
fit with my never seeing the crash on this TTY-only NEWGC build. Though it
should provoke the same crashes on a KKCC non-NEWGC build, which we don’t
see.
Are you looking at this problem? From your description it sound like an easy
thing to test but that is just me counting the number of lines describing the
issue! (One line describing the problem = easy thing to fix!) Or is there not
an inconsistency that should be viewed as bug?
I mean that the reason we don't see the crashes might be that it is hard to
get this error in the first place. I can't recreate it on the machines that I
have available so it is tricky to get and of course even trickier to know if
it is solved.
Maybe, if I could get a patch with this fix I could get the reported, who gets
the error, to test this!?
Yours
--
%% Mats
10:36 a.m.
Ar an cúigiú lá déag de mí Méan Fómhair, scríobh Mats Lidell:
> Aidan Kehoe writes:
> I wonder is it just as simple as the redisplay structures being
> inconsistently marked as GC roots through the kkcc descriptions? That might
> fit with my never seeing the crash on this TTY-only NEWGC build. Though it
> should provoke the same crashes on a KKCC non-NEWGC build, which we don’t
> see.
Are you looking at this problem? From your description it sound like an easy
thing to test but that is just me counting the number of lines describing the
issue! (One line describing the problem = easy thing to fix!) Or is there not
an inconsistency that should be viewed as bug?
I mean that the reason we don't see the crashes might be that it is hard to
get this error in the first place. I can't recreate it on the machines that I
have available so it is tricky to get and of course even trickier to know if
it is solved.
Maybe, if I could get a patch with this fix I could get the reported, who gets
the error, to test this!?
I have been looking at the problem. I have a reasonable working hypothesis
for it, which is that cmotion_display_lines in redisplay.c should be marked
for garbage collection but isn’t, and that with NEWGC the shorter intervals
between GC mark activity make the garbage more likely to be encountered.
I have the bulk of a patch written, but there are six relevant combinations
of configure options it has to work with (NEWGC + KKCC + PDUMP, oldgc + KKCC
+ PDUMP, oldgc + KKCC + olddump, oldgc + oldmark + PDUMP, oldgc + oldmark +
olddump, NEWGC + KKCC + olddump) and so I haven’t yet got it to the point
where I can commit it.
I also have an exam at the end of the month so have been studying for that!
--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after forty pints of stout’
(C. Moore)
7:54 p.m.
Hi Aidan,
Aidan Kehoe writes:
I have been looking at the problem. I have a reasonable working hypothesis
for it, [...]
Have you had a chance to look more on the hypothesis whether it could be it?
I have received two more bug reports about segmentation violations:
- https://bugs.gentoo.org/671848 and
- https://bugs.gentoo.org/672240
The later is even during byte compiling an elisp package. So it is not even when building
XEmacs!?
I have not been able to recreate these errors on my machine.
Yours
--
%% Mats
noon
Ar an triochadú lá de mí na Samhain, scríobh Mats Lidell:
Hi Aidan,
> Aidan Kehoe writes:
> I have been looking at the problem. I have a reasonable working hypothesis
> for it, [...]
Have you had a chance to look more on the hypothesis whether it could be it?
I have.
Working on the GC code is hard; there are four separate relevant
compile-time options (--with-kkcc, --without-kkcc, --with-newgc and
--without-newgc) which is really three more than is appropriate with our
level of development manpower (especially since the GC code is all internal
to XEmacs, there’s no need to interact with external libraries!).
I’m still reasonably happy about my hypothesis and will try to make more
progress on it soon.
I have received two more bug reports about segmentation violations:
- https://bugs.gentoo.org/671848 and
- https://bugs.gentoo.org/672240
The later is even during byte compiling an elisp package. So it is not even when building
XEmacs!?
I have not been able to recreate these errors on my machine.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list -- xemacs-beta(a)xemacs.org
To unsubscribe send an email to xemacs-beta-leave(a)xemacs.org
--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after forty pints of stout’
(C. Moore)
5:29 p.m.
Hi Aidan,
Aidan Kehoe writes:
Working on the GC code is hard; there are four separate relevant
compile-time options (--with-kkcc, --without-kkcc, --with-newgc and
--without-newgc) which is really three more than is appropriate with our
level of development manpower (especially since the GC code is all internal
to XEmacs, there’s no need to interact with external libraries!).
My suggestion, maybe naive, is to choose one configuration (--with-kkcc and --with-newgc
maybe!?) that you support so that you can focus on that to limit the amount of work
necessary. It is better to have one working GC than four almost working!
I’m still reasonably happy about my hypothesis and will try to make
more
progress on it soon.
That sounds great.
If that would turn out to be a success I would in order to be able to use it, either need
a new official release of 21.5 or a patch against the latest official release (21.5.34).
Yours
--
%% Mats
2:24 p.m.
Sorry for hijacking the thread, but this sounds similar enough...
On Arch, building 21.5.34 gives me
[...]
Loading
/var/obj/pkgsrc/editors/xemacs-current/work/xemacs-21.5.34/lisp/paragraphs.elc...
Loading
/var/obj/pkgsrc/editors/xemacs-current/work/xemacs-21.5.34/lisp/loaddefs.elc...
Loading site-load...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name xemacs
./xemacs -no-packages -batch -no-autoloads -l update-elc-2.el -f
batch-update-elc-2
/var/obj/pkgsrc/editors/xemacs-current/work/xemacs-21.5.34/src/../lisp
*** Signal 11
Stop.
bmake[1]: stopped in
/var/obj/pkgsrc/editors/xemacs-current/work/xemacs-21.5.34/src
*** Error code 1
with
(gdb) run -no-packages -batch -no-autoloads -l update-elc-2.el -f
batch-update-elc-2
/var/obj/pkgsrc/editors/xemacs-current/work/xemacs-21.5.34/src/../lisp
Starting program:
/var/obj/pkgsrc/editors/xemacs-current/work/xemacs-21.5.34/src/xemacs
-no-packages -batch -no-autoloads -l update-elc-2.el -f
batch-update-elc-2
/var/obj/pkgsrc/editors/xemacs-current/work/xemacs-21.5.34/src/../lisp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x000055555567bdde in pdump_reloc_one_mc (data=0x7ffff468b000,
desc=desc＠entry=0x55619d5776c0) at dumper.c:1293
1293 for (pos = 0; desc[pos].type != XD_END; pos++)
(gdb) bt
#0 0x000055555567bdde in pdump_reloc_one_mc (data=0x7ffff468b000,
desc=desc＠entry=0x55619d5776c0) at dumper.c:1293
#1 0x000055555567c52d in pdump_load_finish () at dumper.c:2319
#2 0x0000555555680c7e in pdump_load (argv0=<optimized out>) at
dumper.c:2761
#3 0x000055555564c5dc in xemacs_21_5_b34_x86_64_unknown_linux (argc=9,
argv=0x7fffffffe628, unused_envp=<optimized out>, restart=0) at emacs.c:1407
#4 0x00005555555b37b4 in main (argc=<optimized out>,
argv=0x7fffffffe628, unused_envp=<optimized out>) at emacs.c:3190
(gdb) print pos
$1 = 0
(gdb) print desc[0]
Cannot access memory at address 0x55619d5776c0
(gdb)
Compiler is
% gcc --version | head -1
gcc (GCC) 8.2.1 20181127
%
I tried building with and without kkcc and newgc, without any difference.
Building directly from the sources fails early in configure - looks like
gcc8 defaults to -Werror!?
Cheerio,
hauke
--
The ASCII Ribbon Campaign Hauke Fath
() No HTML/RTF in email Institut für Nachrichtentechnik
/\ No Word docs in email TU Darmstadt
Respect for open standards Ruf +49-6151-16-21344
8:47 p.m.
Ar an naoú lá déag de mí na Nollaig, scríobh Hauke Fath:
[...] I tried building with and without kkcc and newgc, without any
difference.
Building directly from the sources fails early in configure - looks like
gcc8 defaults to -Werror!?
Joder, as the Spanish put it.
Was this the tip, or the last release? The tip definitely has configure
support and work-arounds for address space layout randomisation, which will
give the sort of error you’re posting. If I remember correctly the last
release does not include this support. Good argument for a new release!
--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after forty pints of stout’
(C. Moore)
10:50 p.m.
Hi Aidan,
Aidan Kehoe writes:
Was this the tip, or the last release? The tip definitely has configure
support and work-arounds for address space layout randomisation, which will
give the sort of error you’re posting. If I remember correctly the last
release does not include this support. Good argument for a new release!
Does this mean that you suspect that this is could be the same problems I'm seeing
with 21.5 and that that already is fixed in the tip version?
Yours
--
%% Mats
7:42 p.m.
Hi Aidan,
Some more data maybe!? While working on moving the smoketest over to a Gentoo server I
stumbled on these core dumps for the 21.5 build.
Configured like this: ./configure --with-debug --with-error-checking=all -with-assertions
--with-mule --with-newgc --with-system-malloc
From the src folder running make again (after it core dumps the first time)
----------------------------------------------------------------------
$ LANG=C make
./xemacs -nd -no-packages -batch -l
/home/matsl/work/smoketest/xemacs-21.5/src/../lisp/update-elc.el
Loading /home/matsl/work/smoketest/xemacs-21.5/src/../lisp/update-elc.el...
Loading find-paths.el...
Loading packages.el...
Loading setup-paths.el...
Loading /home/matsl/work/smoketest/xemacs-21.5/lisp/dumped-lisp.el...
Wrote /home/matsl/work/smoketest/xemacs-21.5/src/REBUILD_AUTOLOADS
./xemacs -no-packages -batch -no-autoloads -l update-elc-2.el -f batch-update-elc-2
/home/matsl/work/smoketest/xemacs-21.5/src/../lisp
make: *** [GNUmakefile:142: update-elc-2] Segmentation fault (core dumped)
----------------------------------------------------------------------
Visiting the core:
----------------------------------------------------------------------
...
Core was generated by `./xemacs -no-packages -batch -no-autoloads -l update-elc-2.el -f
batch-update-e'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055b548b4edce in pdump_reloc_one_mc (data=0x7fdd383d6000, desc=0x5604f3c60560) at
dumper.c:1293
1293 for (pos = 0; desc[pos].type != XD_END; pos++)
warning: File "/home/matsl/work/smoketest/xemacs-21.5/src/.gdbinit" auto-loading
has been declined by your `auto-load safe-path' set to
"$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /home/matsl/work/smoketest/xemacs-21.5/src/.gdbinit
line to your configuration file "/home/matsl/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/matsl/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
(gdb) bt
#0 0x000055b548b4edce in pdump_reloc_one_mc (data=0x7fdd383d6000, desc=0x5604f3c60560) at
dumper.c:1293
#1 0x000055b548b5118e in pdump_load_finish () at dumper.c:2319
#2 0x000055b548b51a87 in pdump_load (argv0=0x7fffb225c1cc "./xemacs") at
dumper.c:2761
#3 0x000055b548b0eeda in xemacs_21_5_b34_x86_64_unknown_linux (argc=9,
argv=0x7fffb225a508, unused_envp=0x0, restart=0)
at emacs.c:1407
#4 0x000055b548b102b6 in main (argc=9, argv=0x7fffb225a508, unused_envp=0x7fffb225a558)
at emacs.c:3190
(gdb)
----------------------------------------------------------------------
Can you make anything out of this? Anything else that I can produce that would be
helpful?
This has turned into a blocker for building "21.5-b34" in order to use it for
the package smoketest.
Yours
--
%% Mats
10:31 a.m.
Ar an t-ochtú lá is fiche de mí na Nollaig, scríobh Mats Lidell:
[...]
./xemacs -no-packages -batch -no-autoloads -l update-elc-2.el -f batch-update-elc-2
/home/matsl/work/smoketest/xemacs-21.5/src/../lisp
make: *** [GNUmakefile:142: update-elc-2] Segmentation fault (core dumped)
----------------------------------------------------------------------
Visiting the core:
----------------------------------------------------------------------
...
Core was generated by `./xemacs -no-packages -batch -no-autoloads -l update-elc-2.el -f
batch-update-e'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055b548b4edce in pdump_reloc_one_mc (data=0x7fdd383d6000, desc=0x5604f3c60560)
at dumper.c:1293
1293 for (pos = 0; desc[pos].type != XD_END; pos++)
[...]
Can you make anything out of this? Anything else that I can produce
that would be helpful?
This has turned into a blocker for building "21.5-b34" in order to use it for
the package smoketest.
Is that the beta tarball? If so, this is just address space layout
randomization interacting with pdump; see the changes from November 2017,
a3aa49cd5d75 , 0ea0f070cae2 , and 00726cf74255 .
--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after forty pints of stout’
(C. Moore)
3:47 p.m.
Hi Aidan,
Aidan Kehoe writes:
Is that the beta tarball? If so, this is just address space layout
randomization interacting with pdump; see the changes from November 2017,
a3aa49cd5d75 , 0ea0f070cae2 , and 00726cf74255 .
Yes or no!? It is from the repo "hg update r21-5-34". I thought that was the
latest 21.5 release. No?
In order to build it I have patched it with the gentoo patches:
https://gitweb.gentoo.org/repo/gentoo.git/tree/app-editors/xemacs/files
(I suppose the old debian machine that the smoketests runs on now does not trigger the
same build errors as my Gentoo box does. I also have not tried to rebuild the latest
official release on that machine since nearly a year which could have some impact as
well.)
However... so if I would combine the commits a3aa49cd5d75 , 0ea0f070cae2 , and
00726cf74255 I could patch r21-5-34 to get rid of this problem?
Yours
--
%% Mats
4:13 p.m.
Hi Aidan,
Mats Lidell writes:
However... so if I would combine the commits a3aa49cd5d75 , 0ea0f070cae2 , and
00726cf74255 I could patch r21-5-34 to get rid of this problem?
Ah. Now I remember! It is the no-pie stuff that I have fixed on Gentoo by letting the
ebuild set that up. Letting configure deal with it is of course better but the commits
listed above does not cleanly apply on r21-5-34. I suppose trivial to fix but still has to
be done.
Yet another argument for a new release of 21.5?
I could of course skip supporting 21.5.34, ie the latest official release of 21.5, for the
smoketest and only go for the tip version? 21.5.34 needs to be patched anyway so it would
be to some extent lying to say that it was used for building the packages?
Good enough for now? When a new 21.5 official release sees the light I can start
supporting both the latest release and the tip version again?
Yours
--
%% Mats
7:18 a.m.
On Wed, 19 Dec 2018 20:47:57 +0000, Aidan Kehoe wrote:
as this the tip, or the last release?
The latest release tarball.
The tip definitely has configure
support and work-arounds for address space layout randomisation, which will
give the sort of error you’re posting.
Ahh... maybe the package can disable this. Something to look into,
finally...
Cheerio,
hauke
--
The ASCII Ribbon Campaign Hauke Fath
() No HTML/RTF in email Institut für Nachrichtentechnik
/\ No Word docs in email TU Darmstadt
Respect for open standards Ruf +49-6151-16-21344
9:52 p.m.
On Wed, 19 Dec 2018 20:47:57 +0000, Aidan Kehoe wrote:
Was this the tip, or the last release? The tip definitely has
configure
support and work-arounds for address space layout randomisation, which will
give the sort of error you’re posting. If I remember correctly the last
release does not include this support. Good argument for a new release!
I finally got back to looking at this (instead of holding back an
xemacs rebuild on pkgsrc arch, then experimenting with pkgsrc gcc7 to
replace Arch's gcc8), and it turned out that a mere "CFLAGS+= -no-pie"
in the package Makefile gets both xemacs214 and 215 releases back on
track with gcc8.
Cheerio, and happy easter eggs,
hauke
--
The ASCII Ribbon Campaign Hauke Fath
() No HTML/RTF in email Institut für Nachrichtentechnik
/\ No Word docs in email TU Darmstadt
Respect for open standards Ruf +49-6151-16-21344
2075
days inactive
2345
days old
22 comments
5 participants
participants (5)
-
Aidan Kehoe -
Hauke Fath -
Mats Lidell -
Mats Lidell
-
Sean MacLennan