Re: Guile language support in make
On Mon, 12 May 2014, Manoj Srivastava wrote: > make remains lean; make-guile is identical exept for the added > guile support. Thanks for making it this way. Can you please exclude make-guile and the guile-2.0 Build-Depends on m68k because guile does not work there (and nobody appears capable enough to debug it)? Thanks, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"... -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.10.1405121314530.25...@tglase.lan.tarent.de
Re: Guile language support in make
Thorsten Glaser writes:
> and the guile-2.0 Build-Depends on m68k because guile does not
> work there (and nobody appears capable enough to debug it)?
Index: guile-2.0.9/libguile/gsubr.c
===
--- guile-2.0.9.orig/libguile/gsubr.c
+++ guile-2.0.9/libguile/gsubr.c
@@ -213,7 +213,7 @@
*/
static const struct
{
- scm_t_uint64 dummy; /* ensure 8-byte alignment; perhaps there's a better way
*/
+ scm_t_uint64 dummy SCM_ALIGNED (sizeof (scm_t_uint64)); /* ensure 8-byte
alignment; perhaps there's a better way */
const scm_t_uint8 bytes[121 * (sizeof (struct scm_objcode) + 16
+ sizeof (struct scm_objcode) + 32)];
} raw_bytecode = {
@@ -317,7 +317,7 @@ static const struct
static const struct
{
- scm_t_uint64 dummy; /* alignment */
+ scm_t_uint64 dummy SCM_ALIGNED (sizeof (scm_t_uint64)); /* alignment */
scm_t_cell cells[121 * 2]; /* 11*11 double cells */
} objcode_cells = {
0,
Index: guile-2.0.9/libguile/vm-engine.h
===
--- guile-2.0.9.orig/libguile/vm-engine.h
+++ guile-2.0.9/libguile/vm-engine.h
@@ -74,7 +74,7 @@
#define FP_REG asm("%r16")
#endif
#ifdef __mc68000__
-#define IP_REG asm("a5")
+#define IP_REG asm("a3")
#define SP_REG asm("a4")
#define FP_REG
#endif
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87y4y7uf4y@igel.home
Re: Guile language support in make
Andreas Schwab dixit:
>Thorsten Glaser writes:
>
>> and the guile-2.0 Build-Depends on m68k because guile does not
>> work there (and nobody appears capable enough to debug it)?
>
>Index: guile-2.0.9/libguile/gsubr.c
Thanks Andreas!
Rob: I’ll try building guile-2.0 with the attached debdiff
and report success or failure afterwards. Can you please
review it if it’s okay for inclusion, if it indeed fixes
the bug? (And of course feeding back to upstream.)
bye,
//mirabilos
--
[00:02] gecko: benutzt du emacs ?
[00:03] nö [00:03] nur n normalen mac
[00:04] argl [00:04] ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)diff -Nru guile-2.0-2.0.11+1/debian/changelog
guile-2.0-2.0.11+1/debian/changelog
--- guile-2.0-2.0.11+1/debian/changelog 2014-04-23 19:19:00.0 +0200
+++ guile-2.0-2.0.11+1/debian/changelog 2014-05-12 21:34:12.0 +0200
@@ -1,3 +1,10 @@
+guile-2.0 (2.0.11+1-1+m68k.1) unreleased; urgency=low
+
+ * Apply patch from Andreas Schwab to fix bogus alignment
+assumptions and using the wrong register. (Closes: #649718)
+
+ -- Thorsten Glaser Mon, 12 May 2014 21:33:08 +0200
+
guile-2.0 (2.0.11+1-1) unstable; urgency=low
* Incorporate upstream version 2.0.11.
diff -Nru
guile-2.0-2.0.11+1/debian/patches/9000-Fix-alignment-and-m68k-registers.patch
guile-2.0-2.0.11+1/debian/patches/9000-Fix-alignment-and-m68k-registers.patch
---
guile-2.0-2.0.11+1/debian/patches/9000-Fix-alignment-and-m68k-registers.patch
1970-01-01 01:00:00.0 +0100
+++
guile-2.0-2.0.11+1/debian/patches/9000-Fix-alignment-and-m68k-registers.patch
2014-05-12 21:32:47.0 +0200
@@ -0,0 +1,52 @@
+From sch...@linux-m68k.org Mon May 12 18:37:51 2014
+From: Andreas Schwab
+Message-ID: <87y4y7uf4y@igel.home>
+To: Thorsten Glaser
+Cc: Manoj Srivastava , debian-68k@lists.debian.org
+Date: Mon, 12 May 2014 18:37:49 +0200
+X-Original-Subject: Re: Guile language support in make
+Subject: Fix alignment and registers for m68k
+
+Fix bogus alignment assumptions (on some architectures, “natural”
+alignment is not used, which means even an uint64_t is possibly
+unaligned, or aligned to only a 2 byte (m68k) or 4 byte boundary).
+
+Also, fix register name for m68k.
+--
+
+Thorsten Glaser writes:
+
+> and the guile-2.0 Build-Depends on m68k because guile does not
+> work there (and nobody appears capable enough to debug it)?
+
+--- a/libguile/gsubr.c
b/libguile/gsubr.c
+@@ -213,7 +213,7 @@
+ */
+ static const struct
+ {
+- scm_t_uint64 dummy; /* ensure 8-byte alignment; perhaps there's a better
way */
++ scm_t_uint64 dummy SCM_ALIGNED (sizeof (scm_t_uint64)); /* ensure 8-byte
alignment; perhaps there's a better way */
+ const scm_t_uint8 bytes[121 * (sizeof (struct scm_objcode) + 16
+ + sizeof (struct scm_objcode) + 32)];
+ } raw_bytecode = {
+@@ -317,7 +317,7 @@ static const struct
+
+ static const struct
+ {
+- scm_t_uint64 dummy; /* alignment */
++ scm_t_uint64 dummy SCM_ALIGNED (sizeof (scm_t_uint64)); /* alignment */
+ scm_t_cell cells[121 * 2]; /* 11*11 double cells */
+ } objcode_cells = {
+ 0,
+--- a/libguile/vm-engine.h
b/libguile/vm-engine.h
+@@ -74,7 +74,7 @@
+ #define FP_REG asm("%r16")
+ #endif
+ #ifdef __mc68000__
+-#define IP_REG asm("a5")
++#define IP_REG asm("a3")
+ #define SP_REG asm("a4")
+ #define FP_REG
+ #endif
diff -Nru guile-2.0-2.0.11+1/debian/patches/series
guile-2.0-2.0.11+1/debian/patches/series
--- guile-2.0-2.0.11+1/debian/patches/series2014-04-23 19:11:29.0
+0200
+++ guile-2.0-2.0.11+1/debian/patches/series2014-05-12 21:31:13.0
+0200
@@ -1,2 +1,3 @@
0001-Change-guile-to-guile-X.Y-for-info-pages.patch
0002-Mark-mutex-with-owner-not-retained-threads-test-as-u.patch
+9000-Fix-alignment-and-m68k-registers.patch
Re: preparing for GCC 4.9
Hi Matthias et al, I'd like to try to do some of this using my sparc box and see how far I get. Is there a link that explains how to set up these steps? Others seem to "just know" what to do, but I haven't the slightest idea of where to begin. I have a box with gcc-4.9, plenty of disk space, and electricity to burn. Where do I start? Patrick On Thu, May 8, 2014 at 10:25 AM, Matthias Klose wrote: > With gcc-4.9 now available in testing, it is time to prepare for the > change of > the default to 4.9, for a subset of architectures or for all (release) > architectures. The defaults for the gdc, gccgo, gcj and gnat frontends > already > point to 4.9 and are used on all architectures. Issue #746805 tracks the > gfortran default change, including the change of the Fortran 90 module > version > change. > > The Debian archive was rebuilt twice on amd64, once in February, resulting > in > bug submissions for GCC and feedback for the porting guide [1], a second > time in > March to file issues for packages failing to build with GCC 4.9 [2]. > Another > test rebuild for Ubuntu on amd64, i386, armhf, ppc64el didn't show any > other > compiler regressions on these architectures. > > I would like to see some partial test rebuilds (like buildd or minimal > chroot > packages) for other architectures. Any possibility to setup such a test > rebuild > for some architectures by the porters? Afaics the results for the GCC > testsuite > look okish for every architecture. > > I'll work on fixing the build failures in [2], help is of course > appreciated. > Almost all build failures are analyzed and should be easy to fix > (exceptions > e.g. #746883). Patches for the ones not caused by the Debian packaging > may be > found in distributions already using GCC 4.9 as the default compiler (e.g. > Fedora 21). > > If anything goes well, and a large amount of build failures are fixed, I > plan to > make GCC 4.9 the default for the C/C++/ObjC/Obj-C++ frontends at the end > of May, > beginning of June. > > Bugs reports for packages building with a legacy version of GCC (4.6, 4.7, > 4.8) > will be filed. > > Matthias > > [1] http://gcc.gnu.org/gcc-4.9/porting_to.html > [2] > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.9;users=debian-...@lists.debian.org > > > -- > To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: https://lists.debian.org/536ba1ce.9070...@debian.org > >
Re: preparing for GCC 4.9
I'm in the same boat as Patrick, except with a PowerMac G5. Please let us know how to begin. Thanks, Dave > On May 12, 2014, at 16:02, Patrick Baggett wrote: > > Hi Matthias et al, > > I'd like to try to do some of this using my sparc box and see how far I get. > Is there a link that explains how to set up these steps? Others seem to "just > know" what to do, but I haven't the slightest idea of where to begin. I have > a box with gcc-4.9, plenty of disk space, and electricity to burn. Where do I > start? > > Patrick > > >> On Thu, May 8, 2014 at 10:25 AM, Matthias Klose wrote: >> With gcc-4.9 now available in testing, it is time to prepare for the change >> of >> the default to 4.9, for a subset of architectures or for all (release) >> architectures. The defaults for the gdc, gccgo, gcj and gnat frontends >> already >> point to 4.9 and are used on all architectures. Issue #746805 tracks the >> gfortran default change, including the change of the Fortran 90 module >> version >> change. >> >> The Debian archive was rebuilt twice on amd64, once in February, resulting in >> bug submissions for GCC and feedback for the porting guide [1], a second >> time in >> March to file issues for packages failing to build with GCC 4.9 [2]. Another >> test rebuild for Ubuntu on amd64, i386, armhf, ppc64el didn't show any other >> compiler regressions on these architectures. >> >> I would like to see some partial test rebuilds (like buildd or minimal chroot >> packages) for other architectures. Any possibility to setup such a test >> rebuild >> for some architectures by the porters? Afaics the results for the GCC >> testsuite >> look okish for every architecture. >> >> I'll work on fixing the build failures in [2], help is of course appreciated. >> Almost all build failures are analyzed and should be easy to fix (exceptions >> e.g. #746883). Patches for the ones not caused by the Debian packaging may >> be >> found in distributions already using GCC 4.9 as the default compiler (e.g. >> Fedora 21). >> >> If anything goes well, and a large amount of build failures are fixed, I >> plan to >> make GCC 4.9 the default for the C/C++/ObjC/Obj-C++ frontends at the end of >> May, >> beginning of June. >> >> Bugs reports for packages building with a legacy version of GCC (4.6, 4.7, >> 4.8) >> will be filed. >> >> Matthias >> >> [1] http://gcc.gnu.org/gcc-4.9/porting_to.html >> [2] >> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.9;users=debian-...@lists.debian.org >> >> >> -- >> To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org >> Archive: https://lists.debian.org/536ba1ce.9070...@debian.org >
