Mail Archives: djgpp-workers/2001/01/14/04:51:33
> Even if Autoconf is fixed, what do we do about all the Makefile's out
> there which have "foo", not "foo$EXE_EXT" as their targets?
Well, autoconf now uses AC_EXEEXT automatically when a compiler check
is done (at least, it did in 2.49a; can't be really sure it will be this
way in the 2.50 release). Unfortunately, automake still requires seeing
an explicit AC_EXEEXT call in configure.in. Once autoconf 2.50 is
released, I'll probably make a DJGPP package of the current CVS automake
as well; if it still requires AC_EXEEXT, I'll hack it to look for the
macro autoconf invokes which runs AC_EXEEXT. Alternatively, automake'd
packages will require adding AC_EXEEXT to configure.in and re-running
autoconf and automake. In any case, automake'd Makefiles should be doing
The Right Thing(tm) already; if they're not, it indicates a problem with
configure.in.
Non-automake'd makefiles will need manual adjusting. But then again, those
probably already used per-platform variations, so minor changes to the
existing Makefile.dj2 should not be too big a deal.
> We could make ld.exe create an empty `foo', but I suspect that at least
> some Makefile's will actually try to run `foo' (I remember seeing
> "GO32-V2" in the DOS box's caption bar when some packages build).
Yes, usually they use ./<your executable here> <options>. This is
perfectly acceptable if we generate foo.exe, and even if we let ld produce
a coff-go32-exe named foo, but not if we have a fake foo (though if it's
a zero-byte file, or a file containing 'dummy for foo.exe', I doubt libc
will try to execute it.
> So I'm afraid getting rid of producing the extensionless program will
> break too many packages that have integrated DJGPP support. Someone(tm)
> will have to fix all those as well.
Best I can do is to make sure autoconf and automake DTRT; Cygnus configure
already does, I think.
- Raw text -