## Whether it would be fair to expect, that the Debian libc6-dev package work, on an ARM-64 CPU-based device.

One of the facts which I had posted about before was, that I had installed Debian 10 / Buster on a Google Pixel C Tablet, not because that tablet has any special properties, but just to document that with that one specific configuration, the solution ‘works’. And I had gotten to the subject of wanting to install ‘libc6-dev’, which would normally install Development Libraries, on top of Run-Time Libraries, with the ultimate intention of being able to compile or custom-compile C or C++, from in front of this ARM-64 -CPU Device, for use on the same device. And even one major Debian Update later, from 10.0 to 10.1, this facility still doesn’t work.

What I’d like to comment is the idea, that this is not a fair expectation, and that the naming of these packages cannot always be expected to remain canonical. What this expectation would assume is that the general-purpose GNU Compiler will work, even though that compiler is highly optimized for targeting code that runs, either on ‘amd64′ or ‘i386′ architecture, in that order.

If the goal really was, to compile code from in front of an ARM-64 -based machine, to run on it, then a compiler would need to be selected which is meant to target the ARM-64 CPU, and this might involve installing the correct cross-compiler, even though it’s to be executed on an ARM-64. The fact that an ARM-64 version of ‘libc6-dev’ is available, really just stems from the rather nonsensical idea, that the compiler using it should run on an ARM-64, but that the linked code should not.

And then, if one has installed the correct cross-compilers, because those packages are available in ‘arm64′ versions, they will run in spite of being named cross-compilers, and then installing them will also pull in the correct development libraries. Only then, in order actually to compile anything, one would need to specify yay-long commands from the command-line. And the main reason I’ll have none of this, is the simple fact that entering many non-standard ASCII characters using an Android-oriented keyboard, does not appeal to me for the moment.

This is similar to why I don’t install ‘Web-development software’, that is compiled and available from the repositories, but that would require a long sequence of special characters to be typed in, in order to allow any sort of Web-development. And it remains consistent with having LibreOffice installed, where what gets typed, is consistent with the English language, just as what the Google Pixel C’s OEM Keyboard offers, is…

There’s an added level of weirdness that would result, if somebody was just to write and compile C or C++ to run on an ARM-64 CPU in that way: The resulting binary wouldn’t be Android-compatible. It would assume that the O/S is Linux, but with an ARM-64 CPU, just like the Guest System. Writing Android-compatible code would require, that the ‘Android Development Kit’ be installed. Due to cross-compiling by the Debian package maintainers, there just might be ‘arm64′ packages of that available, but again, with no further guarantee that it all works…

(Update 9/08/2019, 10h20 : )

Unfortunately, this recognition does not negate the fact, that the way certain packages have been compiled to run on an ARM-64 CPU, still contain a bug…

## Major Problem when Upgrading a UserLAnd Linux Guest System via ‘apt-get’.

A fact which I had blogged about before was, that I had installed a Debian 10 Linux Guest System on the Android, Google Pixel C Tablet, using the Android app ‘UserLAnd’. This Debian 10 version was compiled by the package maintainers to run on an ARM-64 CPU.

Well, along with major updates to Debian 9 / Stretch, the Debian maintainers have just issued an update to Debian 10 / Buster, from version 10.0 to version 10.1 . The problem? When trying to perform the upgrade via ‘sudo apt-get’, the process hangs over the attempt to update or install ‘systemd’, and then configure it. Apparently, doing this requires full root privileges, because ‘systemd’ would normally control how services run in the background with ‘root’, but UserLAnd does not allow any part of its Guest System to run as ‘root’.

This could become a stumbling-block, in any future updates.

The ‘solution’ which I attempted to apply was, to remove everything that depends on ‘systemd’, and to re-apply the upgrade in total. But the net effect of that is, to remove many more packages than I intended to remove, including all things related to ‘Gtk 3′, ‘LXTerminal’, as well as key components that allow ‘LXDE’, the Lightweight Desktop Manager, to function at all.

Caution: This would have been a completely unsafe thing to do on a real computer, and was only plausible because the setup in question was virtual in some way, and also expendable. This would normally brick the computer…

When the makers of UserLAnd provided easy screen-shortcuts to install Debian and LXDE, they knew how to modify the installation script, to ignore whatever problems result from installing LXDE and its dependencies in a ‘proot’ed environment. But I don’t know those tricks. (:1) So at one point I had a partially gutted system, without LXDE really installed.

But the (Android) devs behind UserLAnd also provided a quick workaround for that problem. The next time I exited the corrupted session, and re-launched LXDE from the UserLAnd menu, this Android app recognized that LXDE was no longer installed, and simply reinstalled it for me, after which I could access it again.

Once I had done this, my wallpaper was a black background, and quite a few of the installed applications were no longer installed. And so what I needed to do next was, to run the equivalent of the following command:


$sudo apt-get install gnome-backgrounds clipit evince wxmaxima gcl firefox-esr libpam-cracklib   After having done this, I was able to select a wallpaper again, from the file chooser, and to regain most of the abilities I already had before. I might still be missing some of the applications I once had. But what all this suggests is, that the Linux Guest System should only consist of a vest-pocket system, with a small number of applications, because in reality any and all Linux applications may simply need to be reinstalled at some point in time. But, there is a way in which users are not ‘hosed’ if this happens: Linux still segregates its data into a system directory, and a user home directory. Even though we have no form of access control within a ‘proot’ed system, even if certain applications are removed from the system directory, and then reinstalled there, our home directory will remember all our personal settings and data. So the solution can be as quick as the initial disaster was. My Linux Guest System is now down to taking up 4.86GB of Android application-data. (Updated 9/09/2019, 16h15 … ) (As of 9/07/2019, 20h00 : ) I think I’ve gotten closer to finding out, what went wrong… ## I now have Linux installed on my Google Pixel C tablet. As the title of this posting suggests. I used the Android app “UserLAnd“, which does not require root. The most recent versions of this app offer a VNC Server, which emulates an X-Server within the Linux system. And the implementation of VNC is ‘TightVNC’. Plus, the latest versions of this app offer a built-in VNC Viewer, that I find makes the most, out of the tiny icons that display on the high-res screen, as well as out of the fact that often, users will want to operate the GUI with their fingers, along with the physical keyboard that my Pixel C pairs with (:7) … The setup of this Linux Guest System is much easier than my earlier experience was because the basic Linux distribution, the desktop manager, and certain apps can all be installed just by tapping on a few icons. And then, using the ‘sudo apt-get’ command-line, additional Debian packages can be installed. There is an interesting side effect to this project: When I give the command:$ cat /etc/debian_version

I obtain the result ‘10.0‘. This would mean that the Linux version which I’m getting, is the new Debian / Buster, which none of my PCs nor my Laptop are even running. However, the repositories that I’m subscribed to are labelled ‘stable’. The CPU is an ‘arm64′. And the desktop manager I chose was ‘LXDE’. I installed a full productivity suite, including LaTeX. But, I found that three Linux applications did not run:

• LyX – The graphical, WYSIWYM LaTeX Editor (:2).
• Synaptic – A GUI for apt-get that makes it particularly easy to browse package-repositories, before selecting which packages to install.
• Latexdraw‘ (:1) (:6).

Everything else I tried seems to work, including “LibreOffice”, “GIMP”, “InkScape”, “Firefox ESR”. On my own, without the aid of simple GUI-buttons, I was also able to install and run “Texmaker”, “Dia”, “Xfig”, “OpenClipArt”, “Maxima” and “wxMaxima”, the Computer Algebra System and its Graphics Front-End. Getting that last item to work properly actually required that I install the package ‘fonts-jsmath’.

The Linux Guest System is currently taking up 5.37GB of my internal storage, and I finally also found out how to share files between the Guest System and the Host System. Within the Guest System, if on the Host System the root of the user folders is ‘/root/<sdcard>’, then this Host System root is mounted at ‘/host-rootfs/<sdcard>’ (within the Guest System). This means that I can open a path directly to this folder in the file-manager ‘PCManFM’, and bookmark it. (:3)

(Updated 9/07/2019, 17h40 … )