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
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.