Mail Archives: djgpp/1998/09/27/09:38:16
On 27 Sep 98 at 12:45, Eli Zaretskii wrote:
> On Wed, 23 Sep 1998, George Foot wrote:
>
> > It would be nice to fix the specs so that it is safer to use
> > RSXNT in the way it's meant to be used, i.e. as an addon that
> > is only activated when you pass `-Zwin32' to gcc.
>
> Please submit the necessary changes to lib/specs for v2.02. If the
> RSX-related entries are orthogonal and don't trigger error messages on
> systems which don't have RSXNT installed, I see no reason to not
> include these additions. Replacing DJGPP.ENV and/or specs by an
> installation procedure is by far more dangerous, IMHO.
Will do, when we sort out what to do about this...
> > %{Zwin32: \
> > %{!Zdll: c:/djgpp/rsx2/rsxntdj/lib/crt0w32.o} \
> > %{Zdll: c:/djgpp/rsx2/rsxntdj/lib/dll0w32.o} \
> > %{Zsysv-signals: c:/djgpp/rsx2/rsxntdj/lib/sigsysv%O} \
> > %{Zbsd-signals: c:/djgpp/rsx2/rsxntdj/lib/sigbsd%O} \
> > %{Zbin-files: c:/djgpp/rsx2/rsxntdj/lib/binmode%O} \
>
> I think it's a bad idea to include absolute path names here. Why
> isn't it possible to lump these files into DJGPP's lib directory and
> then have specs call them by their basenames?
I agree that it's bad to specify the full paths, but I also
don't much like the idea of mixing up all the libraries. DOS
libraries will be compiled to work with djgpp's libc, while
Windows libraries will be compiled to work with the EMX libc.
Things like changes in struct offsets could cause runtime
crashes or just misbehaviour if people link DOS libraries into
Windows programs.
Putting all the files into the `lib' directory of a copy of
djgpp was what my first instinct was. It worked fine, but you
had to use one copy of djgpp for DOS programming and one for
Windows. This system was meant to let you use the same copy of
djgpp for both, without risking linking the wrong libraries.
> Or have DJGPP.ENV add
> an RSX-specific directory to LIBRARY_PATH and put these files
> there?
That's the way the normal RSXNTDJ installation works. It has
the same problem though.
If people think I'm just being paranoid about linking in
incompatible libraries then we can do the modification to
djgpp.env. The problem will still exist though because the
linker needs to know which version of libc.a to use, and the
preprocessor needs to know which include files to use. If both
sets are specified in the same include path and library path
then only one of the sets can be used.
It's a shame you can't use relative paths in the specs, or use
environment variables. (Or can you?)
--
george DOT foot AT merton DOT oxford DOT ac DOT uk
- Raw text -