[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #42910] chained implicit rule can fail to make a prerequisite

From: Manoj Srivastava
Subject: [bug #42910] chained implicit rule can fail to make a prerequisite
Date: Mon, 04 Aug 2014 21:25:38 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.0


                 Summary: chained implicit rule can fail to make a
                 Project: make
            Submitted by: srivasta
            Submitted on: Mon 04 Aug 2014 04:25:37 PM CDT
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: 3.81
        Operating System: POSIX-Based
           Fixed Release: None
           Triage Status: None




    This was reported by a Debian user. Please retain a CC to
address@hidden so that the Debian BTS has a record of this

  Please note that I have been unable top reproduce this with 4.0.X versiosn
of make, so this issue may have been resolved. It would help if we knew what
the fix wwas, and any information that helps us backport it to Debian stable
would be appreciated.

have a Makefile where make appears to decide to use the 2nd of a
pair of chained implicit rules to construct a file, despite having earlier
rejected this same pair of rules when deciding whether to build the necessasry
intermediate file.

As a result, make can run the rules for the 2nd implicit rule despite the fact
that one of its prerequisites has not been built.  The ommands for the 2nd
rule then fail.

To reproduce:

Firstly, preparation:

 $ git clone git://git.chiark.greenend.org.uk/~ianmdlvl/adns.git
   [ usual output from git clone ]
 $ cd adns
 $ git checkout make-bug.2014-07-26
   [ warning about git about detached HEAD ]
 $ ./configure
 $ make
   [ build should complete successfully ]
 $ cd regress

Now repeat the following steps until you lose the race like this:

 $ touch ../src/addrfam.c 
 $ make -j2
 gcc -g -O2 -Wall -Wmissing-prototypes -Wwrite-strings -Wstrict-prototypes
-Wcast-qual -Wpointer-arith -Wno-pointer-sign  -I../src -I. -I./../src 
-DADNS_REGRESS_TEST -I. -c -g -o addrfam_d.o ../src/addrfam.c
 gcc    adnstest_c.o hrecord.o hcommon.o types_d.o event_d.o query_d.o
reply_d.o general_d.o setup_d.o transmit_d.o parse_d.o poll_d.o check_d.o
addrfam_d.o  -o adnstest_record
 gcc: error: adnstest_c.o: No such file or directory
 make: *** [adnstest_record] Error 1

(If you win the race it rebuilds adnstest_c.o again.)

Detailed consideration of the manual node `Implicit Rule Search'
suggests that the Makefile is correct by virtue of para.6: while the
intermediate file adnstest_c.o does not exist, and is not mentioned as a
target or explicit prerequisite, it can be made.

So make is correct to try to use this rule.  But of course it ought to
construct the file first.

The bug occurs only with nontrivial -j options.  I have reproduced it with -j4
and (as here) -j2.

I have also, once, seen it do this:

 regress$ touch ../src/addrfam.c; make -j adnstest_record
 gcc -g -O2 -Wall -Wmissing-prototypes -Wwrite-strings -Wstrict-prototypes
-Wcast-qual -Wpointer-arith -Wno-pointer-sign -I../src -I. -I./../src 
-DADNS_REGRESS_TEST -I. -c -g -o addrfam_d.o ../src/addrfam.c


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]