Mail Archives: djgpp-workers/1998/01/21/08:41:11
On Mon, 19 Jan 1998, Robert Hoehne wrote:
> - Should we test the port first before makeing a
> public release? (I would prefer it)
I think it's a good idea to test it first, but I suggest to make the
test period minimal. If several widely-used programs compiled with
this port run without crashing, this is IMHO evidence hard enough to
release it officially. Testing the port by a large number of users is
in itself an important goal, and it cannot be achieved with alpha
releases.
> - Where to upload it for testing? (I would prefer a
> similar solution like the v2/.alphas directory)
It can go into v2/.alphas, but please keep in mind that some SimTel
mirrors don't mirror that directory properly (I've seen one that keeps
it empty at all times and another that says ``access denied'' when you
try to chdir there). This is yet another reason to go official as
quickly as possible.
> %DJDIR%/lib/gcc-lib/i386-pc-msdosdjgpp/2.80/
>
> (by setting GCC_EXEC_PREFIX)
I suggest adding a small amount of code to gcc so that it would expand
$DJDIR and then append "/lib/gcc-lib/i386-pc-msdosdjgpp/VERSION/" (and
the rest of directories, like include) to it automatically. This is
the equivalent of the Unix built-in path names, only ours depends on a
single environment variable. Let DJGPP.ENV and the environment be the
vehicles for *overriding* the default, not for setting it.
> - Should the stabs debugging format be the default?
I suggest to leave COFF be the default, at least for now. IMHO, core
DJGPP tools are not yet ready to switch to stabs as the default format
(you have listed some of the problems yourself). It would especially
hurt newbies which will probably jump on the opportunity to download
2.8.0 because they cannot seem to live without exceptions and other
hot stuff like that.
> - Should the binaries be built with the DJGPP alpha release
> or with the original 2.01 version?
I suggest not to bring v2.02 into this equation yet, at least not
before it gets into beta. As far as I understand, alpha releases are
not meant to be used in production. Linking gcc with the patched
library from Tom Demmer's site should take care of most of the known
bugs in v2.01 without risking the new ones from added functionality.
> 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)
I haven't upgraded to Binutils 2.8.1 yet (I need to be able to debug
and fix the binaries which will be on the FSF CD-ROM, on which I am
still working). So it would be nice if compatibility with 2.7 is not
broken too soon.
> - Does it make sense to distribute gcc 2.8.0 (including
> of course gpp280 objc280) without libg++ 2.8.0?
It makes a limited sense. There are programs which are written in C++
but they don't use anything from the libraries. Groff is one case in
point. But most of those who use C++ woul be probably unhappy without
the library.
> (making the libg++ 2.8.0 port is much harder, as an
> example see my other mail in this list)
Are you sure you need to port libg++? In the announcement of gcc
2.8.0 I saw a note saying that libg++ is now deprecated and should
not be used for development, and that libstdc++ is the replacement.
maybe porting libstdc++ is easier?
One thing that I haven't got the time to check is what are the
differences between these two distributions. For starters, libg++ is
*much* larger than libstdc++. I wonder what did they leave out?
> - Is someone else working on the ports?
I do, in my dreams... ;-). Thanks for bringing them closer to
reality.
- Raw text -