Re: Re: [UnixOS2] libc
Ilya Zakharevich <[email protected]> Mon, 23 Jun 2003 03:04:18 -0700
| Newsgroups | gmane.comp.ide.emx.devel |
|---|---|
| Message-ID | <[email protected]> |
On Sun, Jun 22, 2003 at 06:05:18PM +0200, Stefan Neis wrote: > > I don't know why EMX needs C++ internally. > > It doesn't. But if you want to be able to use C++, that needs some support > deep in the internals of EMX. Could you elaborate on this? > > speak for the majority of the people on these mailing lists if I say > > that emx (or whatever its future name will be) must be able to compile > > classical OS/2 programs _as_ _well_ _as_ ports of Unix software. > > Breaking that behaviour wasn't at all the point (at least not _my_ point). > I rather think of stuff like fread/fopen/fwrite/fseek silently supporting > large files. This _is_ incompatible with existing applications No, it is not. At least not with most of them, who do not do any seek. > Meanwhile I do believe that this doesn't necessarily mean breaking binary > compatibility. Whoever thinks that it is important enough should be able > to take existing implementations, rename them to > fread32/fopen32/fwrite32/fseek32 and assign the "right" ordinals to those > and everything should work fine, if I understand the concept correctly. The situation is not that simple. Your forgot about linking with old libraries. Again, one needs to consider both linking with DLLs, and linking with static libraries. When you take all the ramifications into account, you will see that one can't just re-ordinal the entry points; one needs both modes. Thus -DEMX_LARGE_FILES and -DEMX_NO_LARGE_FILES (whichever is the default is not very relevant, with GCCOPT supported). Hope this helps, Ilya