Re: Starting /bin/sh in output configure file

[R0b0t1]

On Thu, Jul 13, 2017 at 11:24 PM, Russ Allbery <address@hidden> wrote:
> R0b0t1 <address@hidden> writes:
>
>> A hardcoded binary path isn't portable, the correct solution is to use
>> `env sh`. Typically this is seen as:
>
>> #!/usr/bin/env sh
>
>> Which technically causes the same problem Mr. Akhlagi was
>> experiencing, but on most desktop Unixes the location of `env` is more
>> predictable than the location of various interpreters.
>
> I am extremely dubious that the location of env is more predictable than
> /bin/sh.  python or perl or whatnot, yes, but not /bin/sh, which is
> probably the most hard-coded path in UNIX.
>

Yes, that's why I mentioned it. He could just call `env` but at the
same time he can also just call `sh`.

> But more to the point for this specific request, it would surprise me a
> good deal if Android would move sh and not also move env to some other
> directory than /usr/bin.  If you're going to break compatibility that
> much, it's unlikely you're going to keep compatibility for env.  But,
> well, I've been surprised before....
>

I agree, with the added comment that it's probably not wise to
consider Android to be a flavor of Unix. It actively prevents you from
using your hardware for general purpose computing and has a set of
very restrictive design goals.


To OP:

It is my personal opinion that you should give up on whatever it is
you are trying to do, Mr. Akhlagi, and try to use a normal Linux
distribution instead of Android and set up a cross compiler for your
system. Even then you will run into problems as autoconf and its tests
were not necessarily designed to support cross compilation.

This leaves you in the position where you are doing what you are now,
trying to compile things on device, which can take multiple days for
large software packages. If you are interested in the ARM architecture
I suggest finding a low cost server. I can reply with an example
(perhaps the only example) if you want, otherwise I'd just as well
leave the link off of the list.

If you want to continue as you are I suggest you will get more out of
researching the changes Android made to Linux than you will out of
following up with each project you experience issues with. The Android
system architecture description has a list of changes in it and what
they break, which is essentially everything.

R0b0t1.