Bug#889147: abyss: PairedDBG_LoadAlgorithm test fails on sparc64 due to strict alignment violation
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(&seq + 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(&seq); memcpy(d, src, sizeof seq); @@ -235,9 +236,10 @@ #if MAX_KMER > 96 # if WORDS_BIGENDIAN const size_t *s = reinterpret_cast(&seq); - 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, &seq, Kmer::NUM_BYTES);
Bug#835973: openjdk-8: please enable hotspot for sparc64
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
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&arch=sparc64&ver=2.4.9.1%2Bdfsg-1.2&stamp=\
\
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
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
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
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
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&arch=sparc64&ver=2.10.3%2Bdfsg1-1&stamp=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
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&arch=sparc64&ver=24.5%2B1-5&stamp=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
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&arch=i386&ver=24.5%2B1-4&stamp=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
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&arch=sparc64&ver=3.2.1%2Bdfsg-1&stamp=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
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&arch=sparc64&ver=7u85-2.6.1-1&stamp=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(&newthr->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#805072: protobuf: FTBFS on sparc64 - apparently tries to build x86 code
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#805211: libffado: FTBFS: error: function ‘int* __errno_location()’ is initialized like a variable
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], &tail, 0 ); int fb_id = strtol( argv[2], &tail, 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], &tail, 0 ); int node_id = strtol( argv[2], &tail, 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], &tail, 0 ); int fb_id = strtol( argv[2], &tail, 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], &tail, 0 ); int fb_id = strtol( argv[2], &tail, 0 );
Bug#789180: linux: Register corruption bug on sparc, please enable SLUB as workaround
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
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=qgis&arch=powerpc&ver=1.7.4%2B1.7.5~20120320-1.1&stamp=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
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
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.net&forum_name=sbcl-commits And here for amd64: http://sourceforge.net/mailarchive/forum.php?thread_name=E1KOy9Z-0006Iy-1x%40sc8-pr-cvs8.sourceforge.net&forum_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
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-doc (no description available) ii sbcl-source 1:1.0.18.0-1 Source code files for SBCL pn slime (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
