Date: Fri, 21 Jul 2000 19:49:18 +0100 (GMT) From: Mo McKinlay X-Sender: mmckinlay AT sphere DOT stock DOT ekto DOT org To: Eli Zaretskii 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 Subject: Re: GCC headers and DJGPP port In-Reply-To: <200007211812.OAA11217@indy.delorie.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Please excuse my hurling of this in at this point.. As a developer using both GCC on Solaris, FreeBSD Linux, as well as DJGPP on MS-DOS and Cygwin under Win32, I've been following this thread with interest. 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. 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. I would've thought the best course of action to take would be to: - 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). - Rework DJGPP's libc's headers to follow these semantics, and run a testsuite on the libc (I assume you guys *have* a testsuite for the libc, right? :) At which point, you've sorted your libc headers problem, provided nothing breaks. If it does, figure out why it breaks, and fix it. 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. That still leaves binutils, but I think that's sorted already, isn't it? Again, if I'm out of line, I apologise, but I think it was something worth saying. Of course, feel free to point out if I've missed something glaringly obvious [apologies if I have]. Mo. -- Mo McKinlay Chief Software Architect inter/open Labs mmckinlay (at) gnu.org http://www.gnu.org