Strange redirect problem with gnumake

I have a system in which I generate a makefile and which works perfectly under Mac OS X. When I run it under Linux, I get a strange problem. I managed to reduce my makefile to a very simple example:

    compile:
        gcc -o prog *.c &> compile__

    chm:
        chmod u=rwx,g=rwx,o= prog

    both0:
        gcc -o prog *.c &> compile开发者_StackOverflow中文版__ ;  \
        chmod u=rwx,g=rwx,o= prog

    both1:
        gcc -o prog *.c ;  \
        chmod u=rwx,g=rwx,o= prog

The idea is to compile a file and then change its permissions. If I execute the command sequence:

    make compile
    make chm

everything works fine. However if I execute:

    make both0

I get the message:

    chmod: cannot access `prog': No such file or directory

and the permissions are not changed. On the other hand if I execute:

    make both1

the permissions are changed properly. The only difference is the redirection "&> compile__" under both0 which I removed for both1.

Any ideas?

&> compile__

is not a portable redirection. In bash, it redirects both standard error and standard output, which I assume is your intention. Other shells are likely to do different things with it. In particular, dash backgrounds the command (the &), and redirects standard output (the > compile__). The chmod is executed before the compile finishes and creates prog. Redirecting both standard error and standard output can be done portably with cc -o prog *.c > compile__ 2>&1.

(Why did it work on the mac? Possibly a different shell that interprets &> differently, possible the compiler opening the file earlier, possibly a race condition coming out slightly differently.)

An alternate solution is to specify the shell for GNU make to use. Section 5.3.1 of the manual has information on this. For instance, the following

export SHELL=`which bash`

In a Makefile seems to get Gnu Make 3.8.1 on Ubuntu/Debian to choose bash as the shell.

Other issues are differences in the behaviour of all the shell built-in's, like echo, printf, test, etc. Esoteric options to these built-in's may mysteriously fail when run under make on Debian based systems.