Mail Archives: djgpp-workers/2000/07/21/14:48:25
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
- Raw text -