I would like MakeMaker not to write an implicit rule for making
object files directly from XS files on Windows98. This is preventing
me from smoking blead perl on Windows98.
I am getting this error message making extensions, after miniperl is built
using gcc, dmake and makefile.mk on Windows98.
DMAKE.EXE: Error -- Ambiguous inference chains for target 'C.o'
DMAKE.EXE: 1. C.o(%.o) --> C.xs(%.xs)
DMAKE.EXE: 2. C.o(%.o) --> C.c(%.c)
DMAKE.EXE: Error -- resolve ambiguity before proceeding.
Unsuccessful make(B/C): code=65280 at buildext.pl line 98.
DMAKE.EXE: Error -- `__no_such_target' not found, and can't be made
DMAKE.EXE: Error -- Ambiguous inference chains for target 'C.o'
DMAKE.EXE: 1. C.o(%.o) --> C.xs(%.xs)
DMAKE.EXE: 2. C.o(%.o) --> C.c(%.c)
DMAKE.EXE: Error -- resolve ambiguity before proceeding.
DMAKE.EXE: Error -- Ambiguous inference chains for target 'B.o'
DMAKE.EXE: 1. B.o(%.o) --> B.xs(%.xs)
DMAKE.EXE: 2. B.o(%.o) --> B.c(%.c)
DMAKE.EXE: Error -- resolve ambiguity before proceeding.
Unsuccessful make(B): code=65280 at buildext.pl line 98.
This has been an occasional, intermittent dmake failure building perl XS
extensions in the past. It seems to have something to do with recursive
processing of the Makefiles in B and B/C. It doesn't seem to just depend on
whether there is an object or C file already in the directory or not.
Though if files have been made and exist, this error will occur.
If I comment out the xs_o method in MM_Win98, then the extensions build.
That method is essentially the same as the xs_o method in MM_Unix,
which reproduces the .xs.c and .c.o implicit rules in one implicit .xs.o rule.
According to MM_Unix,
=item xs_o (o)
Defines suffix rules to go from XS to object files directly. This is
only intended for broken make implementations.
=cut
sub xs_o { # many makes are too dumb to use xs_c then c_o
The overriding xs_o method in MM_Win32 stubs this out. A note says:
=item xs_o (o)
This target is stubbed out. Not sure why.
Is it OK if it is stubbed out in MM_Win98, too?
Will there be anyone building on Windows98 who isn't using dmake?
Is nmake too dumb to use xs_c, then c_o? Probably not. Perhaps
it was stubbed out in MM_Win32 for the same reason.
--
Greg Matheson, Taiwan
