Mail Archives: djgpp-workers/2000/07/22/05:10:09
> Date: Fri, 21 Jul 2000 19:49:18 +0100 (GMT)
> From: Mo McKinlay <mmckinlay AT gnu DOT org>
>
> It seems to me that the DJGPP group are going about this back-to-front -
> trying to figure out how to change gcc in order to work with the
> libc. Because of gcc's nature, it seems to me that this approach is almost
> doomed to fail from the start.
Sorry, I don't follow: what led you to this conclusion? Perhaps you
could elaborate a bit more. Specifically, why is this approach
back-to-front, and what is it in GCC's nature which goes against this
approach?
> It's inevitable that a new release of the DJGPP libc will come about at
> the same time that DJGPP's gcc is integrated with the main tree - trying
> to prevent would be foolhardy, I think.
This, too, is a conclusion which evades me. For the past few years,
the releases of DJGPP library and of the ported GCC were perfectly
unsynchronized. I don't see why it should be different with the next
GCC release.
(It's not that we are actively preventing synchronization between GCC
and DJGPP; it's just that the resources and free time of people who
work on both these projects happen to be different.)
> - Take a sample platform/libc. I'll cite glibc 2.1 on i686-pc-linux-gnu
> for this, as it's the platform I know best.
>
> - Examine the headers the libc installs/uses. Knowing both glibc and
> DJGPP's libc *reasonably* well, it should be reasonably trivial to
> spot glaring differences in how things are handled (i.e., placement
> of definitions, what things like NULL are defined to, what definitions
> are wrapped with).
I don't think this approach is practical at this time. DJGPP is a
very old system, and it is presently mostly in maintenance phase. New
features are added, but not at a fast rate, and they never change the
structure of the library in any significant manner: back compatibility
and infrequent releases dictate this. Given the available resources,
I don't believe such a serious change would ever happen.
> - Rework DJGPP's libc's headers to follow these semantics
From what little I know about glibc, following its headers means much
more than changes in headers alone.
> and run a
> testsuite on the libc (I assume you guys *have* a testsuite for the
> libc, right? :)
Yes, we do have a test suite. But no test suite can ever find all the
serious problems. At least ours doesn't, as was proven in the past.
(We have improved the test suite since then, but we are not naive
enough to believe it now covers everything.)
There a difference between running a test suite and building a large
body of industry-strength packages such as all the GNU packages ported
to DJGPP, especially since each DJGPP port typically drags a
Unix-centric package, screaming and kicking, into a DOS/Windows world
which is totally alien to the original code.
> Once that's done, you have a new libc release - one that works both with
> the current DJGPP gcc and with future gcc releases (3.x, 4.x, who knows?),
> and you can start making gcc itself talk GO32/DOS.
GCC already talks to DOS: we have a working port of GCC since 1989,
when DJ Delorie first ported it. We were tracking the GCC development
since then, and I don't think we missed any version (with the
exception of the EGCS vs GCC schism period, when we mostly used GCC
2.8.1). So GCC port is not something that is being born now.
What is different about the next release is that we would like GCC to
be built for DJGPP out of the box, with all the necessary quirks
integrated into the official GCC distribution. Until now, building
GCC for DJGPP required a few custom changes and special scripts that
were not distributed with GCC. For example, the headers that GCC
installs when you say "make install" were ignored--this is the issue
we are trying to figure out in this thread.
- Raw text -