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…
I have tried to run the Python 3 Script which is called ‘reportbug’, and the script errors out with the message, that module ‘_ssl’ cannot be linked to, because it was not provided. This is not a bug in ‘reportbug’, but rather a bug in how the core library of Python 3.7 was built. And, the underscore in front of the ‘ssl’ means, that Python is attempting to import the module from the core C library.
What I’ve learned is, that if I install the package ‘libc6-dev’, the last error message that ‘reportbug’ quits with changes, to ‘Wrong ELF Header’ for the library ‘libc.so’. This error message should only display, if for some reason, Python 3.7 was compiled also to link to the development C library, in addition to the run-time C library. Of course, as soon as I encounter this error message, I remove ‘libc6-dev’ again.
I am inferring that the way most Linux users solve this problem on their ‘amd64′ or their ‘i386′ devices, is just to install ‘libc6-dev’, and then to observe that the problem goes away. But, as this whole posting points out, that set of libraries was never designed to run on an ‘arm64′ CPU. For that reason, Python 3.7 should not be compiled to link to that set of libraries. It should only be compiled to link to the run-time libraries.
But for that reason, on that Tablet’s Guest System, ‘reportbug’ also won’t work.