Bug#477105: raidutils: doesn't work on 64 bit archs
Do you happen to know if the same -m32 switch can be used on all 64-bit architectures: not just AMD64 but also ALPHA, SPARC, etc.? --Barak. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477105: raidutils: doesn't work on 64 bit archs
On Thu, 2008-05-01 at 08:16 +0100, Barak A. Pearlmutter wrote: Do you happen to know if the same -m32 switch can be used on all 64-bit architectures: not just AMD64 but also ALPHA, SPARC, etc.? Hmm no, I wouldn't know, really. Does Alpha have a 32 bit mode anyway ? I know sparc does. Let's see .. what 64 bit archs do we have: ** ALPHA Linux escher 2.6.18-6-alpha-smp #1 SMP Mon Feb 11 10:15:54 UTC 2008 alpha [EMAIL PROTECTED]:~$ vi hello.c [EMAIL PROTECTED]:~$ cc -Wall -o hello64 hello.c [EMAIL PROTECTED]:~$ cc -Wall -m32 -o hello32 hello.c cc1: error: unrecognized command line option -m32 ** HPPA Can't test it, no public developer machine available. ** SPARC Can't test it, no public developer machine available. However this appears to be a 32 bit distribution with extra 64 bit support. I think packages are built in 32 bit mode by default ? ** IA64 [EMAIL PROTECTED]:~$ cc -Wall -o hello64 hello.c [EMAIL PROTECTED]:~$ cc -Wall -m32 -o hello32 hello.c cc1: error: unrecognized command line option -m32 ** AMD64 We know this works. As far as I can check, only amd64 has support for compiling and running 32-bit programs on a 64-bit platform. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477105: raidutils: doesn't work on 64 bit archs
Hmm, seems like there ought to be a way to AUTOMATE this determination. Anyway, my plan is to simply blacklist all suspect 64-bit architectures. --Barak. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477105: raidutils: doesn't work on 64 bit archs
On Mon, 2008-04-21 at 01:22 +0100, Barak A. Pearlmutter wrote: Thanks for the patch. I will dupload it shortly. In addition, the patch makes sure that the raidutils package is built for just i386 and amd64 - it supports only the Adaptec DPT ZCR controllers, which can only be found on x86 boards as far as I know. I'd imagine the Adaptec PCI cards would work on any system with a PCI bus. Well, I was thinking about the ZCR cards which are the Zero Channel Raid cards. It means that the motherboard has an Adaptec SCSI controller on board, and there is an extra slot in which you can put the 2000/2005/2010/2015 ZCR controller. These boards are typically x86 boards. There might exist stand-alone PCI cards that you can put into any system with a PCI bus, you're right about that. Didn't think of that. There is some SPARC-specific stuff in the sources, which I assume is because that configuration actually exists. Good point. Perhaps it would make more sense to just disallow some specific non-amd64 64-bit architectures. You seem to know more about this i2o 64-bit cleanliness issue than me: what do you think? I think I was just being short-sighted by assuming all the dpt_i2o cards are of the ZCR variety and that only x86 boards use them. That doesn't have to be true as you pointed out, so if dpt_raidutils builds on all architectures I do not see a reason not to support that. Oh, the i2o 64-bit cleanliness, how do I know about that.. well, I've tried to fix the raidutils code before to actually work in 64-bit mode, and it would be a lot, really a LOT of work. It assumes pointers == long == 32 bits everywhere. Not only that, but the ioctl interface in the kernel also assumes that, so you'd have to put all data buffers for the ioctls in memory 4G (mmap(MAP_32BIT) ?). I've used the 32 bit package on 64 bit systems for a while now, and recently I found out that it finally is possible to compile 32-bit C++ code in a 64 bit environment .. hence this bugreport. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477105: raidutils: doesn't work on 64 bit archs
Package: raidutils
Version: 0.0.6
Severity: important
Tags: patch
The raidutils package builds on most or all current debian
architectures, but it doesn't work on any 64 bit arch.
This is because the ioctl() interface of the i2o layer in the
kernel isn't 64 bit clean. Neither is the code in raidutils.
Fortunately though, the kernel 32 bit compatibility
layer does work. So, if you run a 32-bit i2o management app
on a 64-bit kernel, it works just fine.
The patch below builds the raidutils on amd64 in 32-bit mode,
so that it actually works. It does give some build warnings
which probably should be looked at - but it works.
In addition, the patch makes sure that the raidutils package
is built for just i386 and amd64 - it supports only the Adaptec
DPT ZCR controllers, which can only be found on x86 boards
as far as I know.
I'm not sure if the severity of this report should be important
or grave. In my case, not having a working management app means
not being able to monitor the raid status, which could result
in data loss, so 'grave' might be appropriate. I've left it
as 'important' for now.
#
diff -ruN t/raidutils-0.0.6/debian/control raidutils-0.0.6/debian/control
--- t/raidutils-0.0.6/debian/control2008-04-21 00:56:34.0 +0200
+++ raidutils-0.0.6/debian/control 2008-04-21 01:20:58.0 +0200
@@ -2,12 +2,12 @@
Section: admin
Priority: optional
Maintainer: Barak A. Pearlmutter [EMAIL PROTECTED]
-Build-Depends: debhelper (= 5), autoconf (= 2.58), linux-kernel-headers
+Build-Depends: debhelper (= 5), autoconf (= 2.58), linux-kernel-headers,
libc6-dev-i386 [amd64], g++-multilib [amd64]
Standards-Version: 3.7.3
Homepage: http://i2o.shadowconnect.com
Package: dpt-i2o-raidutils
-Architecture: any
+Architecture: i386, amd64
Conflicts: raidutils ( 0.0.6-6)
Depends: ${shlibs:Depends}, ${misc:Depends}
Provides: dtp-i2o-raidutils
@@ -21,7 +21,7 @@
array, activate/silence the alarm, and query array/disk status.
Package: raidutils
-Architecture: any
+Architecture: i386, amd64
Depends: dpt-i2o-raidutils
Description: Transition Package for raidutils rename to dpt-i2o-raidutils
The package previously named raidutils, used for manipulating some
diff -ruN t/raidutils-0.0.6/debian/rules raidutils-0.0.6/debian/rules
--- t/raidutils-0.0.6/debian/rules 2008-04-21 00:56:34.0 +0200
+++ raidutils-0.0.6/debian/rules2008-04-21 01:24:07.0 +0200
@@ -11,9 +11,16 @@
# from having to guess our platform (since we know it already)
DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
-
+DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
CFLAGS = -Wall -g
+CXXFLAGS = -Wall -g
+
+# When building on amd64, build 32 bit binaries.
+ifeq (amd64,$(DEB_BUILD_ARCH))
+CFLAGS += -m32
+CXXFLAGS += -m32
+endif
ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
@@ -27,7 +34,7 @@
config.status: configure
dh_testdir
# Add here commands to configure the package.
- CFLAGS=$(CFLAGS) ./configure --host=$(DEB_HOST_GNU_TYPE)
--build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man
--infodir=\$${prefix}/share/info
+ CFLAGS=$(CFLAGS) CXXFLAGS=$(CXXFLAGS) ./configure
--host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
build: build-stamp
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477105: raidutils: doesn't work on 64 bit archs
Thanks for the patch. I will dupload it shortly. In addition, the patch makes sure that the raidutils package is built for just i386 and amd64 - it supports only the Adaptec DPT ZCR controllers, which can only be found on x86 boards as far as I know. I'd imagine the Adaptec PCI cards would work on any system with a PCI bus. There is some SPARC-specific stuff in the sources, which I assume is because that configuration actually exists. Perhaps it would make more sense to just disallow some specific non-amd64 64-bit architectures. You seem to know more about this i2o 64-bit cleanliness issue than me: what do you think? --Barak. -- Barak A. Pearlmutter Hamilton Institute Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www.bcl.hamilton.ie/~barak/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
