pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Can anybody come with a creative solution to the "/bin/sh: bad interpreter" problem?
On 27 January 2017 at 11:45, Jonathan Perkin <jperkin%joyent.com@localhost> wrote:
> * On 2017-01-27 at 06:45 GMT, Ottavio Caruso wrote:
>
>> I've always toyed with the idea of bootstrapping pkgsrc on my Nexus 7
>> (Android 6.1) and I decided to give it a go.
>>
>> Ive installed the excellent Termux app:
>> https://termux.com/
>>
>> Installed a bunch of packages from the built in package manager apt,
>> finally downloaded pkgsrc via CVS and then proceeded to bootstrap.
>>
>> This is where problems start.
>>
>> Most, if not all, pkgsrc scripta are simple shell scripts that start with
>> the canonical shebang:
>> #! /bin/sh
>>
>> The Android filesystem is a non standard Linux-like filesystem where most
>> executables reside in /system/bin.
>
> This will almost certainly require it to be a separate platform,
> there are just too many hardcoded assumptions about paths in
> mk/platform/Linux.mk and mk/tools/tools.Linux.mk.
>
> If you're able to work on this, it would certainly be a useful
> exercise for us to ensure that scripts are always called using ${SH}
> rather than directly. This should already be the case due to
> historical Solaris /bin/sh being useless, but it may be that usage has
> crept back in as fewer, if any, people are using Solaris 9 or older.
>
> To start with, edit bootstrap and use the set_opsys mechanism to set a
> different OPSYS variable, probably "Android" is sensible, and then
> work from there adding support for Android. It'll be a bit of work,
> but also a lot of fun :)
Thanks Jonathan.
It would be a daunting task and I'm not sure I have the skills for that.
Moreover, there could be a strategic problem with that.
If one has a rooted Android device, they will most likely get around
the issue by creating a /bin directory and make a symlink to /bin/sh.
They might not need a specific toolset of files just for them.
Those with unrooted devices would also have different subsets of tool
to access the compilation environment.
For example the standard (and only) shell on Android is at /system/bin/sh.
Those who use Termux would have a complete subset of tools, usually at
/data/data/com.termux/files/usr/bin/*.
How to handle that?
>
> Off the top of my head the files and packages you'll need to work on
> for starters are:
>
> bootstrap/bootstrap (ensure OPSYS is set to "Android")
> devel/bmake (handle OPSYS==Android)
> pkgtools/bootstrap-mk-files (write *.Android.mk overrides)
> mk/bsd.prefs.mk (handle OPSYS==Android)
> mk/platform/Android.mk (based on Linux.mk)
> mk/tools/tools.Android.mk (based on tools.Linux.mk)
>
Daunting task, at least for me, but I can try and maybe somebody could
take it from there.
I need to know more about the OPSYS variable and where it fits in the system.
I believe OPSYS should be the output of “uname -s. On my device uname
-s defaults to Linux.
Where should it be harcoded to? And how should it be invoked?
I assume it won't be invoked automatically. So therefore could be invoked as:
OPSYS=Android ./bootstrap --unprivileged
?
Or maybe make a separate bootstrap.Android.sh script?
Please all give me 24-48 to tinker with it.
In the meantime, this is what I've done so far, in case one wants to
replicate it (try it on an unrooted device with Android 5 or higher):
Install Termux
apt update
apt install cvs openssh coreutils clang
env CVS_RSH=ssh cvs -q -z2 -d anoncvs%anoncvs.NetBSD.org@localhost:/cvsroot
checkout -P pkgsrc
cd pkgsrc/bootstrap
termux-fix-shebang bootstrap
./bootstrap --unprivileged
--
Ottavio
Home |
Main Index |
Thread Index |
Old Index