-DLARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 (was: unzip.spec)

Radoslaw Zielinski radek42 at gmail.com
Tue Aug 8 15:53:50 CEST 2006


Jakub Bogusz <qboosh at pld-linux.org> [08-08-2006 11:46]:
> On Tue, Aug 08, 2006 at 11:20:42AM +0200, Radoslaw Zielinski wrote:
>> Szymon Siwek <sls at poczta.wp.pl> [08-08-2006 06:30]:
>> [...]
>>> -	CF="%{rpmcflags} -I. -Wall -DASM_CRC" \
>>> +	CF="%{rpmcflags} -I. -Wall -DASM_CRC -DLARGEFILE_SOURCE  -D_FILE_OFFSET_BITS=64" \
>> What would be the correct way to do this globally in Th?
>> Changing %optflags, or rather some gcc header file?
>> Should we do it?
> No.
> This is per-app thing.
> LFS-ready apps already define proper flags (usually through autoconf
> macro).

Well, unzip doesn't (assuming the patch is correct).

As I understand [1] and [2], it's also a problem of mixing applications
/ libraries compiled in 32 and 64 mode.

> Others should be reviewed individually. Defining anything won't convert
> ints to 64-bit in bad-written code.

But would it hurt to have 64 bit off_t by default?


[1] http://ac-archive.sourceforge.net/largefile/summary.html 404, copy:
    http://web.archive.org/web/*/http://ac-archive.sourceforge.net/largefile/summary.html
[2] http://freshmeat.net/articles/view/709/

-- 
Radosław Zieliński <radek at pld-linux.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /mailman/pipermail/pld-devel-en/attachments/20060808/bc1715bc/attachment.sig 


More information about the pld-devel-en mailing list