Mail Archives: djgpp-workers/1998/12/07/06:27:24
On 7 Dec 98, at 12:17, Eli Zaretskii wrote:
>
> On Mon, 7 Dec 1998, Andris Pavenis wrote:
>
> > I found '#include <sys/version.h>' only in stdio.h and go32.h. I think
> > sys/version.h is best way how to define minor version of DJGPP
> > (and it should be no more done from specs).
>
> Unfortunately, this cannot be done in a way that's 100% bulletproof. For
> example, it is allowed for a program to not include any headers and
> still use library functions. Also, <sys/version.h> didn't exist before
> v2.02, so you cannot use it directly in a program that needs to be
> backwards-compatible.
>
I don't think it's possible to get 100% bulletproof version at all. So we must
decide how far in that direction we want to go.
Unfortunatelly we have used such way as definition of DJGPP_MINOR
in specs. If one needs DJGPP_MINOR then he needs to include
corresponding header file. For example also in Linux there is no tricks
done to get libc version when no header files are included.
> > However I think it would
> > be best to include from more standard header files (for example stdlib.h,
> > stddef.h,...).
>
> IMHO, the more the better.
>
> I still think that a better solution would be to add support for
> environment variables to the syntax of specs, and then have cpp include
> sys/version.h via "-imacros $DJDIR/include/sys/version.h" activated from
> specs.
Unfortunatelly it is not fast solution and will be not backward compatible.
However it may be good to have it in future. I also think similar tricks
should be avoided if possible.
>
> > specs file is thing that belongs to gcc distribution, therefore
> > I think it should be distributed only there.
>
> This is okay, but it means that you will have occasionally to replace
> gccNNNb.zip just because some change in the library requires specs to be
> changed. Like the problem with crtf.o, for example (I understand that
> Robert says it won't make any trouble, but other similar cases might not
> let us get away that easily).
Only way how to totally avoid any problems with something is not to touch
it at all. I don't think we may have serious libc.a related compatibility
problems that should force us to change specs (unless we'll change to
ELF or doing some other similar changes)
> > For egcs I'm modifying only those parts of specs I have to modify for
> > DJGPP. Therefore of course specs file is different.
>
> IMHO egcs is less of a problem, since it's an experimental compiler;
> people who install it are expected to tweak their installation a bit.
Currently at least one Linux distribution (Slackware-3.5 and 3.6) comes
with egcs-1.0.3 as default. egcs-1.1.1 also seems stable enough for
normal use.
> I'm much more worried about the mainline compiler installed by clueless
> newbies.
>
> > There should be no problems if crtf.o will be linked (however it is
> > redundant with DJGPP-2.02)
>
> What I fear is that somebody could delete crtf.o (hey, it's redundant,
> right? ;-) and then get linker errors when specs instructs it to look for
> that file.
I think that if somebody is messing with files in $DJDIR/lib/gcc-lib/...
without proper understanding he is playing with fire and can get burned.
(similary as with DJGPP.ENV). But we are NOT able to make things
100% foolproff.
> I also think that the vast difference in the switches set up by two
> versions of specs is not very healthy, to say the least. We don't need
> any more confusion (well, at least *I* don't need it ;-).
As I said I'm going to modify default specs that comes with compiler
only when needed. For example with egcs-1.1.1 one can even delete
specs file and all will work (specs file is identical with builtin specs)
Andris
- Raw text -