NetBSD Problem Report #50176

From www@NetBSD.org  Wed Aug 26 11:31:21 2015
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 98394A6562
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 26 Aug 2015 11:31:21 +0000 (UTC)
Message-Id: <20150826113120.55315A65BA@mollari.NetBSD.org>
Date: Wed, 26 Aug 2015 11:31:20 +0000 (UTC)
From: sdaoden@yandex.com
Reply-To: sdaoden@yandex.com
To: gnats-bugs@NetBSD.org
Subject: make(1) prerequisite not assigned to target if target has ./ prefix
X-Send-Pr-Version: www-1.0

>Number:         50176
>Category:       bin
>Synopsis:       make(1) prerequisite not assigned to target if target has ./ prefix
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 26 11:35:01 +0000 2015
>Last-Modified:  Mon Aug 31 17:25:00 +0000 2015
>Originator:     Steffen Nurpmeso
>Release:        NetBSD 7.0_RC3
>Organization:
>Environment:
NetBSD nbsd 7.0_RC3 NetBSD 7.0_RC3 (GENERIC.201508110747Z) i386
>Description:
Makefile contains

  $(AMALGAM_TARGET) mime_types.o: mime_types.h

which happens to end up as

  CC ./mime_types.c
./mime_types.c:95:24: fatal error: mime_types.h: No such file or directory
 #include "mime_types.h"
                        ^
compilation terminated.
*** Error code 1

Stop.
make[1]: stopped in /home/sdaoden/usr/src/s-nail.git
*** Error code 1

Stop.
make: stopped in /home/sdaoden/usr/src/s-nail.git
>How-To-Repeat:
Use relative path names for CWD.
>Fix:
A basename(3) call is missing somewhere. 

>Audit-Trail:
From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/50176: make(1) prerequisite not assigned to target if target
 has ./ prefix
Date: Wed, 26 Aug 2015 14:31:45 +0200

 On Wed, Aug 26, 2015 at 11:35:02AM +0000, sdaoden@yandex.com wrote:
 > >Fix:
 > A basename(3) call is missing somewhere. 

 make is not supposed to mangle path names.

 Joerg

From: Steffen Nurpmeso <sdaoden@yandex.com>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/50176: make(1) prerequisite not assigned to target if
 target has ./ prefix
Date: Wed, 26 Aug 2015 15:07:32 +0200

 Joerg Sonnenberger <joerg@britannica.bec.de> wrote:
  |The following reply was made to PR bin/50176; it has been noted by GNATS.
  |
  |From: Joerg Sonnenberger <joerg@britannica.bec.de>
  |To: gnats-bugs@NetBSD.org
  |Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
  |Subject: Re: bin/50176: make(1) prerequisite not assigned \
  |to target if target
  | has ./ prefix
  |Date: Wed, 26 Aug 2015 14:31:45 +0200
  |
  | On Wed, Aug 26, 2015 at 11:35:02AM +0000, sdaoden@yandex.com wrote:
  |>>Fix:
  |> A basename(3) call is missing somewhere. 
  | 
  | make is not supposed to mangle path names.

 Whatever bmake is about to do, ./f and f are the same file and
 should thus be treated likewise, of course, of course.
 I've started being explicit via ./ for i think the UnixWare port,
 and i like it.  In NetBSD 7.0 RC3 i have to use this syntax for
 e.g. ldd(1), a plain "ldd s-nail" didn't work.  This surprised me
 this noon, i have never consciously realized such behaviour on BSD.
 While complaining, pkgin DB update didn't work with 128MB RAM, and
 the 7.0RC3 pkg path didn't exist.  I've used 6.1, but libelf has
 been bumped... seems to work though.
 I've changed my makefile generation script again.

 --steffen

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/50176: make(1) prerequisite not assigned to target if
Date: Wed, 26 Aug 2015 15:53:22 +0200

 Can you please provide a simple makefile (using cat/echo/touch or
 similar basic tools) to demonstrate the issue?

 I can not see from your original report why the compiler is not seeing
 mime_types.h and which files are actually there/where (and especially
 in what work dir this happens and where the source lives).

 Martin

From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, sdaoden@yandex.com
Subject: Re: bin/50176: make(1) prerequisite not assigned to target if target
 has ./ prefix
Date: Wed, 26 Aug 2015 23:21:10 +0200

 On Wed, Aug 26, 2015 at 01:10:02PM +0000, Steffen Nurpmeso wrote:
 >   | On Wed, Aug 26, 2015 at 11:35:02AM +0000, sdaoden@yandex.com wrote:
 >   |>>Fix:
 >   |> A basename(3) call is missing somewhere. 
 >   | 
 >   | make is not supposed to mangle path names.
 >  
 >  Whatever bmake is about to do, ./f and f are the same file and
 >  should thus be treated likewise, of course, of course.

 But they are not the same thing for make. "f" as target is searched
 using .PATH, "./" as target is considered a resolved relative path.

 Joerg

From: Steffen Nurpmeso <sdaoden@yandex.com>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/50176: make(1) prerequisite not assigned to target if
Date: Thu, 27 Aug 2015 12:56:30 +0200

 Martin Husemann <martin@duskware.de> wrote:
  | Can you please provide a simple makefile (using cat/echo/touch or
  | similar basic tools) to demonstrate the issue?
  | 
  | I can not see from your original report why the compiler is not seeing
  | mime_types.h and which files are actually there/where (and especially
  | in what work dir this happens and where the source lives).

 Yes sure.  Sorry, my old box was compromised (at least via
 Firefox, stupid me) and i had to rotate keys+ and move to a new
 box, the first in over six years, am still not fully setup etc.

 --steffen

 mkdir x || exit 1
 cd x || exit 2
 echo '#include "hf.h"' > cf.c
 cat > exp.mk <<'_EOT'
 OBJ_SRC = ./cf.c
 OBJ = $(OBJ_SRC:.c=.o)
 .SUFFIXES: .o .c .y
 .c.o:
 	$(CC) $(CFLAGS) $(INCS) -c $(<)
 .c .y: ;
 all: $(OBJ)
 cf.o: hf.h
 hf.h:
 	echo '#include <stdlib.h>' > hf.h
 clean:
 	rm -f $(OBJ) hf.h
 _EOT
 < exp.mk sed -e 1d | (echo OBJ_SRC = cf.c; cat) > imp.mk
 echo explicit relative CWD
 make -f exp.mk
 make -f exp.mk clean
 echo implicit relative CWD
 make -f imp.mk
 make -f imp.mk clean
 cd ..
 rm -rf x || exit 3

From: Steffen Nurpmeso <sdaoden@yandex.com>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/50176: make(1) prerequisite not assigned to target if
 target has ./ prefix
Date: Thu, 27 Aug 2015 13:05:06 +0200

 Joerg Sonnenberger <joerg@britannica.bec.de> wrote:
  |The following reply was made to PR bin/50176; it has been noted by GNATS.
  |Date: Wed, 26 Aug 2015 23:21:10 +0200
  | On Wed, Aug 26, 2015 at 01:10:02PM +0000, Steffen Nurpmeso wrote:
  |>| On Wed, Aug 26, 2015 at 11:35:02AM +0000, sdaoden@yandex.com wrote:
  |>|>>Fix:
  |>|> A basename(3) call is missing somewhere. 
  |>| 
  |>| make is not supposed to mangle path names.
  |>  
  |>  Whatever bmake is about to do, ./f and f are the same file and
  |>  should thus be treated likewise, of course, of course.
  | 
  | But they are not the same thing for make. "f" as target is searched
  | using .PATH, "./" as target is considered a resolved relative path.

 Fine you know the code so good, then you ca easily fix this :)
 Ah,.. i'm good in.

 --steffen

From: Martin Husemann <martin@duskware.de>
To: Steffen Nurpmeso <sdaoden@yandex.com>, gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/50176: make(1) prerequisite not assigned to target if
Date: Thu, 27 Aug 2015 13:38:06 +0200

 On Thu, Aug 27, 2015 at 12:56:30PM +0200, Steffen Nurpmeso wrote:
 > cf.o: hf.h
 > hf.h:
 > 	echo '#include <stdlib.h>' > hf.h

 So (for dummies like me) summarized:

 The point is that if you use OBJ_SRC = ./cf.c the above cf.o rule
 does not trigger and you have to write

 ./cf.o: hf.h

 instead to match ${OBJ}. You could (in this simple example) just use

 ${OBJ}: hf.h

 and it all works.

 Wether this should be considered a bug, I am not sure.

 Martin

From: Steffen Nurpmeso <sdaoden@yandex.com>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@NetBSD.org
Subject: Re: bin/50176: make(1) prerequisite not assigned to target if
Date: Thu, 27 Aug 2015 19:08:11 +0200

 Martin Husemann <martin@duskware.de> wrote:
  |On Thu, Aug 27, 2015 at 12:56:30PM +0200, Steffen Nurpmeso wrote:
  |> cf.o: hf.h
  |> hf.h:
  |>  echo '#include <stdlib.h>' > hf.h
  |
  |So (for dummies like me) summarized:

 Ah!  Oh!

  |The point is that if you use OBJ_SRC = ./cf.c the above cf.o rule
  |does not trigger and you have to write
  |
  |./cf.o: hf.h

 Would, yes, would.  I wanna remain and/or become portable with the
 things i maintain, so have to hold hands, here and there.

  |instead to match ${OBJ}. You could (in this simple example) just use
  |
  |${OBJ}: hf.h
  |
  |and it all works.

 Hah!  Really..  (I didn't try that out.)

  |Wether this should be considered a bug, I am not sure.

 As long as there are mexican women which are women and my heart is
 beating that's how it'll be.
 Ciao,

 --steffen

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/50176: make(1) prerequisite not assigned to target if
Date: Mon, 31 Aug 2015 17:21:13 +0000

 On Thu, Aug 27, 2015 at 11:40:00AM +0000, Martin Husemann wrote:
  >  The point is that if you use OBJ_SRC = ./cf.c the above cf.o rule
  >  does not trigger and you have to write
  >  
  >  ./cf.o: hf.h
  >  
  >  instead to match ${OBJ}. You could (in this simple example) just use
  >  
  >  ${OBJ}: hf.h
  >  
  >  and it all works.
  >  
  >  Wether this should be considered a bug, I am not sure.

 I would say it isn't.

 If make were better organized inside it might be possible to make it
 warn if the same file is referred to by more than one target name.
 (Not a chance of that currently.) But we don't want to get into the
 business of altering target names like they're paths (with realpath or
 anything else) because, among other things, they aren't always paths.

 -- 
 David A. Holland
 dholland@netbsd.org

Home	PR Database Search