From: John DOT Turner AT pobox DOT com (John A. Turner)
Subject: make problem/bug on NT (Cygwin B19)
16 Aug 1998 14:41:10 -0700
Message-ID: <35D6877B.48E45A26.cygnus.gnu-win32@POBox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: gnu-win32 mailing list <gnu-win32 AT cygnus DOT com>,
        bug-gnu-utils AT prep DOT ai DOT mit DOT edu

[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 AT cygnus DOT com" with one line of text: "help".