Hi Chris, Michael
On Thursday 26 October 2006 11:55 am, Michael Gerdau wrote:
> [Makefile]
>
> > lib%.a : %.def %.o
> > »···$(DLLTOOL) $(DLLTOOL_FLAGS) --output-lib $@ --def
> > $(srcdir)/$*.def
> > »···$(AR) r $@ $*.o
> > »···$(RANLIB) $@
> >
> > lib%.a: %.def
> > »···$(DLLTOOL) $(DLLTOOL_FLAGS) --output-lib $@ --def $<
> >
> > lib%.a: %.o
> > »···$(AR) rc $@ $*.o
> > »···$(RANLIB) $@
> >
> > With previous versions of make the first rule was used to produce
> > libraries that have both def and object files:
>
> Interesting set of rules...I wasn't even aware the first rule would be
> valid - and after consulting the make info file I'm not convinced it
> is.
I don't think there is anything wrong with the rules, as such; what is
troubling is those `»···' characters in front of each command line, where
there should be at least one initial TAB character, followed by zero or
more TABs or SPACEs, and then the command; what is the `»···' garbage?
> However I see the dlltool comamnds differ slightly (a editing error?).
No; it's simply the way the Makefile has been set up to support VPATH
builds, and looks fine to me; `$<' probably *should* be preferred to
`$(srcdir)/$*.def', in the commands for *both* rules, but it might be
ambiguous -- remember, it is the first listed prerequisite wrt which the
dependent is out of date, and not simply the first listed prerequisite.
> What happens if you change the first rule to:
> lib%.a : $(srcdir)/%.def %.o
> »···$(DLLTOOL) $(DLLTOOL_FLAGS) --output-lib $@ --def $(srcdir)/$*.def
Shouldn't be necessary. If the Makefile defines `srcdir' and `VPATH'
correctly, say with:
srcdir = ../w32api/somedir
VPATH = $(srcdir)
then the dependency will be resolved for both in-place and VPATH builds,
regardless of whether the `%.def' pattern matches *either* in the source
or in the build directory; if you change it, then the pattern *must*
match in the source directory, and will fail if the `%.def' match is a
generated file. That ambiguous matching carries through with the `$<'
expansion, but IIRC not in `$*'; so there is an implicit presumption that
the `%.o' matches, in the above rule set, will *always* be generated
files, or at least, always present in the build directory.
> Anyway:
> If I understand the documentation correctly any pattern rule is
> something like TARGETPATTERN : SOURCEPATTERN (possibly prefixed by an
> optional "TARGETLIST:") and both TARGETPATTERN/SOURCEPATTERN contain
> a '%'.
>
> > whereas with version 3.81 it just runs the dlltool command as a
> > result the symbols and functions exported from the object file are
> > not included in the import library.
>
> I see the problem.
I cannot reproduce it on my GNU/Linux box, (Ubuntu 6.06).
> > Has this behaviour changed in version 3.81? Is this expected?
>
> No idea, I have yet to use 3.81.
Not that I know of. I ran this test case, on the Ubuntu box:
$ make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i686-pc-linux-gnu
$ cat Makefile
# Makefile
# Test, to verify correct operation of Chris Sutcliffe's problem case.
srcdir = .
DLLTOOL = echo >> $@ dlltool
DLLTOOL_FLAGS = --as=as -k
AR = echo >> $@ ar
RANLIB = echo >> $@ ranlib
lib%.a: %.def %.o
rm -f $@
$(DLLTOOL) $(DLLTOOL_FLAGS) --output-lib $@ --def $(srcdir)/$*.def
$(AR) r $@ $*.o
$(RANLIB) $@
lib%.a: %.def
rm -f $@
$(DLLTOOL) $(DLLTOOL_FLAGS) --output-lib $@ --def $<
lib%.a: %.o
rm -f $@
$(AR) rc $@ $*.o
$(RANLIB) $@
all: libfee.a libfie.a libfoe.a libfum.a
# Makefile: end of file
$ rm libf??.a f??.def f??.o
$ touch fee.def fie.o foe.def foe.o fum.o
$ make
rm -f libfee.a
echo >> libfee.a dlltool --as=as -k --output-lib libfee.a --def fee.def
rm -f libfie.a
echo >> libfie.a ar rc libfie.a fie.o
echo >> libfie.a ranlib libfie.a
rm -f libfoe.a
echo >> libfoe.a dlltool --as=as -k --output-lib libfoe.a --def ./foe.def
echo >> libfoe.a ar r libfoe.a foe.o
echo >> libfoe.a ranlib libfoe.a
rm -f libfum.a
echo >> libfum.a ar rc libfum.a fum.o
echo >> libfum.a ranlib libfum.a
$ grep \$ libf??.a
libfee.a:dlltool --as=as -k --output-lib libfee.a --def fee.def
libfie.a:ar rc libfie.a fie.o
libfie.a:ranlib libfie.a
libfoe.a:dlltool --as=as -k --output-lib libfoe.a --def ./foe.def
libfoe.a:ar r libfoe.a foe.o
libfoe.a:ranlib libfoe.a
libfum.a:ar rc libfum.a fum.o
libfum.a:ranlib libfum.a
Note that this is a clean GNU make-3.81, and its behaviour is just as
expected and as required; the behaviour Chris reports is abnormal.
> > how would I go about getting back to the behaviour I desire?
>
> The *.def files are original sources and not created by a rule !?
> Assuming that's the case you could modify the rules as follows:
>
> LIBS_WITH_O = foo.a bar.a
> LIBS_NO_O = fum.a fam.a
> LIBS_NO_D = fim.a fem.a
>
> $(LIBS_WITH_O): lib%.a : %.o
> »···$(DLLTOOL) $(DLLTOOL_FLAGS) --output-lib $@ --def $(srcdir)/$*.def
> »···$(AR) r $@ $*.o
> »···$(RANLIB) $@
>
> $(LIBS_NO_O): lib%.a : %.def
> »···$(DLLTOOL) $(DLLTOOL_FLAGS) --output-lib $@ --def $<
>
> $(LIBS_NO_O): lib%.a : %.o
> »···$(AR) rc $@ $*.o
> »···$(RANLIB) $@
This would add an unnecessary maintenance overhead; now the maintainer
needs to define separate lists for those libs which have both `%.def' and
`%.o' prerequisites, and those with only one or the other, instead of
simply having one common list. He then has to remember to move any, when
its prerequisites change; yuk, no thanks! Let's rather figure out why
Chris' `make-3.81' isn't behaving as it should; i.e. focus on the
problem, not on the symptom.
Regards,
Keith.
|
