sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
Re: [SM-Discuss] large file support on SMGL, or just generally in libraries
- From: Thomas Orgis <thomas-forum AT orgis.org>
- To: sm-discuss AT lists.ibiblio.org
- Subject: Re: [SM-Discuss] large file support on SMGL, or just generally in libraries
- Date: Sat, 13 Mar 2010 19:28:32 +0100
Am Sat, 13 Mar 2010 10:04:48 -0800
schrieb Eric Sandall <eric AT sandall.us>:
> We generally support what upstream supports. If upstream is broken then
> we'll be broken, but we'll try to fix it if we have time.
>
> Some of our packages do ask if you want 64-bit file support
> (libsndfile, mhwaveedit, dansguardian, sessreg, zsh, nano). If you want
> these queries added to all libraries, please do so (or file bugs), but
> our policy would be to leave the query to what upstream wants (e.g. if
> zlib upstream defaults to 32-bit offsets have the query default to that
> as well).
Hm. I wonder if that point isn't one where some policy is required by the
distribution. When upstream packages provide off_t-clean code that works with
64 bit offsets, that implies that they invested work to support large files.
The default of 32 bit offsets does not come from upstream, it comes from our
build environment.
Perhaps one could introduce a global config setting for users preferring
32bit , 64bit, or, if possible, both types of file offset width in libraries
(possibly building two variants of one lib).
But well, my energy with this is limited. I am using SMGL almost exclusively
on 64bit machines anyway. I mainly want that problem to go away, and hope
that distributions will do theit pick with libmpg123 or libmpg123_64 on their
systems.
It is kindof unnerving that this dual off_t stuff has been considered for a
"transitional period" back in the nineties, but it will stay for as long as
there is linux on 32bit x86, I presume:-/ I hope nowadays standards commitees
realize that "nasty stuff for transitional period" equals nastiness forever.
So, the situation sucks per default, and SMGL is just reflecting that
situation without painting over it. Granted, it indeed not the majority of
upstream software that is prepared to work correctly with large files. So the
situation would suck in any case, until we drop x86. Whatever. There are
other things, that suck, too (like Xorg stability with intel drivers).
Alrighty then,
Thomas.
Attachment:
signature.asc
Description: PGP signature
-
[SM-Discuss] large file support on SMGL, or just generally in libraries,
Thomas Orgis, 03/06/2010
-
Re: [SM-Discuss] large file support on SMGL, or just generally in libraries,
Thomas Orgis, 03/13/2010
-
Re: [SM-Discuss] large file support on SMGL, or just generally in libraries,
Eric Sandall, 03/13/2010
- Re: [SM-Discuss] large file support on SMGL, or just generally in libraries, Thomas Orgis, 03/13/2010
-
Re: [SM-Discuss] large file support on SMGL, or just generally in libraries,
Eric Sandall, 03/13/2010
-
Re: [SM-Discuss] large file support on SMGL, or just generally in libraries,
Thomas Orgis, 03/13/2010
Archive powered by MHonArc 2.6.24.