Mail Archives: djgpp-workers/2001/06/28/12:33:45
On Wed, 27 Jun 2001, Eli Zaretskii wrote:
> > Date: Wed, 27 Jun 2001 09:27:24 +0300 (WET)
> > From: Andris Pavenis <pavenis AT lanet DOT lv>
> >
> > 1) incompatible files with identical names simultanously visible to
> > compiler. Examples:
> >
> > specs from djdev201.zip and one from gcc-2.8.1 in
> > lib/gcc-lib/djgpp/2.81
> >
> > djgpp.djl from djdev20[12].zip and one from gcc-2.8.1
> > (we needed that to get C++ exceptions working)
>
> So you are saying that the different name also required to change
> specs to use that new name? That is, if someone replaces their specs
> file, they will lose the linker script as well?
specs file commes with GCC version. If one should use modified one
after upgrading GCC, he/she should modify one from upgraded GCC.
Anyway modifying specs is not for novice users, and is not needed
for most
>
> > If I'm wrong then where exactly?
>
> Having multiple files whose precedence rules are subtle is _the_
> problem I'd like to avoid. It doesn't matter much that the names are
> identical or not; what matters is that there are several incompatible
> files for the same purpose.
>
> Since the linker script needs to match both the compiler and the
> linker (and also the library), we might have a situation in the
> future, perhaps near future, that a new Binutils release will need to
> modify the linker script, say, to prevent the linker from crashing at
> link time, or to prevent programs from crashing at run time. If we
> have more than one linker script lurking on users' platforms, we will
> have a much harder time to get the replacement right than today.
>
> Overwriting files when unzipping a package is indeed unfortunate, but
> at least we keep one file in one, well-defined place. Any reasonable
> user will DTRT when presented by the unzip utility with the time
> stamps of the two files. As for unreasonable ones... they will wind
> up on c.o.m.d. anyway ;-)
My idea for this change was to make error possibility less for such users.
Only those users who mess with specs and djgpp.dlj (and are expected
what they are doing ...) will feel the difference. For others there
will be no user visible changes
> By keeping the linker script in one place, we can more easily fix any
> situations in the future when one of the three consumers of that file
> will require it to be changed.
As I said it's temporary solution and the new linker script in gcc
binary archive is going to be removed some time after binutils will
be fixed.
>
> Once again, the fact that the files' names are identical is not the
> problem: the problem is that there are more than one file, and which
> one will be used depends on factors that most users don't understand,
> and thus will be unable to control without lots of hand-holding.
>
It should work out of box for ordinary users who don't need to
modify specs, linker scripts etc.
I'm currently away and I'm not going to do gcc porting related work
up to about July 10th but I'll continue to read mailing list
Andris
- Raw text -