(03-17-2022, 11:28 AM)3460p Wrote: I’m not able to speak with any degree of authority on this so take this with my advice to double check it but so far as I understand from unix and RPi stackexchange discussions on performing the above operation as mentioned by @rgreen, 3Gb is nowhere near enough RAM and even IBM’s machines take ~7H to compile Firefox from source so realistically we’re not going to be able to on the H64, PinePhone, RPi etc.
From my own adventures trying to get Icecat running on the PinePhone, I followed advice given in the stackexchange posts to install GUIX over the OS I’m running on the PinePhone (Mobian), then run “guix install icecat” - this after having already tried the savannah build script route, which also failed - but after a few hours the phone has run out of battery and shutdown, even though it’s charging from the keyboard case. Even after configuring 1.5Gb of ZRAM, it still wouldn’t work - and I monitored the Usage app (scrolled down so that displaying the CPU usage graphs wouldn’t add to the load), which showed both the 2.9Gb RAM and the 1.5Gb ZRAM maxing our after a while and freezing up the system. So this experience at least anecdotally validates the requirements described in the stackexchange posts. That being said, I haven’t tried the compilation varying the ZRAM config between a min. of 10% and a max. of 250% but I figured a more appropriate route might be to see if there was an Icecat package precompiled for aarch64 / arm64.
Varying my DuckDuckGo search terms led me to discover that The Fedora Project has Icecat packages precompiled for aarch64 as RPMs. I installed Alien to enable me to convert from .rpm to .deb, then downloaded the main Icecat package from TFP’s repository, as well as the -X11- and -Wayland- packages (just in case they were also needed). Once converted, I tried installing them and that appeared to work so far as generating the Icecat logo in my apps list (actually three - one for each of the packages). However, tapping on any of the Icecat logos wouldn’t load anything so I tried launching Icecat from the command line, from within the Icecat directory (found at /usr/lib64/icecat), with “./icecat” and “./run-icecat” when that failed.
Both of these attempts failed for ostensibly the same reasons:
libstdc++.so.6 versions GLIBCXX_3.4.29 and GLIBCXX_3.4.30 were not found but are required
libc.so.6 versions GLIBC_2.33 and GLIBC_2.34 were not found but are required
Following advice in more stackexchange posts, I tried to locate these libraries on the system with “dpkg -L libstdc++.so.6”, for example, but received the message “package is not installed” - which is strange because when I then double checked by flicking through different directories in the GUI Portfolio app, I found entries for it under /usr/lib/aarch64-linux-gnu/ and under /lib/aarch64-linux-gnu/ . Indeed, when I tried running “sudo apt-get install libstdc++6” and “sudo apt-get install libc6”, both gave me that they were already installed as newest versions (libstdc++6 10.2.1-6 and libc6 2.31-33+deb11u2).
So, further searches seem to indicate that people are resolving similar library issues with symlinks but there was also a suggestion in the Ubuntu forum that this is not the correct way to go about such an issue as it may break some backwards compatibility measures.
Does anyone have any further suggestions? This feels tantalisingly close to working so would really appreciate getting this over the line!
N.B. I’m running a few weeks’ old build of Mobian from a 512Gb microSD card, rather than from the eMMC, don’t know if that’s important to mention.
Rather than write this out again, I’m quoting it from where I posted previously, but creating a thread of it in the Mobian on PinePhone section of the forum (where it is perhaps more relevant) in the hopes that it gains some more views and advice for a solution.
Thoughts?
IIRC the gentoo build process does an early test for >=4GB RAM before attempting to compile the major browsers, and even then you'll run into heavy swap use. You can probably either build natively with something like an 8GB Pi4, or crosscompile on a more capable x86_64 machine which is almost certainly how the mobian packages are built. That should allow you to build a package with all the correct dependencies to run.
https://wiki.debian.org/CrossCompiling
03-19-2022, 12:01 PM
(This post was last modified: 03-19-2022, 12:05 PM by 3460p.
Edit Reason: Mentioning RPi build limits described on stackexchange
)
(03-19-2022, 05:44 AM)wibble Wrote: IIRC the gentoo build process does an early test for >=4GB RAM before attempting to compile the major browsers, and even then you'll run into heavy swap use. You can probably either build natively with something like an 8GB Pi4, or crosscompile on a more capable x86_64 machine which is almost certainly how the mobian packages are built. That should allow you to build a package with all the correct dependencies to run.
https://wiki.debian.org/CrossCompiling
Thank you for your reply!
I appreciate the concept of (cross)compiling and after a quick skim of your link, don’t feel like I would have too much difficulty following along if I can already follow native, on-target compilation instructions, however what I’m really not sure about is how I would then transfer the build from the build box to the PinePhone - would it be as simple as copying a single package (or entire build directory?) to a USB and then from there to the PinePhone via a hub? The only other device I have with a Linux environment is a 8Gb RPi 4 but was discouraged from trying to compile on that by stackexchange posts stating that 16Gb RAM with 8Gb ZRAM swap was needed.
Is this the only realistically “correct” way to go about getting Icecat on Mobian on PinePhone, or are there some further, non-symlink steps I can take with the approach I took installing the prebuilt package from The Fedora Project?
I would aim to build a debian package, so you would copy over the .deb for icecat and install it, or even host your own package repository. Mobian has some hints on the package build and crosscompile process as apparently some options are buggy:
https://gitlab.com/mobian1/wiki/-/wikis/...e-packages
I assume you'd be starting with an existing project for packaging icecat for debian, like https://github.com/losuler/icecat - I suppose you could ask them to add an aarch64 target to their OBS build system. Whether it builds cleanly for aarch64 is another matter...
04-21-2022, 08:54 AM
(This post was last modified: 04-21-2022, 09:07 AM by 3460p.
Edit Reason: Further details
)
(03-20-2022, 08:13 AM)wibble Wrote: I would aim to build a debian package, so you would copy over the .deb for icecat and install it, or even host your own package repository. Mobian has some hints on the package build and crosscompile process as apparently some options are buggy:
https://gitlab.com/mobian1/wiki/-/wikis/...e-packages
I assume you'd be starting with an existing project for packaging icecat for debian, like https://github.com/losuler/icecat - I suppose you could ask them to add an aarch64 target to their OBS build system. Whether it builds cleanly for aarch64 is another matter...
I’d be tempted to go with your latter suggestion as I don’t think I’m near the point of hosting my own package repository yet so I will contact them but I can’t help feeling there must be a simpler, yet equally “correct” approach.
I say that not just because I’m hoping for something quicker which anyone else could easily replicate if they wished, but because I have just tried my previous Alien approach again on a fresh Mobian install (latest release) with a slightly different result:
If I simply run “icecat” from the /home/mobian directory, the only library error I get now is the one about
/lib/aarch64-linux-gnu/libc.so.6: version ‘GLIBC_2.34’ not found (required by /usr/lib64/icecat/icecat)*
*this changes to “(required by ./icecat) if I try running “./icecat”, or to “(required by ./icecat-bin)” if I try running “./run-icecat.sh”, from within the /usr/lib64/icecat directory.
I successfully installed and ran Icecat on Fedora from Megi’s multiboot installed on my eMMC before I ever tried Tow-Boot. So as a NOOB it feels like I should be somehow able to add whatever “it” is that Fedora has to my Mobian install to enable Icecat to run correctly on Mobian. I presume that “it” is this GLIBC_2.34 that my Mobian install complains about not being found...
Interestingly, in my Mobian install, GNOME Software recognises that I have manually added GNU IceCat “manual:local (deb)” along with a bunch of information such as that the package has a ~3.6 star rating from 43 reviews, a couple of screenshots and detailed description - but then declares it to be “Potentially Unsafe” because it’s “Provided by a third party” with “Proprietary code” and that “The source code is not public, so it cannot be independently audited and might be unsafe” !!!
I thought the point of GNU IceCat was that it was a rebranded version of Firefox where the GNU Project has stripped away any/all trackers and proprietary code that Mozilla has introduced?!
Seems like the sort of solution I’m looking for might be found on jertype.com so I’ll give it a try on a new install and see how it goes, then update here.
I’ll also see what trying out the advice in responses to Stackoverflow question “How to upgrade glibc from version 2.13 to 2.15 on Debian?” gets me.
if you aren't married to debian-based distros, an easier way might be to use the AUR ( https://aur.archlinux.org/packages/icecat) on Arch/Manjaro
it would look something like
git clone https://aur.archlinux.org/icecat.git
cd icecat
makepkg -As
pacman -U icecat-<version>.tar.xz
It's 'potentially unsafe' because it hasn't come from a known repository so can't be checked for a valid signature or checksum by the package manager. Anyone could make a package claiming to be icecat and make it available for download, but unless they were using a repeatable build system (which most don't) it's hard to be sure that the binary was build from the source it claims it was, was modified somehow, or is a flat out trojan. If it _was_ built with a repeatable build system then you need to build it yourself to check. In your case you've made it from a different package format from another reputable source, but the package manager doesn't know that so it gives you a warning.
The workaround described at https://www.jertype.com/upgrading-glibc/ might work if you're lucky with the rest of the dependencies, but that page notes it's not a preferred solution.
I hadn't previously spotted the docker images Mobian provide for easier crossdev packaging:
https://gitlab.com/mobian1/wiki/-/wikis/Crosscompiling
04-28-2022, 08:00 AM
(This post was last modified: 04-28-2022, 08:30 AM by 3460p.)
(04-23-2022, 02:21 PM)clover Wrote: if you aren't married to debian-based distros, an easier way might be to use the AUR (https://aur.archlinux.org/packages/icecat) on Arch/Manjaro
it would look something like
git clone https://aur.archlinux.org/icecat.git
cd icecat
makepkg -As
pacman -U icecat-<version>.tar.xz
Haha thanks for the suggestion but for the moment I’m trying to get Mobile Debian working for me the way I want it. I’ve tried Manjaro before and made use of the AUR but didn’t enjoy it as much as Debian. If I return to being a “I use Arch btw” user then I’ll definitely make use of IceCat from the AUR!
(04-25-2022, 03:53 AM)The wibble Wrote: It's 'potentially unsafe' because it hasn't come from a known repository so can't be checked for a valid signature or checksum by the package manager. Anyone could make a package claiming to be icecat and make it available for download, but unless they were using a repeatable build system (which most don't) it's hard to be sure that the binary was build from the source it claims it was, was modified somehow, or is a flat out trojan. If it _was_ built with a repeatable build system then you need to build it yourself to check. In your case you've made it from a different package format from another reputable source, but the package manager doesn't know that so it gives you a warning.
The workaround described at https://www.jertype.com/upgrading-glibc/ might work if you're lucky with the rest of the dependencies, but that page notes it's not a preferred solution.
I hadn't previously spotted the docker images Mobian provide for easier crossdev packaging:
https://gitlab.com/mobian1/wiki/-/wikis/Crosscompiling
Oh sure that I get but the “proprietary software” part?!
The most complete post I’ve found on the subject of installing more recent GLIBC libraries alongside that packaged in your distro is a post on Ubuntu forums (the link to which I will provide later when it’s in front of me) but I did go with the workaround on jertype.com :
I compiled GLIBC_2.34 in /opt and used the LD_PRELOAD argument to get IceCat’s libc.so.6 to use it from that directory but a few more errors then popped up, one of which was about libm.so.6 requiring GLIBC_2.35.
So I performed the same steps as described on jertype.com for that and used LD_PRELOAD again to get IceCat’s libm.so.6 to use it from the /opt directory and a few moments later IceCat was running!
Now I just need to figure out how to get IceCat to always look in /opt for those two dependencies so that it also launches when tapping the app drawer icon (currently IceCat only launches from the CL and only if I prefix it with the LD_PRELOAD argument).
Of course I understand that this is the less-preferred option but short of finding a native aarch64 build (which Ubuntu might have?), I think it’s really the best option for me at the moment.
Docker is on my todo list for things to learn! Funnily enough I’d tried searching “Mobian Docker” in DDG but that didn’t jump out at me from the results... I suppose another option could be running it in a VM via PiMox, for example, or via the F-Droid store on Waydroid.
You can edit the icecat .desktop file so that it launches with the LD_PRELOAD. It may be easier to use a wrapper script to launch it than to figure out exactly what you'd have to do to the exec line, but check the docs:
https://specifications.freedesktop.org/d...-variables
|
