Bug#889147: abyss: PairedDBG_LoadAlgorithm test fails on sparc64 due to strict alignment violation

2018-02-02 Thread David Matthew Mattli 
Package: abyss
Severity: normal
Tags: patch upstream
Usertags: sparc64

Dear Maintainer,

This package currently FTBFS on sparc64 due to the
PairedDBG_LoadAlgorithm test failing with a SIGBUS. The Kmer.load and
Kmer.storeReverse methods in the Common/Kmer.cpp file cast a uint8_t*
to a size_t* without ensuring the pointer value has the proper
alignment.

To fix this I added an aligned stack allocated buffer and memcpy to
that. Stack allocated is appropriate because the buffer size is
small(32 bytes) and known at compile time.

-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: sparc64

Kernel: Linux 4.14.0-3-sparc64-smp (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- a/Common/Kmer.cpp
+++ b/Common/Kmer.cpp
@@ -188,9 +188,10 @@
Seq seq;
 #if MAX_KMER > 96
 # if WORDS_BIGENDIAN
-   const size_t *s = reinterpret_cast(src);
+   size_t buf[Kmer::NUM_BYTES];
+   memcpy(buf, src, Kmer::NUM_BYTES);
size_t *d = reinterpret_cast( + 1);
-   copy(s, s + Kmer::NUM_BYTES/sizeof(size_t), 
reverse_iterator(d));
+   copy(buf, buf + Kmer::NUM_BYTES/sizeof(size_t), 
reverse_iterator(d));
 # else
uint8_t *d = reinterpret_cast();
memcpy(d, src, sizeof seq);
@@ -235,9 +236,10 @@
 #if MAX_KMER > 96
 # if WORDS_BIGENDIAN
const size_t *s = reinterpret_cast();
-   size_t *d = reinterpret_cast(dest);
+   size_t d[Kmer::NUM_BYTES];
copy(s, s + Kmer::NUM_BYTES/sizeof(size_t),
reverse_iterator(d +  
Kmer::NUM_BYTES/sizeof(size_t)));
+   memcpy(dest, d, Kmer::NUM_BYTES);
reverse(dest, dest + Kmer::NUM_BYTES);
 # else
memcpy(dest, , Kmer::NUM_BYTES);

Bug#835973: openjdk-8: please enable hotspot for sparc64

2016-08-29 Thread David Matthew Mattli 
Source: openjdk-8
Severity: wishlist
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

Dear Maintainer,



The openjdk-8 packages for sparc64 are currently configured to use the  

zero interpreter. This works fine but I wanted to find out what was 

blocking the use of the much faster hotspot compiler. Fortunately I 

found that simply enabling hotspot for sparc64 in the debian/rules  

file allows a sparc64 hotspot jvm to build. I used the current debian   

openjdk-8 as the bootstrap jvm. Here are the changes I made to the  

debian/rules file:  



--- openjdk-8-8u102-b14.1/debian/rules  2016-08-06 03:12:09.0 -0500 

+++ openjdk-8-8u102-b14.1-hotspot/debian/rules  2016-08-26 09:00:27.932659521 
-0500 
@@ -39,7 +39,7 @@   



 multiarch_dir = /$(DEB_HOST_MULTIARCH) 



-hotspot_archs  = amd64 i386 arm64 ppc64 ppc64el kfreebsd-amd64 kfreebsd-i386   

+hotspot_archs  = amd64 i386 arm64 ppc64 ppc64el kfreebsd-amd64 kfreebsd-i386 
sparc64   
 # FIXME: use bootcycle builds for zero archs?  

  bootcycle_build  = $(if $(filter $(DEB_HOST_ARCH), $(hotspot_archs)),yes) 

   ifneq ($(DEB_HOST_ARCH),$(DEB_BUILD_ARCH))   

   @@ -164,7 +164,7 @@  

# Shark build but just crash

 altshark_archs =   



-altzero_archs = $(filter-out sparc sparc64, $(hotspot_archs)) 
$(altshark_archs)   
 
+altzero_archs = $(filter-out sparc, $(hotspot_archs)) $(altshark_archs)



 ifeq (,$(filter noaltcacao, $(DEB_BUILD_OPTIONS))) 

ifneq (,$(filter $(DEB_HOST_ARCH), $(cacao_archs)))

Bug#714923: opencv FTBFS on sparc64

2016-02-01 Thread David Matthew Mattli 

Source: opencv
Followup-For: Bug #714923
User: debian-sp...@lists.debian.org
Usertags: sparc64

The _Atomic_word problem was reintroduced in two places and it's
breaking the sparc64 build again. You can see the problem in this
build log:

https://buildd.debian.org/status/fetch.php?pkg=opencv=sparc64=2.4.9.1%2Bdfsg-1.2=\
\
1452934608

I've updated the "change_type_from_int_to_Atomic_word" patch already
in the opencv package to add corrections for the problematic
lines. Please replace the current patch with the one attached to fix
the build.

Thanks,
David Mattli



-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: sparc64

Kernel: Linux 4.3.0-1-sparc64-smp (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


Description: Fix FTBFS on sparc64
Author: Aurelien Jarno , David Mattli 
Forwarded: not yet
Debian-Bug: 714923
Last-Update: <2015-01-25>

Index: opencv-2.4.9.1+dfsg/modules/core/include/opencv2/core/core.hpp
===
--- opencv-2.4.9.1+dfsg.orig/modules/core/include/opencv2/core/core.hpp
+++ opencv-2.4.9.1+dfsg/modules/core/include/opencv2/core/core.hpp
@@ -1300,7 +1300,7 @@ public:
 operator const _Tp*() const;
 
 _Tp* obj; //< the object pointer.
-int* refcount; //< the associated reference counter
+_Atomic_word* refcount; //< the associated reference counter
 };
 
 
@@ -1468,9 +1468,9 @@ class CV_EXPORTS MatAllocator
 public:
 MatAllocator() {}
 virtual ~MatAllocator() {}
-virtual void allocate(int dims, const int* sizes, int type, int*& refcount,
+virtual void allocate(int dims, const int* sizes, int type, _Atomic_word*& 
refcount,
   uchar*& datastart, uchar*& data, size_t* step) = 0;
-virtual void deallocate(int* refcount, uchar* datastart, uchar* data) = 0;
+virtual void deallocate(_Atomic_word* refcount, uchar* datastart, uchar* 
data) = 0;
 };
 
 /*!
@@ -1965,7 +1965,7 @@ public:
 
 //! pointer to the reference counter;
 // when matrix points to user-allocated data, the pointer is NULL
-int* refcount;
+_Atomic_word* refcount;
 
 //! helper fields used in locateROI and adjustROI
 uchar* datastart;
@@ -3384,7 +3384,7 @@ public:
 {
 Hdr(int _dims, const int* _sizes, int _type);
 void clear();
-int refcount;
+_Atomic_word refcount;
 int dims;
 int valueOffset;
 size_t nodeSize;
Index: opencv-2.4.9.1+dfsg/modules/core/include/opencv2/core/gpumat.hpp
===
--- opencv-2.4.9.1+dfsg.orig/modules/core/include/opencv2/core/gpumat.hpp
+++ opencv-2.4.9.1+dfsg/modules/core/include/opencv2/core/gpumat.hpp
@@ -301,7 +301,7 @@ namespace cv { namespace gpu
 
 //! pointer to the reference counter;
 // when GpuMatrix points to user-allocated data, the pointer is NULL
-int* refcount;
+_Atomic_word* refcount;
 
 //! helper fields used in locateROI and adjustROI
 uchar* datastart;
Index: opencv-2.4.9.1+dfsg/modules/core/include/opencv2/core/operations.hpp
===
--- opencv-2.4.9.1+dfsg.orig/modules/core/include/opencv2/core/operations.hpp
+++ opencv-2.4.9.1+dfsg/modules/core/include/opencv2/core/operations.hpp
@@ -2281,7 +2281,7 @@ public:
 Hdr() : data(0), datastart(0), refcount(0), size(0), capacity(0) {};
 _Tp* data;
 _Tp* datastart;
-int* refcount;
+_Atomic_word* refcount;
 size_t size;
 size_t capacity;
 };
@@ -2588,7 +2588,7 @@ template inline Ptr<_Tp>::
 {
 if(obj)
 {
-refcount = (int*)fastMalloc(sizeof(*refcount));
+refcount = (_Atomic_word*)fastMalloc(sizeof(*refcount));
 *refcount = 1;
 }
 else
@@ -2625,7 +2625,7 @@ template inline Ptr<_Tp>::
 
 template inline Ptr<_Tp>& Ptr<_Tp>::operator = (const Ptr<_Tp>& 
_ptr)
 {
-int* _refcount = _ptr.refcount;
+_Atomic_word* _refcount = _ptr.refcount;
 if( _refcount )
 CV_XADD(_refcount, 1);
 release();
Index: opencv-2.4.9.1+dfsg/modules/core/src/gpumat.cpp
===
--- opencv-2.4.9.1+dfsg.orig/modules/core/src/gpumat.cpp
+++ opencv-2.4.9.1+dfsg/modules/core/src/gpumat.cpp
@@ -716,7 +716,7 @@ void cv::gpu::GpuMat::create(int _rows,
 datastart = data = static_cast(devPtr);
 dataend = data + nettosize;
 
-refcount = static_cast(fastMalloc(sizeof(*refcount)));
+refcount = static_cast<_Atomic_word*>(fastMalloc(sizeof(*refcount)));
 *refcount = 1;
 }
 }
Index: opencv-2.4.9.1+dfsg/modules/core/src/matrix.cpp

Bug#806992: ffcall: New upstream release 1.12, fixes sparc64 and ppc64el

2015-12-03 Thread David Matthew Mattli 
Package: ffcall
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64

There's a new upstream release of this package that
includes newer sparc64 asm files that have a
different syntax that modern gcc accepts. It also
claims to fix the ppc64el build but I don't have
the ability to test that.

The release was announced here:
http://lists.gnu.org/archive/html/libffcall/2015-08/msg1.html

The tarballs are here:
https://github.com/libffcall/libffcall/releases

Thanks!
David

-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: sparc64

Kernel: Linux 4.3.0-gentoo (SMP w/1 CPU core)
Locale: LANG=en_SG.UTF-8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#806816: webkit2gtk: FTBFS on sparc64

2015-12-02 Thread David Matthew Mattli 
Alberto Garcia  writes:
> Thanks! Did you check if the browser works fine? You can use the
> shipped MiniBrowser binary for that.
>
> Berto

Hi Berto

Thanks for the reply. Unfortunately the MiniBrowser fails with a Bus
Error. The problem doesn't appear to be with webkit though. gdb says the
error is occuring in gtk and the other gtk apps I've tried failed
similarly. I'll try to track down the gtk issue next.

The other potential issue with webkit2gtk is that bmalloc assumes 4k
pages and sparc64 has 8k pages. Does the Debian package use bmalloc by
default? If so it will have to be disabled for sparc64 and use the
system malloc instead. If you're not sure I'll verify what it's doing
after I look at gtk.

Thanks!
David

Bug#806837: qtwebkit: FTBFS on sparc64

2015-12-01 Thread David Matthew Mattli 
Source: qtwebkit
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

Dear Maintainer,

qtwebkit currently fails to build for sparc64. I was able to
fix the build by adding sparc64 to the list of non-JIT archs
in debian/rules, fixing a declaration of UChar32, and removing
a condition disabling atomics on sparc64. Newer versions of gcc
implement builtin atomic operations for all integer types.

Below is the change to debian/rules and I've attached the patch
that changes the two headers. The changes are simple and shouldn't
affect other archs.

Similar changes have already been made upstream in newer versions
of webkit but they seem to implement an incompatible qt api.

--- a/debian/rules2015-09-15 08:05:20.0 -0500
+++ b/debian/rules2015-12-01 10:18:33.501211135 -0600
@@ -50,7 +50,7 @@
#disable JIT assembler on archs where it doesn't compile
#disable WTF_USE_3D_GRAPHICS on ARM where it doesn't compile
#disable forcing SSE2 on all other platforms
-ifneq (,$(filter arm64 armel hppa mips mipsel mips64 mips64el powerpc ppc64el 
s390x x32,$(DEB_HOST_ARCH)))
+ifneq (,$(filter arm64 armel hppa mips mipsel mips64 mips64el powerpc ppc64el 
s390x sparc64 x32,$(DEB_HOST_ARCH)))
./Tools/Scripts/build-webkit --qt DEFINES+=ENABLE_JIT=0 
DEFINES+=ENABLE_YARR_JIT=0 DEFINES+=ENABLE_ASSEMBLER=0 $(QMAKE_ARGS) 
$(MAKE_ARGS)
 else ifeq ($(DEB_HOST_ARCH),armhf)
./Tools/Scripts/build-webkit --qt DEFINES+=WTF_USE_3D_GRAPHICS=0 
DEFINES+=ENABLE_JIT=0 DEFINES+=ENABLE_YARR_JIT=0 DEFINES+=ENABLE_ASSEMBLER=0 
$(QMAKE_ARGS) $(MAKE_ARGS)



-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: sparc64

Kernel: Linux 4.3.0-gentoo (SMP w/1 CPU core)
Locale: LANG=en_SG.UTF-8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
--- a/Source/WTF/wtf/unicode/qt4/UnicodeQt4.h
+++ b/Source/WTF/wtf/unicode/qt4/UnicodeQt4.h
@@ -69,8 +69,12 @@
 #endif
 
 #if !USE(ICU_UNICODE)
+#ifdef __sparc_v9__
+typedef int32_t UChar32;
+#else
 typedef uint32_t UChar32;
 #endif
+#endif
 
 namespace WTF {
 namespace Unicode {
--- a/Source/WTF/wtf/Atomics.h
+++ b/Source/WTF/wtf/Atomics.h
@@ -98,7 +98,7 @@
 inline int atomicIncrement(int volatile* addend) { return __atomic_inc(addend) + 1; }
 inline int atomicDecrement(int volatile* addend) { return __atomic_dec(addend) - 1; }
 
-#elif COMPILER(GCC) && !CPU(SPARC64) // sizeof(_Atomic_word) != sizeof(int) on sparc64 gcc
+#elif COMPILER(GCC)
 #define WTF_USE_LOCKFREE_THREADSAFEREFCOUNTED 1
 
 inline int atomicIncrement(int volatile* addend) { return __sync_add_and_fetch(addend, 1); }

Bug#806816: webkit2gtk: FTBFS on sparc64

2015-12-01 Thread David Matthew Mattli 
Source: webkit2gtk
Severity: normal
Tags: upstream patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

The webkit2gtk build currently fails on sparc64. You can see
an example build failure log here:
https://buildd.debian.org/status/fetch.php?pkg=webkit2gtk=sparc64=2.10.3%2Bdfsg1-1=1448169030

I patched a few header files and the cmake build files to
help webkit understand the sparc64 platform. With these
changes the build completes successfully for me.


-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: sparc64

Kernel: Linux 4.3.0-gentoo (SMP w/1 CPU core)
Locale: LANG=en_SG.UTF-8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
--- a/Source/WTF/wtf/Platform.h
+++ b/Source/WTF/wtf/Platform.h
@@ -153,6 +153,12 @@
 #define WTF_CPU_BIG_ENDIAN 1
 #endif
 
+/* CPU(SPARC64) - sparc64 */
+#if defined(__sparc__) && defined(__sparc_v9__)
+#define WTF_CPU_SPARC64 1
+#define WTF_CPU_BIG_ENDIAN 1
+#endif
+
 /* CPU(X86) - i386 / x86 32-bit */
 #if   defined(__i386__) \
 || defined(i386) \
@@ -340,7 +346,7 @@
 
 #endif /* ARM */
 
-#if CPU(ARM) || CPU(MIPS) || CPU(SH4)
+#if CPU(ARM) || CPU(MIPS) || CPU(SH4) || CPU(SPARC64)
 #define WTF_CPU_NEEDS_ALIGNED_ACCESS 1
 #endif
 
@@ -692,6 +698,7 @@
 || CPU(ALPHA) \
 || CPU(ARM64) \
 || CPU(S390X) \
+|| CPU(SPARC64) \
 || CPU(MIPS64) \
 || CPU(PPC64) \
 || CPU(PPC64LE)
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -111,6 +111,8 @@
 set(WTF_CPU_S390 1)
 elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "s390x")
 set(WTF_CPU_S390X 1)
+elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "sparc64")
+set(WTF_CPU_SPARC64 1)
 else ()
 message(FATAL_ERROR "Unknown CPU '${LOWERCASE_CMAKE_SYSTEM_PROCESSOR}'")
 endif ()
--- a/Source/JavaScriptCore/CMakeLists.txt
+++ b/Source/JavaScriptCore/CMakeLists.txt
@@ -1161,6 +1161,7 @@
 elseif (WTF_CPU_S390X)
 elseif (WTF_CPU_MIPS)
 elseif (WTF_CPU_SH4)
+elseif (WTF_CPU_SPARC64)
 elseif (WTF_CPU_X86)
 elseif (WTF_CPU_X86_64)
 if (MSVC AND ENABLE_JIT)
--- a/Source/WTF/wtf/dtoa/utils.h
+++ b/Source/WTF/wtf/dtoa/utils.h
@@ -49,7 +49,7 @@
 defined(__ARMEL__) || \
 defined(_MIPS_ARCH_MIPS32R2)
 #define DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS 1
-#elif CPU(MIPS) || CPU(MIPS64) || CPU(PPC) || CPU(PPC64) || CPU(PPC64LE) || CPU(SH4) || CPU(S390) || CPU(S390X) || CPU(IA64) || CPU(ALPHA) || CPU(ARM64) || CPU(HPPA)
+#elif CPU(MIPS) || CPU(MIPS64) || CPU(PPC) || CPU(PPC64) || CPU(PPC64LE) || CPU(SH4) || CPU(S390) || CPU(S390X) || CPU(IA64) || CPU(ALPHA) || CPU(ARM64) || CPU(HPPA) || CPU(SPARC64)
 #define DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS 1
 #elif defined(_M_IX86) || defined(__i386__)
 #if defined(_WIN32)

Bug#806667: emacs24: FTBFS on sparc64, Bus Error during lucid build

2015-11-29 Thread David Matthew Mattli 
Source: emacs24
Severity: normal
Tags: upstream patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

Dear Maintainer,

The emacs24 build is currently failing on sparc64 with a Bus
Error. You can see an example build log here:

https://buildd.debian.org/status/fetch.php?pkg=emacs24=sparc64=24.5%2B1-5=1448688813

I've attached a patch that corrects an unaligned pointer dereference
in src/unexelf.c. But my fix is more of a hack and probably not suitable
for submitting to upstream.

I'm going to continue looking at this issue to try to create a 
more robust fix to offer upstream.

Below is a short explaination of what I've found looking into this
build failure.


The lucid build is failing with this error:

Loading /«BUILDDIR»/emacs24-24.5+1/debian/build-lucid/lisp/electric.el 
(source)...
Loading /«BUILDDIR»/emacs24-24.5+1/debian/build-lucid/lisp/tooltip.el 
(source)...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name emacs
/bin/bash: line 7: 19090 Bus error   ./temacs --batch --load loadup 
bootstrap
make[3]: *** [bootstrap-emacs] Error 1
Makefile:815: recipe for target 'bootstrap-emacs' failed
make[3]: Leaving directory '/«BUILDDIR»/emacs24-24.5+1/debian/build-lucid/src'
make[2]: *** [src] Error 2
Makefile:389: recipe for target 'src' failed

Loading 'temacs' in gdb the bus error occurs in the file
src/unexelf.c, around line 980:

  */

  if (NEW_SECTION_H (nn).sh_offset >= old_bss_offset
  || (NEW_SECTION_H (nn).sh_offset + NEW_SECTION_H (nn).sh_size
  > new_data2_offset))
NEW_SECTION_H (nn).sh_offset += new_data2_incr;

With this instruction:

0x294c20   ldx  [ %g4 + 0x18 ], %g2

   // info reg g4 => 0x80011458013b -140732852076229

So it's trying to load an extended word (64bits, 8 bytes) from an
unaligned address.

NEW_SECTION_H is a macro that generates a pointer offset from
'new_section_h'.

static void * 
   entry_address (void *section_h, ptrdiff_t idx, ptrdiff_t entsize)
{
  char *h = section_h;
  return h + idx * entsize;
}

#define NEW_SECTION_H(n) \
  (*(ElfW (Shdr) *) entry_address (new_section_h, n, 
new_file_h->e_shentsize))

If 'new_section_h' is properly aligned this should be ok because it's
adding multiples of 'e_shentsize' which is 8. But new_section_h is
/not/ aligned so the resulting pointer is also not aligned.

Here is how 'new_section_h' is computed:

new_section_h = (ElfW (Shdr) *)
((byte *) new_base + old_file_h->e_shoff + new_data2_incr);

GDB says the components of this sum have these values:

(gdb) print new_base
$6 = (caddr_t) 0x8001126aa000 "\177ELF\002\002\001"
(gdb) print old_file_h->e_shoff
$7 = 15751616
(gdb) print new_data2_incr
$8 = 16582459


'new_base' and 'old_file_h->e_shoff' are both 8 byte aligned but
'new_data2_incr' is not.

'new_data2_incr' is calculated this way:

new_data2_incr = new_data2_size + (new_data2_offset - old_bss_offset);

It seems like 'new_data2_incr' is just an offset so it would be ok to
round it up to the nearest multiple of 8, using a function already
used in the file:

new_data2_incr = round_up(new_data2_incr, (ElfW (Addr))8);

Adding this line to src/unexelf.c allows the build to finish normally. 

-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: sparc64

Kernel: Linux 4.3.0-gentoo (SMP w/1 CPU core)
Locale: LANG=en_SG.UTF-8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
--- a/src/unexelf.c
+++ b/src/unexelf.c
@@ -779,6 +779,9 @@
  the end of the old .data section (and thus the offset of the .bss
  section) was unaligned.  */
   new_data2_incr = new_data2_size + (new_data2_offset - old_bss_offset);
+#ifdef __sparc_v9__
+  new_data2_incr = round_up(new_data2_incr, (ElfW (Addr))8);
+#endif
 
 #ifdef UNEXELF_DEBUG
   fprintf (stderr, "old_bss_index %td\n", old_bss_index);

Bug#805904: emacs24: FTBFS anywhere after 24.5+1-4

2015-11-23 Thread David Matthew Mattli 
Source: emacs24
Version: 24.5+1-4
Severity: serious
Justification: 4

With version 24.5+1-4 emacs24 fails to build on all 
archs because of a missing file. For example,
you can find the build log for i386 here:

https://buildd.debian.org/status/fetch.php?pkg=emacs24=i386=24.5%2B1-4=1446934624

And the error is:

make[1]: Entering directory '/«BUILDDIR»/emacs24-24.5+1'
cp -a debian/emacs24-el/usr/share/emacs/24.5/lisp/version.el.gz \
  debian/elgz-canary
cp: cannot stat 
'debian/emacs24-el/usr/share/emacs/24.5/lisp/version.el.gz': No such file or 
directory
debian/rules:613: recipe for target 'override_dh_strip_nondeterminism' 
failed



-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: sparc64

Kernel: Linux 4.3.0-gentoo (SMP w/1 CPU core)
Locale: LANG=en_SG.UTF-8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#805884: ion: FTBFS on sparc64, tv_usec wrong type in printf

2015-11-23 Thread David Matthew Mattli 
Source: ion
Severity: important
Tags: upstream patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

Dear Maintainer,

The ion package currently fails to build on sparc64. The build log
can be seen here:

https://buildd.debian.org/status/fetch.php?pkg=ion=sparc64=3.2.1%2Bdfsg-1=1448045105

The error that stops the build is this:

   gcc -DHAVE_CONFIG_H -I. -I..   -D_FORTIFY_SOURCE=2 
-I./dtnperf/al_bp/src/bp_implementations -I./dtnperf/al_bp/src 
-I./../bp/include -I./../bp/library -fmessage-length=0 -Dlinux 
-fno-strict-aliasing -DENABLE_BPACS -DENABLE_IMC -Wall -Werror -g -include 
./../config.h  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-DNOEXPAT -c -o dtnperf/dtnperf/src/dtnperf_vION-csv_tools.o `test -f 
'dtnperf/dtnperf/src/csv_tools.c' || echo './'`dtnperf/dtnperf/src/csv_tools.c
dtnperf/dtnperf/src/csv_tools.c: In function 'csv_print_rx_time':
dtnperf/dtnperf/src/csv_tools.c:24:15: error: format '%ld' expects argument 
of type 'long int', but argument 4 has type '__suseconds_t {aka int}' 
[-Werror=format=]
  sprintf(buf, "%ld.%ld;", result->tv_sec, result->tv_usec);
   ^  
cc1: all warnings being treated as errors

What's happening is that Werror is enabled for format expressions and
in the sprintf call here:

sprintf(buf, "%ld.%ld;", result->tv_sec, result->tv_usec);

The last argument 'result->tv_usec' does not match the flag '%ld'
which is for 'long'.  Apparantly on sparc64 'tv_usec' is type 'int'.
A simple solution which will work on all archs is to add a cast to
'long' to the fourth argument:

sprintf(buf, "%ld.%ld;", result->tv_sec, (long)result->tv_usec);

On archs where 'tv_usec' is long the cast will do nothing and on
sparc64 the cast will widen the int to a long.

I've attached a patch that implements this change and which allows the
package to build on sparc64.

If you're going to suggest a change for upstream I'd ask them to
consider changing it to this:

sprintf(buf, "%lld.%lld;", (long long)result->tv_sec, (long 
long)result->tv_usec);

By using the format flags for and casting to 'long long' the format
will work with any width of 'tv_sec' and 'tv_usec'. And because 'long
long' will be the widest integer on the platform it won't truncate
values.

Thanks!
David


-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: sparc64

Kernel: Linux 4.3.0-gentoo (SMP w/1 CPU core)
Locale: LANG=en_SG.UTF-8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
--- a/contrib/dtnperf/dtnperf/src/csv_tools.c
+++ b/contrib/dtnperf/dtnperf/src/csv_tools.c
@@ -21,7 +21,7 @@
 	struct timeval * result = malloc(sizeof(struct timeval));
 	char buf[50];
 	sub_time(time, start_time, result);
-	sprintf(buf, "%ld.%ld;", result->tv_sec, result->tv_usec);
+	sprintf(buf, "%ld.%ld;", result->tv_sec, (long)result->tv_usec);
 	fwrite(buf, strlen(buf), 1, file);
 }

Bug#805846: openjdk-7: FTBFS on sparc64, missing asm/ptrace header, patch attached

2015-11-22 Thread David Matthew Mattli 
Source: openjdk-7
Severity: important
Tags: patch
Justification: fails to build from source
User: debian-sp...@lists.debian.org
Usertags: sparc64

Dear Maintainer,

Currently openjdk-7 is configured to use the zero vm on
sparc64. However zero doesn't seem to build. If hotspot is enabled for
sparc64 the build fails with several similar errors concerning a
struct, you can see here:

https://buildd.debian.org/status/fetch.php?pkg=openjdk-7=sparc64=7u85-2.6.1-1=1441319505

/«PKGBUILDDIR»/build/openjdk-boot/hotspot/agent/src/os/linux/ps_core.c: In 
function 'core_handle_prstatus':
/«PKGBUILDDIR»/build/openjdk-boot/hotspot/agent/src/os/linux/ps_core.c:542:49: 
error: invalid application of 'sizeof' to incomplete type 'struct pt_regs'
memcpy(>regs, prstat->pr_reg, sizeof(struct user_regs_struct));
 ^
In file included from 
/«PKGBUILDDIR»/build/openjdk-boot/hotspot/agent/src/os/linux/LinuxDebuggerLocal.c:27:0:
/«PKGBUILDDIR»/build/openjdk-boot/hotspot/agent/src/os/linux/libproc.h:80:27: 
warning: 'struct pt_regs' declared inside parameter list
 #define user_regs_struct  pt_regs
   ^
/«PKGBUILDDIR»/build/openjdk-boot/hotspot/agent/src/os/linux/libproc.h:114:65: 
note: in expansion of macro 'user_regs_struct'
 bool get_lwp_regs(struct ps_prochandle* ph, lwpid_t lid, struct 
user_regs_struct* regs);
 ^
/«PKGBUILDDIR»/build/openjdk-boot/hotspot/agent/src/os/linux/libproc.h:80:27: 
warning: its scope is only this definition or declaration, which is probably 
not what you want
 #define user_regs_struct  pt_regs
   ^
/«PKGBUILDDIR»/build/openjdk-boot/hotspot/agent/src/os/linux/libproc.h:114:65: 
note: in expansion of macro 'user_regs_struct'
 bool get_lwp_regs(struct ps_prochandle* ph, lwpid_t lid, struct 
user_regs_struct* regs);


What's happening is that 'user_regs_struct' is defined to be 'pt_regs'
but 'pt_regs' isn't declared anywhere so the compiler interprets the
first use of 'struct user_regs_struct' to be the declaration. Then
because it's not fully defined the compiler complains that it doesn't
know the size of the incomplete type and the build fails.

So the real problem is 'struct pt_regs'.

A simple fix would be to add the header 'asm/ptrace.h' to the file
'openjdk/hotspot/agent/src/os/linux/libproc.h'. With this change the
build completes successfully for me. I've attached a patch to achieve
this.

If sparc64 is added to the list of hotspot archs and this patch
included in DISTRIBUTION_PATCHES in debian/rules should fix the
build for sparc64.

Thanks!
David


-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: sparc64

Kernel: Linux 4.3.0-gentoo (SMP w/1 CPU core)
Locale: LANG=en_SG.UTF-8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Index: openjdk/hotspot/agent/src/os/linux/libproc.h
===
--- openjdk/hotspot/agent/src/os/linux/libproc.h.old	2015-11-12 22:57:20.0 -0600
+++ openjdk/hotspot/agent/src/os/linux/libproc.h		2015-11-22 10:49:17.684049960 -0600
@@ -34,6 +34,7 @@
 #include "libproc_md.h"
 #endif
 
+#include 
 #include 
 
 /

Bug#805211: libffado: FTBFS: error: function ‘int* __errno_location()’ is initialized like a variable

2015-11-21 Thread David Matthew Mattli 
Source: libffado
Followup-For: Bug #805211

Dear Maintainer,

In several of the tests in this package 'errno' is declared as an
int. However, errno is provided by the c runtime and may be a macro so
declaring it again as an int is an error. This is breaking the build on,
at least, sparc64. Fortunately the fix is simple: change the errno
declaration to an 'extern'. Removing the entire 'int errno' declaration
and including  would work as well.

Included is a patch that changes the declarations:

int errno = 0;

to

extern int errno;

This allows the package to build on sparc64 and doesn't break the build
on other archs.

Thanks!
David

-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: sparc64

Kernel: Linux 4.3.0-gentoo (SMP w/1 CPU core)
Locale: LANG=en_SG.UTF-8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
--- a/tests/test-enhanced-mixer.cpp
+++ b/tests/test-enhanced-mixer.cpp
@@ -77,7 +77,7 @@
 exit(0);
 }
 
-int errno = 0;
+extern int errno;
 char* tail;
 int node_id = strtol( argv[1], , 0 );
 int fb_id   = strtol( argv[2], , 0 );
--- a/tests/test-mixer.cpp
+++ b/tests/test-mixer.cpp
@@ -227,7 +227,7 @@
 exit(0);
 }
 
-int errno = 0;
+extern int errno;
 char* tail;
 int port = strtol( argv[1], , 0 );
 int node_id = strtol( argv[2], , 0 );
--- a/tests/test-pan.cpp
+++ b/tests/test-pan.cpp
@@ -131,7 +131,7 @@
 exit(0);
 }
 
-int errno = 0;
+extern int errno;
 char* tail;
 int node_id = strtol( argv[1], , 0 );
 int fb_id   = strtol( argv[2], , 0 );
--- a/tests/test-volume.cpp
+++ b/tests/test-volume.cpp
@@ -127,7 +127,7 @@
 exit(0);
 }
 
-int errno = 0;
+extern int errno;
 char* tail;
 int node_id = strtol( argv[1], , 0 );
 int fb_id   = strtol( argv[2], , 0 );

Bug#805072: protobuf: FTBFS on sparc64 - apparently tries to build x86 code

2015-11-21 Thread David Matthew Mattli 
Source: protobuf
Followup-For: Bug #805072

Dear Maintainer,

The x86 sources are actually included on every platform. If you look at the
build logs for powerpc for example you can see them being included. The
contents are just preprocessed out everywhere except on intel.

The build is failing because the type 'Atomic64' is not defined. This is
supposed to be defined in src/google/protobuf/stubs/atomicops.h:

#ifdef GOOGLE_PROTOBUF_ARCH_64_BIT
// We need to be able to go between Atomic64 and AtomicWord implicitly.  
This
// means Atomic64 and AtomicWord should be the same type on 64-bit.
#if defined(__ILP32__) || defined(GOOGLE_PROTOBUF_OS_NACL) || 
defined(GOOGLE_PROTOBUF_ARCH_SPARC)
// NaCl's intptr_t is not actually 64-bits on 64-bit!
// http://code.google.com/p/nativeclient/issues/detail?id=1162
// sparcv9's pointer type is 32bits
typedef int64 Atomic64;
#else
typedef intptr_t Atomic64;
#endif
#endif

But it is failing to be defined here because GOOGLE_PROTOBUF_ARCH_64_BIT
is not being defind on Debian/sparc64. GOOGLE_PROTOBUF_ARCH_64_BIT is
supposed to be defined in src/google/protobuf/stubs/platform_macros.h.
Here is the section about sparc:

#elif defined(sparc)
#define GOOGLE_PROTOBUF_ARCH_SPARC 1
#ifdef SOLARIS_64BIT_ENABLED
#define GOOGLE_PROTOBUF_ARCH_64_BIT 1
#else
#define GOOGLE_PROTOBUF_ARCH_32_BIT 1
#endif

So it's checking whether SOLARIS_64BIT_ENABLED is defined to determine
if it's on a 64bit arch. This is not defined on sparc64 linux so 
but instead we can check for __LP64__, making that section into:

#elif defined(sparc)
#define GOOGLE_PROTOBUF_ARCH_SPARC 1
#if defined(SOLARIS_64BIT_ENABLED) || defined(__LP64__)
#define GOOGLE_PROTOBUF_ARCH_64_BIT 1
#else
#define GOOGLE_PROTOBUF_ARCH_32_BIT 1
#endif

So now it checks for either SOLARIS_64BIT_ENABLED or __LP64__ to 
determine whether the sparc platform is 64bit. With this change the package
builds on my sparc64 system and it shouldn't affect any other archs.

I've attached a patch to implement this change.

Thanks!
David


-- System Information:
Debian Release: stretch/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: sparc64

Kernel: Linux 4.3.0-gentoo (SMP w/1 CPU core)
Locale: LANG=en_SG.UTF-8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
--- a/src/google/protobuf/stubs/platform_macros.h
+++ b/src/google/protobuf/stubs/platform_macros.h
@@ -67,7 +67,7 @@
 #define GOOGLE_PROTOBUF_ARCH_32_BIT 1
 #elif defined(sparc)
 #define GOOGLE_PROTOBUF_ARCH_SPARC 1
-#ifdef SOLARIS_64BIT_ENABLED
+#if defined(SOLARIS_64BIT_ENABLED) || defined(__LP64__)
 #define GOOGLE_PROTOBUF_ARCH_64_BIT 1
 #else
 #define GOOGLE_PROTOBUF_ARCH_32_BIT 1

Bug#789180: linux: Register corruption bug on sparc, please enable SLUB as workaround

2015-06-18 Thread David Matthew Mattli 
Source: linux
Severity: important
Tags: upstream

Dear Maintainer,

The kernel has a register corruption bug on sparc that is causing corruption
and failed builds. Enabling SLUB instead of SLAB in the kernel is an
effective workaround.

James Y Knight observed it here

https://lists.debian.org/debian-sparc/2015/06/msg5.html

and he includes the source for a test case. It is also causing failed builds
such as this

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789013

This problem has been around for a long time. I haven't been able to find a 
good version to bisect from.

During the course of my testing I discovered an effective workaround, enabling
SLUB as the kernel allocator instead of SLAB seems to prevent the error from
occurring. 

With SLAB enabled Knight's test program produces an error within seconds.
With SLUB enabled Knight's test program ran for more than 10 hours without
producing an error. SLUB also fixes the nettle build.

Because this workaround seems to be very effective and should have a very low
impact on users I request that you enable SLUB on sparc kernels while the
cause of the problem is investigated.

I'll add a patch once I figure out the Debian kernel config generation. But it
seems like it would look something like:

##
## file: init/Kconfig
##
# CONFIG_SLAB is not set
CONFIG_SLUB=y

added to debian/config/kernelarch-sparc/config .

Thanks,
David

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: sparc (sparc64)
Foreign Architectures: sparc64

Kernel: Linux 4.1.0-rc7.201506100842+ (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688246: qgis fails to build on powerpc due to internal spatialite

2012-09-20 Thread David Matthew Mattli 
Package: qgis
Version: 1.7.4+1.7.5~20120320-1.1
Severity: important
Tags: 

Dear Maintainer,

qgis currently fails to build on powerpc. The problem seems to be
the src/core/spatialite/spatialite.c file which somehow makes
gcc emit code that the assembler rejects. I have two powerpc
systems that I've reproduced the problem on. They have identical
output to buildd log:
https://buildd.debian.org/status/fetch.php?pkg=qgisarch=powerpcver=1.7.4%2B1.7.5~20120320-1.1stamp=1337680851

I tried to build with both gcc-4.6 and gcc-4.7 but get the 
same errors.

qgis has libspatialite-dev as a build-dep and libspatialite3 as
a depedency of the binary package, through libgdal1, so why not
use the external libspatialite ?

I removed the comment from the line
   CMAKE_OPTS += -D WITH_INTERNAL_SPATIALITE=FALSE
in the debian/rules file and the package builds fine.

The maintainers of qgis say that the amalgamated version of 
spatialite.c included with qgis is mainly for windows support:
http://hub.qgis.org/issues/4030

This is the section I changed:

--- rules  2012-09-20 11:37:58.0 -0500
+++ rules   2012-09-20 10:33:59.0 -0500
@@ -43,7 +43,7 @@
 #ifeq (,$(findstring $(DISTRIBUTION),squeeze lucid maverick natty sid))
CMAKE_OPTS += -D WITH_INTERNAL_SPATIALITE=TRUE
 #else
-#  CMAKE_OPTS += -D WITH_INTERNAL_SPATIALITE=FALSE
+   CMAKE_OPTS += -D WITH_INTERNAL_SPATIALITE=FALSE
 #endif
 
 ifneq (,$(findstring $(DISTRIBUTION),hardy intrepid))


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc64)

Kernel: Linux 3.2.0-3-powerpc64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#578588: spu-tools: spu-top segfaults when /spu directory doesn't exist

2010-04-20 Thread David Matthew Mattli 

Package: spu-tools
Version: 2.3.0.136-1
Severity: normal
Tags: patch upstream


The spu-top program will segfault if the system doesn't have a /spu directory.
Also if the directory is removed while spu-top is running it will segfault. A
simple fix is attached that just checks if the call to read info from /spu fails
and exits the program if it does. A better fix would probably involve informing 
the user somehow but this patch at least shows the problem area.

--- src/spu-top.c2008-06-05 09:22:49.0 -0500
+++ src/spu-top.c   2010-04-20 18:48:45.0 -0500
@@ -424,6 +424,9 @@
/* Providing a valid time range for the first measure (0.055 sec) */
spus = get_spus();
ctxs = get_spu_contexts(refresh_delay);
+   if (ctxs == NULL) {
+   quit();
+   }
procs = get_procs(ctxs);
usleep(55000);
 
@@ -442,6 +445,9 @@
if (min_time_has_passed) {
spus = get_spus();
ctxs = get_spu_contexts(period);
+   if (ctxs == NULL) {
+   quit();
+   }
procs = get_procs(ctxs);
fill_spus_tids(spus, ctxs);
last_time = current_time;


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc64)

Kernel: Linux 2.6.34-rc4--20100417-02-00115-gdc57da3 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages spu-tools depends on:
ii  libc6 2.10.2-6   Embedded GNU C Library: Shared lib
ii  libncurses5   5.7+20100313-2 shared libraries for terminal hand

spu-tools recommends no packages.

spu-tools suggests no packages.

-- no debconf information




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#503255: sbcl: Error using null pointer in ffi

2008-10-24 Thread David Matthew Mattli 
On Fri, Oct 24, 2008 at 12:49:52PM +0200, Luca Capello wrote:
 Hi there!
 
 For the d-release list: this is a request about how to fix the bug below
 in time for lenny.
 
 For everyone: please keep at least the bug report cc:ed, no subscription
 needed, TIA.
 
 On Fri, 24 Oct 2008 01:48:53 +0200, David Matthew Mattli wrote:
  Package: sbcl
  Version: 1:1.0.18.0-1
  Severity: important
 
  Whenever uses sbcl uses a null pointer in a cffi call it gives the 
  following 
  error:
 
  #.(SB-SYS:INT-SAP #X) fell through ETYPECASE expression.
 Wanted one of (CHARACTER SYMBOL INTEGER). 
 
  This problem was not present in sbcl-1.0.17 and is fixed in 1.0.19.14. 
  Updating sbcl to the latest version will fix this bug. This bug was 
  reported 
  and a fix reported on the sbcl-devel list.
 
  http://groups.google.com/group/sbcl-devel/browse_thread/thread/b67a3e18bb7a7dea
 
 David, first of all thank you for the report.
 
 I haven't looked yet at it in details, but is there any upstream bug
 opened, maybe with a patch that can backported to SBCL-1.0.17?  In that
 case the fix can be easily applied to the version already present in
 lenny and then the migration will be smoother.
 
 On the contrary, if backporting the fix is not so trivial, let's see if
 the RM accepts a new source upload for lenny.
 
 Thx, bye,
 Gismo / Luca

Luca, 

Thanks for your quick reply. I've tracked down the fixed applied in
the sbcl cvs for this specific issue.  The relevant messages to
sbcl-commit are here for x86:
http://sourceforge.net/mailarchive/forum.php?thread_name=E1KOy9Y-0006Iv-Uh%40sc8-pr-cvs8.sourceforge.netforum_name=sbcl-commits

And here for amd64:
http://sourceforge.net/mailarchive/forum.php?thread_name=E1KOy9Z-0006Iy-1x%40sc8-pr-cvs8.sourceforge.netforum_name=sbcl-commits

The following patch resolves the issue for me on x86 but I haven't
tested it on amd64.

Index: vm.lisp
===
RCS file: /cvsroot/sbcl/sbcl/src/compiler/x86/vm.lisp,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -d -r1.28 -r1.29
--- src/compiler/x86/vm.lisp12 Apr 2007 14:55:07 -  1.28
+++ src/compiler/x86/vm.lisp1 Aug 2008 17:10:23 -   1.29
@@ -384,7 +384,7 @@
 (!def-vm-support-routine immediate-constant-sc (value)
   (typecase value
 ((or (integer #.sb!xc:most-negative-fixnum #.sb!xc:most-positive-fixnum)
- #-sb-xc-host system-area-pointer character)
+ character)
  (sc-number-or-lose 'immediate))
 (symbol
  (when (static-symbol-p value)

Index: vm.lisp
===
RCS file: /cvsroot/sbcl/sbcl/src/compiler/x86-64/vm.lisp,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -d -r1.9 -r1.10
--- src/compiler/x86-64/vm.lisp 10 Apr 2007 01:20:25 -  1.9
+++ src/compiler/x86-64/vm.lisp 1 Aug 2008 17:10:23 -   1.10
@@ -428,7 +428,7 @@
 (!def-vm-support-routine immediate-constant-sc (value)
   (typecase value
 ((or (integer #.sb!xc:most-negative-fixnum #.sb!xc:most-positive-fixnum)
- #-sb-xc-host system-area-pointer character)
+ character)
  (sc-number-or-lose 'immediate))
 (symbol
  (when (static-symbol-p value)




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#503255: sbcl: Error using null pointer in ffi

2008-10-23 Thread David Matthew Mattli 
Package: sbcl
Version: 1:1.0.18.0-1
Severity: important

Whenever uses sbcl uses a null pointer in a cffi call it gives the following 
error:

#.(SB-SYS:INT-SAP #X) fell through ETYPECASE expression.
   Wanted one of (CHARACTER SYMBOL INTEGER). 

This problem was not present in sbcl-1.0.17 and is fixed in 1.0.19.14. 
Updating sbcl to the latest version will fix this bug. This bug was reported 
and a fix reported on the sbcl-devel list.

http://groups.google.com/group/sbcl-devel/browse_thread/thread/b67a3e18bb7a7dea


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages sbcl depends on:
ii  common-lisp-controller6.17   Common Lisp source and compiler ma
ii  libc6 2.7-15 GNU C Library: Shared libraries

Versions of packages sbcl recommends:
ii  binfmt-support1.2.11 Support for extra binary formats

Versions of packages sbcl suggests:
pn  sbcl-docnone   (no description available)
ii  sbcl-source 1:1.0.18.0-1 Source code files for SBCL
pn  slime   none   (no description available)

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]