Re: Re: [UnixOS2] libc

On Tue, 17 Jun 2003, Andreas Buening wrote:

> I'd like to keep the standalone libs like intl and pthreads out of emx.
> Lots of Unix system also have standalone versions of them so it's
> more important to get them working than to integrate them into emx.
> However, the details have to be discussed.

Well, the problem is that pthreads is not really a standalone library,
currently it redefines a couple of file related functions to its own
extended version, which causes some trouble if you are using stuff like
some_class::open. If one tries to clean this up, one ends up with more
dependencies on linking order (i.e. you have to link pthreads library
prior to other libraries defining file I/O functions). 

> How do other systems solve this problem? Do they use an internal
> fseek_64() replacement which is used by default instead of fseek()?

There typically is fseek() (32-bit version) and fseek_64().
If -D_FILE_OFFSET_BITS=64 is given on compilation, fseek() is typically
"somehow" mapped to fseek_64(). And you better avoid mixing the two in
the same binary. (i.e. either compile _everything_ (including every helper
library) with that library, or nothing). Similar to the problems
with single- and multi-threaded libc in EMX. That's why I suggested to
have only the large file enabled version in a new library. It would
eliminate all the problems of unintentionally mixing the two variants.

	Regards,
		Stefan
-- 
Micro$oft is not an answer. It is a question. The answer is 'no'.