Igor Marnat wrote:

I'm building GPC for arm-elf target. In the source directory in files p/rts/configure.in and rts.h options "_LARGEFILE64_SOURCE" and "_FILE_OFFSET_BITS 64" are hardcoded. Is it really necessary? Is it possible to build GPC without large file support as it doesn't make sense for embedded platforms? It doesn't depend of version of GPC sources.

The general idea is to have as few artifical restrictions as possible in Pascal. In C, they need to distinguish between 32 bit and 64 bit routines precisely, because routines are sometimes called without prototypes etc.

In Pascal, we can assume that type sizes are always converted automatically when necessary, so we can (and should IMHO) provide the least restrictive implementation. I.e., if the system allows for 64 bit files, we should simply use them, without any additional requirements on the user.

To put the question the other way around, if it doesn't make sense to use large files on these platforms and causes problems (does it?), then why don't the system headers simply ignore it?

Frank

Igor Marnat wrote:

...

...

I'm building GPC for arm-elf target. In the source directory in files p/rts/configure.in and rts.h options "_LARGEFILE64_SOURCE" and "_FILE_OFFSET_BITS 64" are hardcoded. Is it really necessary? Is it possible to build GPC without large file support as it doesn't make sense for embedded platforms? It doesn't depend of version of GPC sources.

FH> To put the question the other way around, if it doesn't make sense FH> to use large files on these platforms and causes problems (does FH> it?), then why don't the system headers simply ignore it?

I don't know exactly, perhaps I'm doing something wrong, but I have the problems here. I'm truing to build GPC (of 20030830 version) with gcc of 3.3.1 version for arm-elf target. This GCC uses uClibc instead of glibc, and there is file features.h included in uClibc. It is included, for example, from stdlib.h, which is in turn included from conftest.h from p/rts/configure script. I've configured and built uClibc without large file support. So, when conftest.h declares

#define _LARGEFILE64_SOURCE #define _FILE_OFFSET_BITS 64

system runs into the following strings in features.h:

/* Make sure users large file options agree with uClibc's configuration. */ #ifndef __UCLIBC_HAS_LFS__

/* If uClibc was built without large file support, output an error if

• and 64-bit file offsets were requested, output an error.
• NOTE: This is probably incorrect on a 64-bit arch... */

#ifdef __USE_FILE_OFFSET64 #error It appears you have defined _FILE_OFFSET_BITS=64. Unfortunately, \ uClibc was built without large file support enabled. #endif

More C sillyness IMHO. Do you know of any conditionals we could use to check for uClibc (or more generally, to find out if _FILE_OFFSET_BITS=64 will work)? If so, we might be able to do something like this:

#include <foo>

#if <blah> #define _LARGEFILE64_SOURCE #define _FILE_OFFSET_BITS 64 #endif

#include <actual headers>

...

Frank

Dixitur illum marny@rambler.ru scribere...

As far as I know, there are two main C libraries at the moment: glibc for usual platforms and uClibc for embedded platforms. Both of them contain

DietLibc (from Fefe) for some Linux systems, and one different BSD libc for each of the BSDs.

The BSD libcs all do not need the largefile definition to have largefile support - it's always in (so do NOT think you can disable it, just in case...).

//Thorsten

Igor Marnat wrote:

Hello Frank! Thank you for your answer, sorry for delay, I was out of the city.

FH> More C sillyness IMHO. Do you know of any conditionals we could use FH> to check for uClibc (or more generally, to find out if FH> _FILE_OFFSET_BITS=64 will work)? If so, we might be able to do FH> something like this:

FH> #include <foo>

FH> #if <blah> FH> #define _LARGEFILE64_SOURCE FH> #define _FILE_OFFSET_BITS 64 FH> #endif

FH> #include <actual headers>

As far as I know, there are two main C libraries at the moment: glibc for usual platforms and uClibc for embedded platforms. Both of them contain file <source_dir>/include/features.h. In uClibc there is macro __UCLIBC__ defined in this file. It is possible to turn off large file support in uClibc, whereas in glibc it is always on (if GNU_SOURCE is defined). Anyway, in uClibc sources in file include/features.h there are two macros: __UCLIBC__ allows to determine if uClibc is in use, and __UCLIBC_HAS_LFS__ allows to determine if large file support is turned on. Is it possible to take them in consideration to make GPC more suitable for embedded platforms?

So you might want to try adding an autoconf check for <features.h>, and changing rts/rts.h to something like:

#ifdef HAVE_FEATURES_H #include <features.h> #endif

#if !defined (__UCLIBC__) || defined (__UCLIBC_HAS_LFS__) [ ... _LARGEFILE64_SOURCE etc. defines ... ] #endif

If this works, send me a patch so I can integrate it.

However, I generally don't like system-specific code (as opposed to feature-specific code). So if you find any macros with more general names, I'd strongly prefer them instead.

Igor Marnat wrote:

Anyway, if exist C libraries where large-file-support may be turned off then GPC should consider such possibility, otherwise it will restrict library usage.

Ideally, we should cater for all of them with generic (combinations of) macros, if anyone knows such a thing ...

Frank

Igor Marnat wrote:

Hello Frank,

FH> So you might want to try adding an autoconf check for <features.h>, FH> and changing rts/rts.h to something like:

FH> #ifdef HAVE_FEATURES_H FH> #include <features.h> FH> #endif

FH> #if !defined (__UCLIBC__) || defined (__UCLIBC_HAS_LFS__) FH> [ ... _LARGEFILE64_SOURCE etc. defines ... ] FH> #endif

FH> If this works, send me a patch so I can integrate it.

FH> However, I generally don't like system-specific code (as opposed to FH> feature-specific code). So if you find any macros with more general FH> names, I'd strongly prefer them instead.

So am I. Why don't you want just remove these definitions about [ ... _LARGEFILE64_SOURCE etc. defines ... ]?

Because the library (glibc at least) then uses 32 bit file routines which we don't want (by default) as the limitation is becoming more and more practically relevant.

I think it's a problem of C library, when you include any C headers, they automagically includes in turn system includes and C library inlcudes where system's and librariy's configuration definitions lies. Why should you include just these two system defines here and leave all others on their places?

This is not library configuration (i.e., at library build time), but rather library usage (i.e., program compile time) defines. AFAIUI, the intended usage is for programs (or other libraries, as in our case) to define them (before including system headers) if wanted.

glibc provides both 32 and 64 bit routines, and these variables let a program choose between them.

Frank