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.

On Wed, Feb 25, 2009 at 10:52:30PM +0000, 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 Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, Feb 25, 2009 at 06:20:50PM -0800, Steve Langasek wrote:
> On Wed, Feb 25, 2009 at 10:52:30PM +0000, 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.

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.


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.

On Thu, Feb 26, 2009 at 10:48:35AM +0000, 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Roger Leigh <rleigh@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org