Unknown type name ‘off64_t’

问题:

I have a problem using Apache Portable Runtime on Ubuntu with GCC 4.8.1

The problem is that the off64_t from <sys/types.h> is not available when compiling with gcc. (When compiling with g++ everything work fine)

Does anybody know which compiler switch to use to enable off64_t? (I know that defining _LARGEFILE_SOURCE _LARGEFILE64_SOURCE avoids the problem, but wondering if this is the right way)

To reproduce the error one can simply try to compile the following code:

#include <sys/types.h>
off64_t a_variable;

回答1:

off64_t is not a language defined type. No compiler switch will make it available.

It is defined in sys/types.h, but (on a 32 bit system) only if

• _LARGEFILE64_SOURCE is defined
  Which will make the 64 bit interfaces available (off64_t, lseek64(), etc...).
  The 32 bit interfaces will still be available by their original names.

• _FILE_OFFSET_BITS is defined as '64'
  Which will make the names of the (otherwise 32 bit) functions and data types refer to their 64 bit counterparts.
  off_t will be off64_t, lseek() will use lseek64(), and so on...
  The 32 bit interface is no longer available.

Make sure that if you define these macros anywhere in your program, you define them at the beginning of all your source files. You don't want ODR violations to be biting you in the ass.

Note, this is for a 32 bit system, where off_t is normally a 32 bit value.
On a 64 bit system, the interface is already 64 bits wide, you don't need to use these macros to get the large file support.
off_t is a 64 bit type, lseek() expects a 64 bit offset, and so on.
Additionally, the types and functions with 64 in their name aren't defined, there's no point.

See http://linux.die.net/man/7/feature_test_macros
and http://en.wikipedia.org/wiki/Large_file_support

You also may be interested to know that when using g++, _GNU_SOURCE is automatically defined, which (with the gnu c runtime library) leads to _LARGEFILE64_SOURCE being defiend. That is why compiling your test program with g++ makes off64_t visible. I assume APR uses the same logic in making _LARGEFILE64_SOURCE defined.

回答2:

A bit late, but still current. I simply add -Doff64_t=_off64_t to the compiler flags.

回答3:

Redefine off64_t to __off64_t in your compile flag. Edit your Makefile so it contains:

CFLAGS= -Doff64_t=__off64_t

then, just run $ make 1 (assuming you have 1.c in your directory)

回答4:

In my environment gcc version 4.1.2, I need to define __USE_LARGEFILE64. I found this macro from /usr/include/unistd.h who defines lseek64()

#define __USE_LARGEFILE64
#include <sys/types.h>
#include <unistd.h>

回答5:

You should define $C_INCLUDE_PATH to point to linux headers, something like

export C_INCLUDE_PATH=/usr/include/x86_64-linux-gnu

To install linux header, use

sudo apt-get install linux-headers-`uname -r`

P.S.

$ cat 1.c
#include <sys/types.h>
off64_t a_variable;
int main(){return 0;}

$ gcc --version
gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1

$ echo $C_INCLUDE_PATH
/usr/include/x86_64-linux-gnu

$ grep off64_t /usr/include/x86_64-linux-gnu/sys/types.h 
typedef __off64_t off_t;
#if defined __USE_LARGEFILE64 && !defined __off64_t_defined
typedef __off64_t off64_t;
# define __off64_t_defined

回答6:

Sorry for the lateness but I did never had to embed perl code in C programs untill today ^^

I solved the issue in Unix/Linux systems (I think it is possible to create such feature in Windows since Vista) by creating a symbolic link pointing to the CORE folder of perl version...

ln -s $(perl -MConfig -e 'print $Config{archlib}')/CORE /usr/include/perl

In your project file, source code, simply add:

#include <perl/EXTERN.h>
#include <perl/perl.h>

...and I came from long list of notes and errors related to off_t and off64_t to a clean build result ^^

回答7:

Also late to the party, but the main reason for receiving this issue was installing the 64-bit version of MinGW instead of 32-bit:

https://sourceforge.net/projects/mingw/