Mail Archives: djgpp-workers/1999/03/11/18:48:43
> > I'm (still) using GCC-2.8.1, and -DDJGPP=2 isn't defined there (in
> > config/i386/go32.h). What Peter uses is I think egcs-2.91.60, and it
> > doesn't seem to be defined there, either. So I assume it's OK if we
> > add it there?
> >
> > > LINK_COMMAND_SPEC is defined but not dumped of course.
>
> I have LINK_COMMAND_SPEC defined in config/i386/go32.h
OK, we added it now for the older GCC/EGCS versions.
> > Of course? Well, I don't know the reasons behind that, but I know
> > that there's a problem currently with regard to GPC.
> >
> > GPC comes with a runtime library (libgpc.a) -- a bit like libgcc.a,
> > however it requires some configure checks. The configure script for
> > that library, has to be run with the xgcc just built (rather than
> > the cc used to build the compiler, because that's a compiler for
> > host, and we need one for target here).
> >
> > Unfortunately, somewhere in the Makefile, xgcc is made to dump its
> > specs, and if this happens before libgpc is configured, it will use
> > those dumped specs instead of the built in ones, so it will miss the
> > link command, and produce the error:
> >
> > configure: error: installation or configuration problem: C compiler
> > cannot create executables.
> >
> > For the first make, it works by chance as Peter said, i.e. the
> > libgpc configure happens before the dumpspecs (but since the order
> > of make rules evaluation is partly undeterministic, this is not
> > guaranteed to work, consider e.g. make -j). However, when we change
> > a Makefile.in later, make will run the libgpc configure again, and
> > this time the dumped specs are already there, and the error occurs.
> >
> > I don't know what is supposed to be the right solution, but to me it
> > would seem most natural if the DJGPP compiler would dump exactly
> > those specs that it needs.
> >
> > > So
> > > DJGPP is defined. DJGPP_MINOR is defined for DJGPP-2.02 in
> > > sys/version.h included from stdio.h. I dont think we should define it
> > > in specs.
> >
> > I think that's alright for GPC.
> >
>
> Try binaries of egcs-1.1.2-pre3 for DJGPP I uploaded today to
> ftp.delorie.com. They are at:
> ftp://ftp.delorie.com/private/egcs
>
> At least I met no problems building egcs together with libg++-2.8.1.3 and
> gpc-19980118. No source archive yet but I put script there that modifies
> original sources for building with DJGPP.
As I said, a simple one-time make works by accident. However, when
you let it dump its specs and install them, it will get problems.
So, why must it dump its specs: This is to make cross-compilers
work. As you might know, a single gpc (or gcc) compiler driver can
be used to compile for different targets, using the `-b<target>'
option. It will then find the correct gpc1 (or cc1) (cross) compiler
in lib/gcc-lib/<target>/<version>. So far so good.
However, gpc (gcc) has only built in specs for native compilation,
not for cross compiling. So, to make the cross compilers work, they
need their specs installed in lib/gcc-lib/<target>/<version>/specs,
and the way to get the specs there, is to have them dumped by the
(cross) compilers as they get built.
That's why I think that the DJGPP compiler should dump the
LINK_COMMAND_SPECS (otherwise, e.g., a Linux gpc when called with
`-b i386-pc-go32' will not know about the link command specs and
will not be able to link correctly for DJGPP). If there is any
problem with dumping the LINK_COMMAND_SPECS, please tell me what it
is -- up to know, I don't know of any problem.
BTW, that's not a theoretical issue. I'm constantly building a
number of native and cross compilers on my system, including
Linux->DJGPP and DJGPP->Linux cross compilers, and I'm currently
having a problem because of the LINK_COMMAND_SPECS not being dumped.
Frank
--
Frank Heckenbach, frank AT fjf DOT gnu DOT de
http://fjf.gnu.de/
PGP and GPG keys: http://fjf.gnu.de/plan
- Raw text -