Message-ID:	<34C3CFFE.F72F7C7@gmx.net>
Date:	Mon, 19 Jan 1998 23:13:18 +0100
From:	Robert Hoehne <robert DOT hoehne AT gmx DOT net>
Organization:	none provided
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	gcc 2.8.0

I have done now a gcc 2.8.0 port for DJGPP after making
some minor patches.
It is at least stable enough to recompile gcc 2.8.0
with itself and some test programs.
(BTW: the hardest part was to build ligcc.a, but
after some tricks it worked now).

I have also already a first gcc280s.zip (about 5.2 MB)
(in the common distribution format) and making the bin
zip wouldn't be so hard.

My questions are now the following:

- Is there some interest for it? :-)

- Should we test the port first before makeing a
  public release? (I would prefer it)

- Where to upload it for testing? (I would prefer a
  similar solution like the v2/.alphas directory)

- Is it OK, to have the binaries configured (which
  needs mostly changes to djgpp.env) to search the
  executables in a more unix-like way in
  
  %DJDIR%/lib/gcc-lib/i386-pc-msdosdjgpp/2.80/

  (by setting GCC_EXEC_PREFIX)

  This would help also to have more than one gcc installed
  without conflicting them.

  I would prefer this technique, but how to include the changes
  for djggp.env in the gcc280b.zip? In the readme? Knowing
  that there are people which cannot read them?

- Should the stabs debugging format be the default? (Which
  I would prefer). The only problems I see here are

  * GDB 4.16 cannot use exe's with mixed debugging information
    (the next version has not this bug)

  * FSDB and edebug32 cannot read the stabs debugging information

  * symify cannot be used, but for this I have written already
    a program "gsymify" (the name can be changed of course) which
    is based on the BFD library an can read both debugging information
    formats.

- Should the binaries be built with the DJGPP alpha release
  or with the original 2.01 version?

- Should the gcc280b.zip include also a specs file? This could
  contain also a modified link spec, which makes the stubify
  program obsolete. Example:

*link_command:
%{!c:%{!M:%{!MM:%{!E:%{!S:ld %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n}
\
        %{r} %{s} %{t} %{u*} %{x} %{z}\
        %{!A:%{!nostartfiles:%{!nostdlib:%S}}} %{static:}\
        %{L*} %D %{T*} %o -X\
        %{!raw-coff:--oformat coff-go32-exe --force-exe-suffix}\
        %{raw-coff:--oformat coff-go32}\
        %{!nostdlib:-( %L %G -) %{!A:%E}}}}}}}

*lib:
-lc

*libgcc:
-lgcc



  With this spec, there is produced as default the output name and the
  outputname with the .exe suffix (if this was specified already, of
course
  only one file is produced) but both files are the same (a simple copy
  by ld.exe when seeing the --force-exe-suffix). If the user wants
really
  the raw coff image, he has to use the -raw-coff switch like

    gcc -o foo foo.o -raw-coff

  This will work OK with ld 2.8.1 but I don't know if it will work
  also with ld 2.7 (I haven't it anymore, maybe someone can test it,
  at least the --force-exe-suffix is unknown to it AFAIK)

- Does it make sense to distribute gcc 2.8.0 (including
  of course gpp280 objc280) without libg++ 2.8.0?
  (making the libg++ 2.8.0 port is much harder, as an
  example see my other mail in this list)

- Is someone else working on the ports?

There are still some other questions, but I think it's
enough for today.

Robert
-- 
******************************************************
* email:   Robert Hoehne <robert DOT hoehne AT gmx DOT net>     *
* Post:    Am Berg 3, D-09573 Dittmannsdorf, Germany *
* WWW:     http://www.tu-chemnitz.de/~sho/rho        *
******************************************************

- Raw text -