Re: Bug#868868: emacs25: Please include patch to fix FTBFS on m68k
Hi!
It looks like this or a similar bug has returned with emacs26:
Old build log for emacs25 with this bug:
> https://buildd.debian.org/status/fetch.php?pkg=emacs25&arch=m68k&ver=25.2%2B1-2&stamp=1500286070&raw=0
/usr/bin/make -C ../lisp update-subdirs
make[4]: Entering directory '/<<BUILDDIR>>/emacs25-25.2+1/debian/build-x/lisp'
make[4]: Leaving directory '/<<BUILDDIR>>/emacs25-25.2+1/debian/build-x/lisp'
./temacs --batch --load loadup bootstrap
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Makefile:736: recipe for target 'bootstrap-emacs' failed
make[3]: *** [bootstrap-emacs] Segmentation fault
make[3]: Leaving directory '/<<BUILDDIR>>/emacs25-25.2+1/debian/build-x/src'
Makefile:400: recipe for target 'src' failed
make[2]: *** [src] Error 2
make[2]: Leaving directory '/<<BUILDDIR>>/emacs25-25.2+1/debian/build-x'
debian/rules:365: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory '/<<BUILDDIR>>/emacs25-25.2+1'
debian/rules:224: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
Latest build log for emacs26:
> https://buildd.debian.org/status/fetch.php?pkg=emacs&arch=m68k&ver=1%3A26.1%2B1-3.2&stamp=1549253883&raw=0
/usr/bin/make -C ../lisp update-subdirs
make[4]: Entering directory '/<<BUILDDIR>>/emacs-26.1+1/debian/build-gtk/lisp'
make[4]: Leaving directory '/<<BUILDDIR>>/emacs-26.1+1/debian/build-gtk/lisp'
./temacs --batch --load loadup bootstrap
Loading loadup.el (source)...
Using load-path (/<<BUILDDIR>>/emacs-26.1+1/debian/build-src/lisp /<<BUILDDIR>>/emacs-26.1+1/debian/build-src/lisp/emacs-lisp /<<BUILDDIR>>/emacs-26.1+1/debian/build-src/lisp/progmodes /<<BUILDDIR>>/emacs-26.1+1/debian/build-src/lisp/language /<<BUILDDIR>>/emacs-26.1+1/debian/build-src/lisp/international /<<BUILDDIR>>/emacs-26.1+1/debian/build-src/lisp/textmodes /<<BUILDDIR>>/emacs-26.1+1/debian/build-src/lisp/vc)
Loading emacs-lisp/byte-run (source)...
Loading emacs-lisp/backquote (source)...
Loading subr (source)...
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
make[3]: *** [Makefile:738: bootstrap-emacs] Segmentation fault
make[3]: Leaving directory '/<<BUILDDIR>>/emacs-26.1+1/debian/build-gtk/src'
make[2]: *** [Makefile:420: src] Error 2
make[2]: Leaving directory '/<<BUILDDIR>>/emacs-26.1+1/debian/build-gtk'
make[1]: *** [debian/rules:334: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<<BUILDDIR>>/emacs-26.1+1'
make: *** [debian/rules:204: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2
Looking at Andreas's fix from back then:
> https://emba.gnu.org/emacs/emacs/commit/7a4d9f6304cffa39642507609605bcbfa40d4675
The parts of the source have changed and might need another fix:
> https://sources.debian.org/src/emacs/1:26.1+1-3.2/lib-src/make-docfile.c/#L661
> https://sources.debian.org/src/emacs/1:26.1+1-3.2/src/alloc.c/#L7012
> https://sources.debian.org/src/emacs/1:26.1+1-3.2/src/lisp.h/#L844
Andreas, could you have another look whether this is again an alignment issue?
Thanks,
Adrian
On 7/25/17 12:31 AM, Michael Karcher wrote:
>> On Jul 19 2017, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
>> wrote:
>>
>>> "sizeof(struct Lisp_Symbol) is 22 bytes on m68k, but the code expects
>>> the
>>> size of the object to be dividable by 8."
>>
>> No, it doesn't. See union aligned_Lisp_Symbol.
>
> Yes, it does, although this most likely is a bug.
>
> While aligned_Lisp_Symbol is used in alloc.c, which is used for dynamic
> allocations, and most likely works OK, it is not used for the array of
> static symbols, lispsym. The declaration in globals.h (a generated file)
> looks like this:
>
> struct Lisp_Symbol alignas (GCALIGNMENT) lispsym[1101];
>
> This does not generate an array of aligned elements, but an aligned array
> of non-aligned elements. This is in line with the documented use case of
> alignas to create aligned vectors of floats like "alignas(16) float
> vector[4];" in which only the whole array gets aligned.
>
> The issue can most likely be fixed by using the union (which currently is
> only defined inside alloc.c) in globals.h. This means copying that
> definition or putting that definition into a shared header file. globals.h
> is generated by lib-src/make-docfile.c
>
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: