Re: Should 32-bit apps work with a 64-bit kernel?
Roger Leigh rle...@codelibre.net writes: On Wed, Feb 25, 2009 at 04:16:53PM +0100, Goswin von Brederlow wrote: Maybe we need a mass bug filing for programs not using 64bit file offsets. I think that would be appropriate. At this point, I can't see a valid reason for any package to not have LFS enabled. Anyone up for hacking libc to always fail on the 32bit wrappers for seek, stat, ...? Well, breaking old code might be considered bad. This would break *all* binaries using the old 32-bit ABI. This would just be on special systems where you want to detect bad software by breaking it. Instead of failing the 32-bit calls could also just log arg[0] on the first use. Personally, I would prefer the glibc headers to just set the LFS macros to the 64 bit versions by default, so that rather than taking extra steps to enable LFS, LFS would be the default and you would then need to take extra steps to disable it. i.e. just default _FILE_OFFSET_BITS to 64 rather than 32. If someone really, really, wanted 32 bit file offsets, they could just set it back to 32 again. I would like that too. But that would break all sources that just assume 32bit. Sources that just copy off_t into an int or long, or blksize_t, or any of the others. That is obviously broken but hard to detect. Regards, Roger MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should 32-bit apps work with a 64-bit kernel?
On Thu, Feb 26, 2009 at 10:48:35AM +, Roger Leigh wrote: Agreed. If we can identify all libraries (perhaps with a simple grep over the lintian lab?) containing these types, and make sure LFS is enabled in all of them, it should then be possible to switch once all dependencies are rebuilt. I guess this would need the library packages renaming due to altering the ABI. Some of these libraries provide ABIs which support both LFS and non-LFS versions - we'd also need to check for those and make sure they can handle being built with LFS defined by default. I do worry that we may end up causing compatibility issues here by surprsing people with changed defaults. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should 32-bit apps work with a 64-bit kernel?
Ron Johnson ron.l.john...@cox.net writes:
On 02/09/2009 08:04 AM, Ron Johnson wrote:
On 02/09/2009 12:28 AM, Martin Langhoff wrote:
On Mon, Feb 9, 2009 at 2:19 PM, Ben Hutchings b...@decadent.org.uk
wrote:
If jed can deal with files that large, sure. But if it expects to be
able to load the entire file into memory - as most text editors do -
stat() will be only the first of its problems.
Old vi was able to work with files larger than available RAM. I wonder
if any modern text editor today can still handle that.
I've got a 23GB text file that vim 7.2.079-1 just won't see.
more(1) processes it, file(1) processes it, but vim displays an
empty screen with [New File] at the bottom.
Bug #514617.
stat64(ACCOUNT_TOLL_V20_200408.UNL, {st_mode=S_IFREG|0640,
st_size=23726916643, ...}) = 0
stat64(ACCOUNT_TOLL_V20_200408.UNL, {st_mode=S_IFREG|0640,
st_size=23726916643, ...}) = 0
access(ACCOUNT_TOLL_V20_200408.UNL, W_OK) = 0
open(ACCOUNT_TOLL_V20_200408.UNL, O_RDONLY) = -1 EOVERFLOW (Value
too large for defined data type)
readlink(ACCOUNT_TOLL_V20_200408.UNL, 0xfff19c4c, 4095) = -1
EINVAL (Invalid argument)
Maybe we need a mass bug filing for programs not using 64bit file
offsets.
Anyone up for hacking libc to always fail on the 32bit wrappers for
seek, stat, ...?
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should 32-bit apps work with a 64-bit kernel?
Goswin von Brederlow, le Wed 25 Feb 2009 16:16:53 +0100, a écrit : Anyone up for hacking libc to always fail on the 32bit wrappers for seek, stat, ...? Or looking for binaries with a U lseek ? Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should 32-bit apps work with a 64-bit kernel?
On Wed, Feb 25, 2009 at 04:16:53PM +0100, Goswin von Brederlow wrote: Maybe we need a mass bug filing for programs not using 64bit file offsets. I think that would be appropriate. At this point, I can't see a valid reason for any package to not have LFS enabled. Anyone up for hacking libc to always fail on the 32bit wrappers for seek, stat, ...? Well, breaking old code might be considered bad. This would break *all* binaries using the old 32-bit ABI. Personally, I would prefer the glibc headers to just set the LFS macros to the 64 bit versions by default, so that rather than taking extra steps to enable LFS, LFS would be the default and you would then need to take extra steps to disable it. i.e. just default _FILE_OFFSET_BITS to 64 rather than 32. If someone really, really, wanted 32 bit file offsets, they could just set it back to 32 again. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Should 32-bit apps work with a 64-bit kernel?
On Wed, Feb 25, 2009 at 10:52:30PM +, Roger Leigh wrote: Personally, I would prefer the glibc headers to just set the LFS macros to the 64 bit versions by default, so that rather than taking extra steps to enable LFS, LFS would be the default and you would then need to take extra steps to disable it. i.e. just default _FILE_OFFSET_BITS to 64 rather than 32. If someone really, really, wanted 32 bit file offsets, they could just set it back to 32 again. There are libraries in existence that (unfortunately) expose libc types that are sensitive to _FILE_OFFSET_BITS as part of their ABIs. Making a change like this without first identifying and handling those libraries would cause a mess. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should 32-bit apps work with a 64-bit kernel?
On 02/09/2009 12:28 AM, Martin Langhoff wrote: On Mon, Feb 9, 2009 at 2:19 PM, Ben Hutchings b...@decadent.org.uk wrote: If jed can deal with files that large, sure. But if it expects to be able to load the entire file into memory - as most text editors do - stat() will be only the first of its problems. Old vi was able to work with files larger than available RAM. I wonder if any modern text editor today can still handle that. I've got a 23GB text file that vim 7.2.079-1 just won't see. more(1) processes it, file(1) processes it, but vim displays an empty screen with [New File] at the bottom. -- Ron Johnson, Jr. Jefferson LA USA Supporting World Peace Through Nuclear Pacification -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should 32-bit apps work with a 64-bit kernel?
On 02/09/2009 08:04 AM, Ron Johnson wrote:
On 02/09/2009 12:28 AM, Martin Langhoff wrote:
On Mon, Feb 9, 2009 at 2:19 PM, Ben Hutchings b...@decadent.org.uk
wrote:
If jed can deal with files that large, sure. But if it expects to be
able to load the entire file into memory - as most text editors do -
stat() will be only the first of its problems.
Old vi was able to work with files larger than available RAM. I wonder
if any modern text editor today can still handle that.
I've got a 23GB text file that vim 7.2.079-1 just won't see.
more(1) processes it, file(1) processes it, but vim displays an empty
screen with [New File] at the bottom.
Bug #514617.
stat64(ACCOUNT_TOLL_V20_200408.UNL, {st_mode=S_IFREG|0640,
st_size=23726916643, ...}) = 0
stat64(ACCOUNT_TOLL_V20_200408.UNL, {st_mode=S_IFREG|0640,
st_size=23726916643, ...}) = 0
access(ACCOUNT_TOLL_V20_200408.UNL, W_OK) = 0
open(ACCOUNT_TOLL_V20_200408.UNL, O_RDONLY) = -1 EOVERFLOW (Value
too large for defined data type)
readlink(ACCOUNT_TOLL_V20_200408.UNL, 0xfff19c4c, 4095) = -1
EINVAL (Invalid argument)
--
Ron Johnson, Jr.
Jefferson LA USA
Supporting World Peace Through Nuclear Pacification
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Should 32-bit apps work with a 64-bit kernel?
Hi, I have the bug report #489917 that complains that Jed can't handle 64‐bit kernel structures. In this special case, the stat() return with EOVERFLOW Value too large to be stored in data type. Jed was compiled for a 32‐bit kernel and is run with a 64‐bit kernel. The error can be fixed by compiling Jed with -D_FILE_OFFSET_BITS=64. Should I set this option for all 32‐bit builds or does it have any drawbacks? Bye, Jörg. -- Wer einen Traum verwirklichen will, muss erst aufwachen. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should 32-bit apps work with a 64-bit kernel?
On Sun, Feb 08, 2009 at 10:46:42AM +, Jörg Sommer wrote: I have the bug report #489917 that complains that Jed can't handle 64‐bit kernel structures. (...) The error can be fixed by compiling Jed with -D_FILE_OFFSET_BITS=64. Should I set this option for all 32‐bit builds or does it have any drawbacks? I'd think you should enable it for all 32 bit builds; it is, I think, a step in having support for large files (files bigger than 2 or 4 gigabytes), something we wanted to have for... woody. -- Lionel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should 32-bit apps work with a 64-bit kernel?
hi, On Sun, Feb 08, 2009 at 12:58:43PM +0100, Lionel Elie Mamane wrote: I'd think you should enable it for all 32 bit builds; it is, I think, a step in having support for large files (files bigger than 2 or 4 gigabytes), something we wanted to have for... woody. more specifically, what i think you really want is the output of calling getconf LFS_CFLAGS. i.e. on my old 32-bit laptop it outputs: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 but keep in mind that this (either option i believe) breaks binary compatibility, so if you're packaging a shared library or similar you may have to tread a bit more carefully. BR sean signature.asc Description: Digital signature
Re: Should 32-bit apps work with a 64-bit kernel?
On 02/08/2009 04:46 AM, Jörg Sommer wrote: Hi, I have the bug report #489917 that complains that Jed can't handle 64‐bit kernel structures. In this special case, the stat() return with EOVERFLOW Value too large to be stored in data type. Jed was compiled for a 32‐bit kernel and is run with a 64‐bit kernel. The error can be fixed by compiling Jed with -D_FILE_OFFSET_BITS=64. Should I set this option for all 32‐bit builds or does it have any drawbacks? All of the 32-bit apps that I've had need to install run just fine with a 64-bit kernel. $ uname -m x86_64 $ dpkg-architecture DEB_BUILD_ARCH=i386 DEB_BUILD_ARCH_OS=linux DEB_BUILD_ARCH_CPU=i386 DEB_BUILD_GNU_CPU=i486 DEB_BUILD_GNU_SYSTEM=linux-gnu DEB_BUILD_GNU_TYPE=i486-linux-gnu DEB_HOST_ARCH=i386 DEB_HOST_ARCH_OS=linux DEB_HOST_ARCH_CPU=i386 DEB_HOST_GNU_CPU=i486 DEB_HOST_GNU_SYSTEM=linux-gnu DEB_HOST_GNU_TYPE=i486-linux-gnu -- Ron Johnson, Jr. Jefferson LA USA Supporting World Peace Through Nuclear Pacification -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Should 32-bit apps work with a 64-bit kernel?
On Sun, 2009-02-08 at 10:46 +, Jörg Sommer wrote: Hi, I have the bug report #489917 that complains that Jed can't handle 64‐bit kernel structures. In this special case, the stat() return with EOVERFLOW Value too large to be stored in data type. Jed was compiled for a 32‐bit kernel and is run with a 64‐bit kernel. You can get this error under 32-bit kernels too, because thankfully they can handle 2 GB files. The error can be fixed by compiling Jed with -D_FILE_OFFSET_BITS=64. Should I set this option for all 32‐bit builds or does it have any drawbacks? If jed can deal with files that large, sure. But if it expects to be able to load the entire file into memory - as most text editors do - stat() will be only the first of its problems. Ben. signature.asc Description: This is a digitally signed message part
Re: Should 32-bit apps work with a 64-bit kernel?
On Mon, Feb 9, 2009 at 2:19 PM, Ben Hutchings b...@decadent.org.uk wrote: If jed can deal with files that large, sure. But if it expects to be able to load the entire file into memory - as most text editors do - stat() will be only the first of its problems. Old vi was able to work with files larger than available RAM. I wonder if any modern text editor today can still handle that. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
