Mail Archives: djgpp/1998/09/23/14:28:49
On 23 Sep 98 at 14:06, Eli Zaretskii wrote:
> On Sun, 20 Sep 1998, Doug Gale wrote:
>
> > I have already patched my headers (obviously), and would be willing
> > to zip them up and send them to you pre-patched. (I did have to
> > screw around a bit to get the patch to work).
> [snip]
> > Is anyone out there maintaining rsxntdj? I have a modified specs
> > file with a major fix in the linking part.
>
> Would someone please make an updated rsxntdj distribution and upload
> it to SimTel.NET? At the very least, an additional zip file should be
> available that, when unzipped on top of rsxdj131, will fix up any
> problems that the original package has.
>
> IMHO, it's a pity that several people has succeeded to solve the
> problems, but newbies still cannot easily benefit from these
> solutions (even though they are listed in the FAQ now).
True... I uploaded my version of the installation instructions,
which should be very simple to follow. However, I don't fully
agree with them any more -- some of the things I did weren't
actually necessary, now that I've looked at RSXNTDJ's version
of the specs in more detail.
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. We could in
fact remove all the modifications to djgpp.env and replace them
with entries in the specs -- this would probably be the best
approach. I've already almost done this. The reason I think
it's necessary is that I think mixing libraries compiled with
pure djgpp and libraries compiled with RSXNTDJ could be very
dangerous.
The current installation system modifies djgpp.env to put
RSXNTDJ's library and include paths in before djgpp's own ones.
My modification to RSX's lib/specs makes it almost unnecessary
to change djgpp.env. It abolishes the default include search
paths if `-Zwin32' is specified, and uses RSXNTDJ's instead. I
think this will only work for C compilations though, because
the C++ library include paths won't be present. In any case I
suspect that you shouldn't use djgpp's C++ libraries in
RSXNTDJ, because they might lean on the C library they were
compiled with, i.e. djgpp's own one.
For anyone who is interested, I have copied my updated specs
file at the end of this message. It should replace djgpp's
specs file in djgpp's `lib' directory. You need to copy
RSXNTDJ's linker (rsxntdj/patch/ld.exe) to djgpp's `bin'
directory, renaming it to `rsxntld.exe'.
I wish there was a better way to do some things; maybe there
is and I just don't know it. One thing that's annoying is the
lack of any way to use macros in the specs file -- to work on
new systems it needs a lot of modifications because absolute
paths to the RSXNTDJ files need to be entered.
This specs file incorporates a modified version of Doug Gale's
addition which he posted a few days ago.
Please do say if any of my changes will break something I
haven't thought about. It's important that all the normal
djgpp programs will work using this specs file, otherwise it
defeats the point of having the file.
It's not really simple to change the supplied installation
instructions because they're in MS Windows Help format and
AFAICS we don't have the sources.
I think we should make separate patches against the RSXNTDJ
distribution to solve the various problems, upload them
somewhere for testing, come to some agreement about which to
keep and then upload a patch ZIP to Simtelnet.
Maybe it would be worth compiling a version of the binutils
v2.8.1 linker with the patch supplied with RSXNTDJ. I don't
know whether mixing the binutils is very dangerous, but if it
is then this would probably be a good thing to do.
Everything below this point is the specs file:
*asm:
*asm_final:
*cpp:
%{posix: -D_POSIX_SOURCE} \
%{Zwin32: \
-D__WIN32__ -D__RSXNT__ -D__EMX__ \
-nostdinc \
-Ic:/djgpp/rsx2/rsxntdj/include \
-Ic:/djgpp/rsx2/rsxntdj/include/mssdk \
-Ic:/djgpp/rsx2/rsxntdj/include/win32 \
%{Zmt: -D__MT__} \
%{Zdll: -D__DLL__} \
%{Zcrtdll*: -D__CRTRSXNT__} \
}
*cc1:
*cc1plus:
*endfile:
*link:
%{Zwin32: \
-Lc:/djgpp/rsx2/rsxntdj/lib \
-Lc:/djgpp/rsx2/rsxntdj/lib/all \
%{Zmt: -Lc:/djgpp/rsx2/rsxntdj/lib/mt} \
%{!Zmt: -Lc:/djgpp/rsx2/rsxntdj/lib/st} \
}
*link_command:
%{!c:%{!M:%{!MM:%{!E:%{!S: \
%{!Zwin32: ld} %{Zwin32: rsxntld} \
%l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r} %{s} %{t} %{u*} %{x} %{z} \
%{!A:%{!nostartfiles:%{!nostdlib:%S}}} \
%{static:} \
%{L*} %{!Zwin32:%D} %{T*} %o \
%{!Zwin32: -Tdjgpp.djl} %{Zwin32: -Trsxnt.djl} \
%{!nostdlib: \
%{!Zwin32: -lgcc %L -lgcc %{!A:%E}} \
%{Zwin32: \
%{!Zdll:-lmain} \
%{Zdll:-ldll} \
-lalias \
%{!Zcrtdll*: %G %L %G %{!Zno-rte:-lemx -lemx2} -lkrn32 -lusr32 -lgdi32} \
%{Zcrtdll*: -lstati %{!Zmt: -lcrtcs} %{Zmt: -lcrtcm} -lemx2 -lkrn32 -lusr32 -lgdi32} \
} \
}
%{!Zwin32: \
stubify %{v} %{o*:%*} %{!o*:a.out} \
}
%{Zwin32: \
%{!o*:%especs: no output name} \
ntbind %{!g:-remove} %{o*:%*} %{Zrsx32: -s dosstub.rsx} \
}
}}}}}
*lib:
-lc \
%{Zwin32: \
%{Zdll: \
%{Zso:-ldllso} \
%{Zno-rte:-ldllno} \
%{!Zso:%{!Zno-rte:-ldllrt}} \
} \
%{!Zdll:-lc_app} \
-lc \
}
*startfile:
%{!Zwin32: \
%{pg:gcrt0.o%s}%{!pg:%{p:mcrt0.o%s}%{!p:crt0.o%s}} \
} \
%{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} \
}
*switches_need_spaces:
*signed_char:
%{funsigned-char:-D__CHAR_UNSIGNED__}
*predefines:
-Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -DDJGPP_MINOR=1
*cross_compile:
0
*multilib:
st Zwin32 !Zmt;mt Zwin32 Zmt;
- Raw text -