Tuesday, 3 February 2015

Re: [gccsdk] make: File '-c' not found

On Tue, 03 Feb 2015 16:11:23 -0000, Duncan Moore <duncan.moore@gmx.com>
wrote:

>
> On 31/01/2015 16:15, Duncan Moore wrote:
>> On 31/01/2015 13:11, Duncan Moore wrote:
>>> As to why \n is causing problems, I'm not sure. It looks like some
>>> weird
>>> interaction between 'make' and 'printf'.
>>>
>> I'm wondering if it's due to 'make' calling exec() and then the argument
>> list being manipulated. I seem to recall that it quotes both " and '.
>> Maybe it's doing something with the \ of \n too, and that's messing
>> things up.
>>
>
> No, that's wrong. The problem is with 'make'.
> This code is in job.c:
>
> #elif defined (__riscos__)
>
> char default_shell[] = "";
> int batch_mode_shell = 0;
>
> #else
>
> It's not just in the RISC OS version, but in the GNU make version itself.
> If I remove this code (so default_shell becomes "/bin/sh"), then
> everything works.
> For example, this Makefile:
>
> dir :
> @printf '$$(CC) = $(CC)\\n'
> @printf "$$(CC) = $(CC)\\n"
> @printf "$$(sfix) = $(sfix)\\n"
>
> gives:
>
> *make
> $(CC) = cc
> $(CC) = cc
> $(sfix) = c:cc:h:hh:d:o:s:y:cxx:cpp:c++:f:for:fpp:i:ii
>
> With the single quotes printf, the arguments to execvp() are:
>
> printf
> $(CC) = cc\\n
>
> With double quotes printf, the arguments to execvp() are:
>
> /bin/sh
> -c
> printf "$(CC) = cc\\n"
>
> It's any of the characters \$` within double quotes that cause /bin/sh
> to be used instead. What was happening before was that /bin/sh was
> missing, and -c was the first argument, causing the failure.
>
> So we could remove the above code. But it must have been put in for a
> reason. Was it for efficiency? Maybe it was put in before changes were
> made to execvp() to handle /bin/sh -c. Maybe it is required by other
> RISC OS compilers? Does anyone have any ideas?
>
> If there is some reason why the above code is needed in 'make', it's
> possible to modify job.c later on, so that double quotes are handled
> like single quotes. But the above change seems simpler.
>
> Duncan

Presumably it's UnixLib that handles the "/bin/sh" references getting
passed to the RISC OS CLI, is it? If so, knowing the date when that
happened in UnixLib and comparing to the date that code was added to job.c
might give us a clue?

WPB

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

No comments:

Post a Comment