Mail Archives: djgpp/1998/03/25/07:32:25
On Tue, 24 Mar 1998, Bob Paddock wrote:
> > gcc -o cc1 ....
>
> cc1: $(P) $(C_OBJS) $(OBJS) $(BC_OBJS) $(LIBDEPS)
> $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ $(C_OBJS) $(OBJS) $(BC_OBJS) $(LIBS)
>
> Don't think that is what you where really asking tho?
This is *exactly* what I was asking about. The "-o $@" part is expanded
by Make into "-o cc1". When GCC sees that option, it should generate
both cc1 and cc1.exe.
> makefile has "exeext =" (None), but gcc.c says:
>
> #if !defined(__DJGPP__)
> /* Do not convert the output filename on DJGPP, since it
> will break many makefiles, which assume, that gcc produces
> exactly the file, which was given as output file. And since
> GNU make for DJGPP (which is the only make used) can run
> also the programs without the .exe suffix this not a problem)
> */
>
> Therefor I get what the makefiles says it will give me,
> executable with no extensions.
AFAIK, you are looking in the wrong place. The $exeext trick is not for
DJGPP, it's for another MS-based environment (Cygwin32, I think).
> Which is why I expected "install" or some thing to produce .exe
> versions at some point.
The DJGPP port of `install' can also stubify the COFF images on the fly,
but I'm not sure "make install" uses that. And I remember you telling
that "make install" didn't work for you either.
> I don't know what a "specs file" is, but I have the felling
> I'm about to find out... :-)
The stock version supplied with DJGPP is in %DJDIR%/lib/specs. Under the
linker section there you will see that GCC invokes a program called
`stubify' which is what prepends the 2KB stub to the COFF image.
My guess was that the GCC build procedure somehow forces GCC to use
another specs file, which doesn't instruct GCC to run`stubify'.
- Raw text -