Message-Id: <199809281550.LAA13544@indy.delorie.com>
Comments: Authenticated sender is <mert0407 AT sable DOT ox DOT ac DOT uk>
From: "George Foot" <george DOT foot AT merton DOT ox DOT ac DOT uk>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date: Mon, 28 Sep 1998 16:48:11 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: DJGPP and windows?
Reply-to: mert0407 AT sable DOT ox DOT ac DOT uk
CC: djgpp AT delorie DOT com
Precedence: bulk

On 28 Sep 98 at 12:40, Eli Zaretskii wrote:

> On Sun, 27 Sep 1998, George Foot wrote:
> 
> > > > %{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.
> 
> Sorry, I must be missing something: where's the mixup?  All of the
> names above (crt0w32.o, dll0w32.o etc.) don't happen at all in the
> stock DJGPP distribution.  So what's the problem to have them all in
> the same directory with DJGPP's libraries and object files?

The problem isn't with these files, it's with other libraries
such as libc, libm and libg, of which RSXNTDJ provides its own
copies of course.  In addition, I thought it would be better to
prevent people from linking any DOS-djgpp libraries into
Windows programs.  stdcxx would be an easy library to link in
by accident, using gxx.  I'm not sure, but linking DOS
libraries into Windows programs doesn't seem very safe to me.

> > 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.
> 
> Will renaming the libraries that have the same names (if there are
> such) and using lib/specs to force GCC to use the correct ones solve
> this problem?

To some extent; but when people say `-lm' on the command line, 
how can we change this to `-lm_win'?  AFAICS it gets thrown in 
with `%o' and I don't see how we can adjust it after that 
happens.  Perhaps the only option is to require them to type 
`-lm_win' (or whatever we call it).

Do you have any ideas about how to control which include files
get used?  I'm not terribly happy about my solution to this
(which is in that specs file I posted).  It's the only other
place where I needed to put paths in the specs file.  You
should be aware that `rsxntdj/include' contains standard C
include files, like those in djgpp's `include' directory.  I
don't think it's wise to use djgpp's include files with
RSXNTDJ's libraries, or vice versa.

Incidentally, rather than having all these copies of the path 
to RSXNTDJ floating around we could just add a new spec:

    *rsxntdj_path:
    c:/path/to/rsxntdj

Then include it elsewhere in the specs file using 
%(rsxntdj_path).  It doesn't solve the problem (people would 
still need to edit the specs to use RSXNTDJ) but it reduces the 
chance of them breaking anything.

BTW, looking at the changes to `lib/specs' from 2.01 to 2.02 I
think whatever we do to it for RSXNTDJ can't clash with 2.02's
changes.  The only differences are the default target
architechture and alignments, and the minor version number.

-- 
george DOT foot AT merton DOT oxford DOT ac DOT uk