Date: Sat, 22 Jul 2000 05:09:42 -0400 (EDT) Message-Id: <200007220909.FAA11989@indy.delorie.com> From: Eli Zaretskii To: Mo McKinlay CC: martin AT loewis DOT home DOT cs DOT tu-berlin DOT de, mrs AT windriver DOT com, djgpp-workers AT delorie DOT com, gcc AT gcc DOT gnu DOT org In-reply-to: (message from Mo McKinlay on Fri, 21 Jul 2000 19:49:18 +0100 (GMT)) Subject: Re: GCC headers and DJGPP port References: Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > Date: Fri, 21 Jul 2000 19:49:18 +0100 (GMT) > From: Mo McKinlay > > 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.