[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#618033: texlive-bin-2009: Missing -D_FILE_OFFSET_BITS=64 leads to files not opening (x86 /32bit)



Am 2011-03-13 17:40, schrieb Hilmar Preuße:
> On 13.03.11 Pierre SCHNIZER <p.schnizer@gsi.de> (p.schnizer@gsi.de) wrote:
> 
> Hi Pierre,
> 
> I continue discussing in the bug, please keep it in Cc, when
> answering.
> 
>> --- texlive-bin-2009/debian/rules	2011-03-12 21:23:52.000000000 +0100
>> +++ texlive-bin-2009-modified/debian/rules	2011-03-13 16:49:37.000000000 +0100
>> @@ -18,6 +18,15 @@
>>  ifneq (,$(filter $(DEB_BUILD_ARCH),$(GCC_44_ARCHES)))
>>      export CC=gcc-4.4
>>      export CXX=g++-4.4
>> +else
>> +    # This is a hack here. I used it to rebuild the binaries on x86/32bit and 
>> +    # check that the stat() call would then succeed in 
>> +    # texlive-bin-2009/texk/kpathsea/readable.c
>> +    # I guess that necessity for the flag should be detected by autconf/automake
>> +    # I am not familiar enough with the GNU buildchain to try that
>> +    # Pierre
>> +    export CC=gcc -D_FILE_OFFSET_BITS=64
>> +    export CXX=g++ -D_FILE_OFFSET_BITS=64
>>  endif
>>
>>  ifneq (,$(filter $(DEB_BUILD_ARCH),$(RELAX_ARCHES)))
>>  
> For the records: I asked Pierre, why we should introduce the gcc
> option -D_FILE_OFFSET_BITS=64 only on arches !armel. Here is his
> answer.
> 
> <quote src=Pierre>
> 
> [Hilmar:]
>>
>> 2. Is the option -D_FILE_OFFSET_BITS=64 really only on arches
>> !armel needed or can the option bei introduced in general?
>>
> I have not enough experience to judge that. I guess so, but I also
> guess it would be better to enable AC_SYS_LARGEFILE for
> autoconf/automake.
> 
> The same applies to readdable. It does not need to be patched.
> 
> </quote>
> 
>> --- texlive-bin-2009/texk/kpathsea/readable.c	2009-03-16 16:13:07.000000000 +0100
>> +++ texlive-bin-2009-modified/texk/kpathsea/readable.c	2011-03-13 16:44:41.000000000 +0100
>> @@ -58,9 +58,51 @@
>>  		  !(st & FILE_ATTRIBUTE_DIRECTORY));
>>
> So, this part of the patch can be romoved and the only thing, to be
> done is to use -D_FILE_OFFSET_BITS=64 and/or enable LFS support,
> correct?
Yes the patch can be removed. All what is required is exactly what you say.

Best regards,
	Pierre




Reply to: