Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!jarthur!elroy.jpl.nasa.gov!ncar!gatech!udel!mmdf
From: HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen)
Newsgroups: comp.os.minix
Subject: Unified MINIX GNU port
Message-ID: <43079@nigel.ee.udel.edu>
Date: 29 Jan 91 16:03:35 GMT
Sender: mmdf@ee.udel.edu
Lines: 35

Recently there was a posting which stated the need for a unified GNU
port.
The extensive hacking on GNU which was done in the past is obsolete now
because
- MINIX 1.5 has removed some deficiencies of MINIX 1.1
- The GNU version which was taken is replaced by a newer version.

Personally, I am most interested in GNU as, ar, ld, cpp to make a
compiling system together with c68/c386 (GNU cc is much too large for me).
The main problem for me are the incompatible format of the system binaries,
this has resulted in an extensive hack to ld once.

My question, would it be tolerable to use the originial GNU a.out format and
design a conversion program that converts GNU binaries to MINIX binaries
(yes I hear you crying: ''we have just overcome that odd cv program'') --
in a later step, it might be possible to modify MM such that it can load
GNU binaries [ I know that the GEM reloaction info is more dense than
the reloc info produced with ld -r ].

This would free us from the need to hack every new version of GNU ld as it
comes along. I would personlly prefer to make as few changes as possible.

I will look if the bug in m68k.md which I reported to R. Stallman is removed
in gcc 1.39. If so, I will post a 20-line patch which makes sizeof()
yielding a 16-bit int in -mshort mode (I think this is the main reason why
GCC does not work with all MINIX-1.5 sources, at least in fdopen(), there is



..... = malloc(sizeof(...));

which does not work with an un-modified gcc since size_t is
long or unsigned long (depending on flag_traditional) there.

C.v.W.