make problem/bug on NT (Cygwin B19)
John A. Turner
John.Turner@pobox.com
Sun Aug 16 04:13:00 GMT 1998
[using Cygwin B19 with Sergey's latest coolview (7/15) on NT,
gmake --version shows 3.75-B19, make_mode set to unix]
I've been having a horrible time with a very odd make problem. I
hesitate to call it a bug with make yet, for reasons that will
become apparent.
After hours of poking at this thing, I've got it pinned down pretty
well, but the problem is that a key factor seems to be the particular
linker I'm using, which comes with the Absoft compilers, but this is
a *very* weird problem.
OK, consider a directory containing the following source files:
GNUmakefile
numbers.f90
types.f90
The important part of the makefile looks like this:
f90_files = $(wildcard *.f90)
src_names = $(notdir $(basename $(f90_files)))
obj_files = blorp.lib($(addsuffix .obj,$(src_names)))
default: blorp
%.obj: %.f90
f90 -c $<
blorp:
gmake blorp.lib
blorp.lib(%.obj): %.obj
if [ -f $@ ]; then lb /out:$@ $@ $<; else lb /out:$@ $<; fi
blorp.lib: $(obj_files)
touch $@
Obviously, "lb" is the Absoft equivalent of "ar". The reason for
the screwy rule is that "lb" can't handle with a single form both
cases where the lib doesn't yet exist and where it has already
been created.
OK, so here's what happens:
STRAT$ gmake
gmake blorp.lib
f90 -c numbers.f90
if [ -f blorp.lib ]; then lb /out:blorp.lib blorp.lib numbers.obj; else lb /out:blorp.lib numbers.obj; fi
f90 -c types.f90
if [ -f blorp.lib ]; then lb /out:blorp.lib blorp.lib types.obj; else lb /out:blorp.lib types.obj; fi
touch blorp.lib
rm numbers.obj types.obj
STRAT$ touch numbers.f90
STRAT$ gmake
gmake blorp.lib
touch blorp.lib
numbers.f90 isn't being recompiled.
OK, so you say dealing with libraries is always tricky, maybe
I've done something wrong. Alright, so let's try using the
standard "ar" rule, even though we know it would fail to link
with the other Absoft stuff. That is, change the rule for
archive members to:
ar rv $@ $<
Guess what? Works correctly:
STRAT$ gmake
gmake blorp.lib
f90 -c numbers.f90
ar rv blorp.lib numbers.obj
a - numbers.obj
f90 -c types.f90
ar rv blorp.lib types.obj
a - types.obj
touch blorp.lib
rm numbers.obj types.obj
STRAT$ touch numbers.f90
STRAT$ gmake
gmake blorp.lib
f90 -c numbers.f90
ar rv blorp.lib numbers.obj
r - numbers.obj
touch blorp.lib
rm numbers.obj
OK, so I did a few other tests.
o use the "ar" rule inside the same kind of test to see if
that's the problem, i.e.:
if [ -f $@ ]; then ar rv $@ $<; else ar rv $@ $<; fi
works fine
o try rewriting the original "lb" rule, i.e.:
if [ ! -f $@ ]; then lb /out:$@; fi
lb /out:$@ $@ $<
fails just like original
o in last desperate attempt, use "-" form for options rather
than "/", i.e.:
if [ -f $@ ]; then lb -out:$@ $@ $<; else lb -out:$@ $<; fi
fails just like original
Does anyone have a clue what might be happening here? Obviously
something's weird about Absoft's "lb", but I don't understand
how what's in the rule could cause what we're seeing here.
Oh, I also grabbed the source for v3.77 of make, and although it
configured and build right out of the box, it seemed to have
other problems (kept claiming times were off). So I set that
aside and went back to the one dist with B19.
Thanks in advance to anyone who's read this far. I wish I
could send a test case anyone could try, but it seems to be
tied up somehow with Absoft's archive tool.
--
John A. Turner
Blue Sky | VIFX - http://www.bluesky-vifx.com/
Los Alamos Nat Lab - http://lune.mst.lanl.gov/turner/
Personal - http://john.turner.org/
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".
More information about the Cygwin
mailing list