make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Adam J. Richter]

	linux-2.5.24/drivers/net/hamradio/soundmodem/Makefile contains
the following rule:

$(obj)/sm_tbl_%: $(obj)/gentbl
        $<

	obj was set to "." /usr/src/linux/Rules.make, which was included
earlier in the Makefile.

	The problem is that when make executes this rule it executes
"gentbl" rather than "./gentbl".  This causes the command to fail if
you do not have "." in your path.  Make-3.79.1 is apparently being too
clever in expanding file names.  I think this is a make bug.

	Until the make bug is fixed, I have worked around the problem
by replacing the rule with:

$(obj)/sm_tbl_%: $(obj)/gentbl
        PATH=$(obj):$$PATH $<


Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Henning Makholm]

Scripsit "Adam J. Richter" <adam@yggdrasil.com>

[Warning: I am not the make maintainer; I just lurk on bug-make]

> $(obj)/sm_tbl_%: $(obj)/gentbl
>         $<

> 	obj was set to "." /usr/src/linux/Rules.make, which was included
> earlier in the Makefile.

> 	Until the make bug is fixed, I have worked around the problem
> by replacing the rule with:

> $(obj)/sm_tbl_%: $(obj)/gentbl
>         PATH=$(obj):$$PATH $<

That looks like an excessively complicated workaround. Why not just

$(obj)/sm_tbl_%: $(obj)/gentbl
	$(obj)/gentbl

?

I'm not sure this is really a bug either. It is a Good Thing that make
tries to normalize the names of targets and dependencies internally,
lest the build may be incomplete or redundant if make does not realize
that foo.bar and ./foo.bar is the same file. It is quite reasonable
for $< to unfold to the *canonical* name of the file in question, I
think.

If one absolutely wants the command to use the exact form of the
dependency that's used in the dependency list, it's easy to simply
reproduce that form, replacing the % by $*

-- 
Henning Makholm                                "You are in a little twisting
                                            maze of passages, all different"

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Riley Williams]

Hi Henning.

> [Warning: I am not the make maintainer; I just lurk on bug-make]

Fair warning...

>> $(obj)/sm_tbl_%: $(obj)/gentbl
>>         $<
>>
>> obj was set to "." in /usr/src/linux/Rules.make, which was included
>> earlier in the Makefile.
>>
>> Until the make bug is fixed, I have worked around the problem
>> by replacing the rule with:
>>
>> $(obj)/sm_tbl_%: $(obj)/gentbl
>>         PATH=$(obj):$$PATH $<

> That looks like an excessively complicated workaround. Why not just
>
> $(obj)/sm_tbl_%: $(obj)/gentbl
> 	$(obj)/gentbl
>
> instead ?

I'm no expert on Makefile syntax, but I am aware of one possible
difference between those two versions with SOME versions of Make and
I believe this Makefile has been carefully crafted to work with all
versions thereof.

The difference will only show up if $(obj) expands to a string with
spaces in it, generated by a definition such as...

	obj = `pwd`

...due to a difference in how SOME versions of Make handle that. My
experience has been that all versions of Make expand "dependency" tokens
as a single token, and copy them down as a single token when $< or the
like are used, but expand the $(obj) in the command line as multiple
tokens in that case. As an example, say that your version of that
definition had been used with the obj=`pwd` definition when the current
directory was "/home/michael/source files/ax25" and we see that the
dependency is correctly interpreted as...

	"/home/michael/source files/ax25/gentbl"

...but the command that follows is taken as being...

	/home/michael/source

...with a parameter of...

	files/ax25/gentbl

...which is clearly not what was intended.

> I'm not sure this is really a bug either.

It's a genuine bug that needs fixing.

> It is a Good Thing that make tries to normalize the names of targets
> and dependencies internally, lest the build may be incomplete or
> redundant if make does not realize that foo.bar and ./foo.bar is the
> same file.

Providing "internally" relates only to internal transliterations done on
the files listed on the dependency line for the purpose of determining
whether a particular file is up to date, and does not also relate to the
use of those files in the rules that follow, there's no problem there.

However, using ANY sort of transliteration with commands listed below
those lines is completely counter-intuitive, and 

> It is quite reasonable for $< to unfold to the *canonical* name of
> the file in question, I think.

The ONLY reasonable canonical name for ANY file is that which includes
the full path to that file starting from the root directory and working
down through real directories without encountering any symbolic links.
Absolutely anything else is open to misinterpretation.

> If one absolutely wants the command to use the exact form of the
> dependency that's used in the dependency list, it's easy to simply
> reproduce that form, replacing the % by $*

By doing so, one introduces unacceptable bugs in many cases, simply due
to differing treatment of the two cases by different versions of make.

Best wishes from Riley.

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Kai Germaschewski]

On Sat, 22 Jun 2002, Riley Williams wrote:

> >> $(obj)/sm_tbl_%: $(obj)/gentbl
> >>         PATH=$(obj):$$PATH $<
> 
> > That looks like an excessively complicated workaround. Why not just
> >
> > $(obj)/sm_tbl_%: $(obj)/gentbl
> > 	$(obj)/gentbl
> >
> > instead ?

I think I like the latter better as well. Anyway, $(obj) is just "."
currently, so it doesn't have a space in it. For $(src), I'll always use
relative paths, so there won't be any spaces in them either. I think it's
a sensible restriction for separate src/obj trees to disallow spaces in
the obj tree path, I fear it'd cause problems at a huge number of places.
At least it's certainly acceptable to do "no space" first and then see
what needs to be done in order to remove that restriction.

(I also think the two are functionally equivalent even if $(obj) contains 
a space, but I haven't tried at all)

--Kai

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Adam J. Richter]

enning Makholm wrote:
>Scripsit "Adam J. Richter" <adam@yggdrasil.com>
>> 	Until the make bug is fixed, I have worked around the problem
>> by replacing the rule with:

>> $(obj)/sm_tbl_%: $(obj)/gentbl
>>         PATH=$(obj):$$PATH $<

>That looks like an excessively complicated workaround. Why not just

>$(obj)/sm_tbl_%: $(obj)/gentbl
>	$(obj)/gentbl

	Thanks.  That is a cleaner workaround.



>I'm not sure this is really a bug either. It is a Good Thing that make
>tries to normalize the names of targets and dependencies internally,
>lest the build may be incomplete or redundant if make does not realize
>that foo.bar and ./foo.bar is the same file. It is quite reasonable
>for $< to unfold to the *canonical* name of the file in question, I
>think.

	That just makes the behavior of make less predictable.
Whatever make does with the file names internally is its own business.
Rewriting the file names passed to commands unnecessarily is
potentially a big problem.  Suppose, for example, that this was a
command that wanted to chop up the directory prefix and that the
bottom level directory was a symbolic link (for example, maybe I have
/usr/netscape/bin as a symlink to /usr/local/bin, but I want the
installation command to record the path name as /usr/netscape/bin).



>If one absolutely wants the command to use the exact form of the
>dependency that's used in the dependency list, it's easy to simply
>reproduce that form, replacing the % by $*

	Sorry, I do not understand what you mean.  If you want to
explain it to me, you may have to write the rule out.

	Thanks for the better workaround and the advice.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Riley Williams]

Hi Kai.

>>>> $(obj)/sm_tbl_%: $(obj)/gentbl
>>>>         PATH=$(obj):$$PATH $<

>>> That looks like an excessively complicated workaround. Why not just
>>>
>>> $(obj)/sm_tbl_%: $(obj)/gentbl
>>> 	$(obj)/gentbl
>>>
>>> instead ?

> I think I like the latter better as well.

Providing it is always exactly equivalent, I have no problem with it.

To be honest, I have no real interest in this particular issue as the
Linux-Hams package is inherently Linux specific, GNU make is the only
version of make used with Linux (as far as I have seen anyway), and GNU
make (in all versions I have met) correctly expands $(...) as a single
token wherever it is met. The problem I was referring to only relates to
some of the non-GNU make's used - certainly, the early Solaris versions
were known to do just that. I haven't used Solaris since 1999 so don't
feel qualified to comment on recent versions.

> Anyway, $(obj) is just "." currently, so it doesn't have a space in it.

Is that fixed as such for ever?

If so, what is the purpose behind having the definition in the first place?

> For $(src), I'll always use relative paths, so there won't be any
> spaces in them either. I think it's a sensible restriction for
> separate src/obj trees to disallow spaces in the obj tree path, I
> fear it'd cause problems at a huge number of places.

For many packages I've worked on, OBJ is defined as $(SRC)/../obj so if
$(SRC) has a space in it, then $(OBJ) will as well. My preferred version
deals with the entire problem in a different way:

 1. Each subdirectory has a Makefile that begins with...

	BASEDIR=..
	include $(BASEDIR)/Makefile-rules

    ...where the definition of BASEDIR is the relative path from the
    current directory to the base of the source tree for that package.

 2. $(BASEDIR)/Makefile-rules contains the following...

	TOPDIR = $(shell cd $(BASEDIR) ; set -P ; pwd)
	INCDIR = $(BASEDIR)/include
	OBJDIR = $(BASEDIR)/obj

    ...after which TOPDIR is the canonical path to the root directory
    of the package's source, INCDIR is the relative path from the
    current directory to the package include files directory, and
    OBJDIR is the relative path from the current directory to the
    common object directory.

Given those definitions, one can guarantee that problems such as the
above do not occur simply by not using directory names with spaces in
them inside the tree, and it also has the advantage that the resulting
tree is not dependent on where it is placed in the user's system.

In addition, this method guarantees that the commands used to compile
*.c files into *.o files will be exactly the same throughout the source
tree, thus preventing bugs resulting from incompatible optimisations in
different source files. This guarantee arises because the command
sequence to use is only defined in the common $(BASEDIR)/Makefile-rules
file, and not separately in each individual Makefile.

> At least it's certainly acceptable to do "no space" first and then
> see what needs to be done in order to remove that restriction.

The above does all that is necessary.

> I also think the two are functionally equivalent even if $(obj)
> contains a space, but I haven't tried at all.

With all versions of GNU make that I have tried, they are identical but
with some of the other make's out there, they are not, and that is what
causes problems such as the above to surface.

My stance on this is quite simple: If I write a program that isn't
inherently Linux specific, I would prefer for it to work unmodified on
Solaris, AIX and just about any other version of UNIX that may be out
there, so it can just be dropped on a system and the user run something
like `make config install` and ends up with a system on which it works.
Oddities such as relying on GNU make being the version of make installed
on that system are very much unwelcome as a result.

Best wishes from Riley.

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Henning Makholm]

Scripsit Riley Williams <rhw@InfraDead.Org>

> >> $(obj)/sm_tbl_%: $(obj)/gentbl
> >>         PATH=$(obj):$$PATH $<

> > That looks like an excessively complicated workaround. Why not just

> > $(obj)/sm_tbl_%: $(obj)/gentbl
> > 	$(obj)/gentbl

> The difference will only show up if $(obj) expands to a string with
> spaces in it, generated by a definition such as...

> 	obj = `pwd`

In which case the command

	PATH=$(obj):$$PATH $<

is likely do fail miserably too.

Also, the dependency list $(obj)/gentbl will be parsed as multiple
files when $(obj) contains spaces. Which is clearly the right
behavior, as it is hard to find a serious project that does not use
Makefile variables to hold the names of multiple dependencies
somewhere.

> ...due to a difference in how SOME versions of Make handle that. My
> experience has been that all versions of Make expand "dependency" tokens
> as a single token, and copy them down as a single token when $< or the
> like are used, but expand the $(obj) in the command line as multiple
> tokens in that case.

If one is afraid of that, one can use

	"$(obj)/gentbl"

which will prevent the shell from thinking that the space separates
"words" on the command line. (Whether one can trick make into
interpreting the space as part of the filename in the dependency list
is another matter).

> > I'm not sure this is really a bug either.

> It's a genuine bug that needs fixing.

I still disagree.

> Providing "internally" relates only to internal transliterations done on
> the files listed on the dependency line for the purpose of determining
> whether a particular file is up to date, and does not also relate to the
> use of those files in the rules that follow, there's no problem there.

I don't think that "$<" is documented anywhere to have any exact
relationship to the string of characters used in the depencency
list. The GNU make manual says that $< is "the name of the first
depencency", not "the string used to identify the first dependency in
the rule".

> The ONLY reasonable canonical name for ANY file is that which includes
> the full path to that file starting from the root directory and working
> down through real directories without encountering any symbolic links.
> Absolutely anything else is open to misinterpretation.

Assuming anything for $< (and similar variables) but that they unfold
to SOME name that references the file in question, is open to
misinterpretation and leads to unportable makefiles.

-- 
Henning Makholm                             "... and that Greek, Thucydides"

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Henning Makholm]

Scripsit Riley Williams <rhw@InfraDead.Org>

> Linux-Hams package is inherently Linux specific, GNU make is the only
> version of make used with Linux (as far as I have seen anyway), and GNU
> make (in all versions I have met) correctly expands $(...) as a single
> token wherever it is met.

No it doesn't. If it did, it idiomatic rules such as

binary: $(OBJS)
	$(CC) -o $< $(OBJS)

would not work.


It is even easy to check this:

pc-043:~/foo$ cat Makefile
foo = a b
bar:
        ./echonum $(foo) stop
pc-043:~/foo$ cat echonum
#! /bin/sh
while true ; do
  echo $1
  [ "$1" = stop ] && exit 0 ;
  shift
done
pc-043:~/foo$ gmake bar
./echonum a b stop
a
b
stop
pc-043:~/foo$ gmake --version
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i686-pc-linux-gnu
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
        Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

Report bugs to <bug-make@gnu.org>.

pc-043:~/foo$ 

-- 
Henning Makholm        "Hvorfor skulle jeg tale som en slave og en tåbe? Jeg
                ønsker ikke, at han skal leve evigt, og jeg ved, at han ikke
               kommer til at leve evigt, uanset om jeg ønsker det eller ej."
-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Henning Makholm]

Scripsit "Adam J. Richter" <adam@yggdrasil.com>

> >I'm not sure this is really a bug either. It is a Good Thing that make
> >tries to normalize the names of targets and dependencies internally,
> >lest the build may be incomplete or redundant if make does not realize
> >that foo.bar and ./foo.bar is the same file. It is quite reasonable
> >for $< to unfold to the *canonical* name of the file in question, I
> >think.

> 	That just makes the behavior of make less predictable.
> Whatever make does with the file names internally is its own business.
> Rewriting the file names passed to commands unnecessarily is
> potentially a big problem.

It is not rewriting file names. It is just substituting the name of
the dependency for the $< variable, just as documented.

> >If one absolutely wants the command to use the exact form of the
> >dependency that's used in the dependency list, it's easy to simply
> >reproduce that form, replacing the % by $*

> 	Sorry, I do not understand what you mean.

It wasn't right anyway. I remembered the semantics of $* when the file
name contains slashes wrong.

-- 
Henning Makholm                      "They are trying to prove a hypothesis,
                             they are down here gathering data every season,
                       they're publishing results in peer-reviewed journals.
                     They're wrong, I think, but they are still scientists."

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Paul D. Smith]

If your goal is to avoid GNU make-isms, you've got a long way to go.

Patterns are not portable.

Include is not portable.

Even use of $< in explicit rules is not portable.


If you want to write truly portable makefiles, none of the issues raised
in this post have any relevance to you, since you cannot use any of the
features which may be impacted by it in the first place.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@gnu.org>          Find some GNU make tips at:
 http://www.gnu.org                      http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist