Icecat on Pine H64
#1
How would I go about compiling GNUzilla/Icecat from source on the Pine H64 on Manjaro ARM?
  Reply
#2
(08-04-2021, 02:24 PM)armuser97 Wrote: How would I go about compiling GNUzilla/Icecat from source on the Pine H64 on Manjaro ARM?

Instructions for Gnuzilla and Icecat can be found here:

https://www.gnu.org/software/gnuzilla/

The link to the git repository is minorly broken but scripts to generate IceCat from Firefox source can be found at:

https://git.savannah.gnu.org/cgit/gnuzilla.git/


Good luck!
  Reply
#3
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.
  Reply
#4
[quote pid="108200" dateline="1647538128"]
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.
[/quote]

I'm wondering if you couldn't statically link build?

Or something as simple as setting LD_LIBRARY_PATH=/path/to/aarchlibs/ before you run build. ie:

Code:
LD_LIBRARY_PATH=/usr/lib/aarch64 make
  Reply
#5
(03-18-2022, 10:25 AM)rgreen Wrote: [quote pid="108200" dateline="1647538128"]
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.

I'm wondering if you couldn't statically link build?

Or something as simple as setting LD_LIBRARY_PATH=/path/to/aarchlibs/ before you run build. ie:

Code:
LD_LIBRARY_PATH=/usr/lib/aarch64 make

[/quote]

Thank you for your reply! Would you mind awfully spelling out what that means (as if I was a 5 year old) ; I’m a NOOB and can follow along/understand but have little idea what certain terms (like “statically link build” or “LD_LIBRARY_PATH”) mean because I feel very much still at the start of the learning curve.

I’m not sure I understand what you mean by “run build” here either because in the context of my previous “guix install icecat” attempts, I could understand that being built/compiled but in the context of my running “./icecat” or “./run-icecat” attempts, I didn’t think there was anything to “build” per se as I had already installed TFP’s pre-built package? Rather, I was expecting the Icecat browser to simply open but then this missing libraries issue popped up.
  Reply
#6
(03-18-2022, 12:03 PM)3460p Wrote:
(03-18-2022, 10:25 AM)rgreen Wrote: [quote pid="108200" dateline="1647538128"]
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.

I'm wondering if you couldn't statically link build?

Or something as simple as setting LD_LIBRARY_PATH=/path/to/aarchlibs/ before you run build. ie:

Code:
LD_LIBRARY_PATH=/usr/lib/aarch64 make

Thank you for your reply! Would you mind awfully spelling out what that means (as if I was a 5 year old) ; I’m a NOOB and can follow along/understand but have little idea what certain terms (like “statically link build” or “LD_LIBRARY_PATH”) mean because I feel very much still at the start of the learning curve.

I’m not sure I understand what you mean by “run build” here either because in the context of my previous “guix install icecat” attempts, I could understand that being built/compiled but in the context of my running “./icecat” or “./run-icecat” attempts, I didn’t think there was anything to “build” per se as I had already installed TFP’s pre-built package? Rather, I was expecting the Icecat browser to simply open but then this missing libraries issue popped up.
[/quote]

gotcha. I didn't catch you had a pre-built package. preamble - I only slightly understand all this but the ldconfig is the related program in linux. run "man ldconfig" if you want to know more.

When you build software you can statically or dynamically link the libraries it uses.  At run-time dynamically linked builds have to go searching the system for libraries and if it doesn't know where to get the libraries it obviously won't find them.

to get around this you can set the LD_LIBRARY_PATH system variable and run the program in the same line.  Something like:
Code:
LD_LIBRARY_PATH=/path/to/you/libs ./icecat
 
But Linus will tell you that is a bad practice.  You should learn and understand how ldconfig does the magic bits.... I'll let you know when I fully grok that too. lol.
  Reply
#7
[/quote]

gotcha. I didn't catch you had a pre-built package. preamble - I only slightly understand all this but the ldconfig is the related program in linux. run "man ldconfig" if you want to know more.

When you build software you can statically or dynamically link the libraries it uses.  At run-time dynamically linked builds have to go searching the system for libraries and if it doesn't know where to get the libraries it obviously won't find them.

to get around this you can set the LD_LIBRARY_PATH system variable and run the program in the same line.  Something like:
Code:
LD_LIBRARY_PATH=/path/to/you/libs ./icecat
 
But Linus will tell you that is a bad practice.  You should learn and understand how ldconfig does the magic bits.... I'll let you know when I fully grok that too. lol.
[/quote]

Eminently comprehensible - thank you! Just to check my understanding: so the “guix install icecat” build method I had initially been trying was a dynamically linked build but could be made statically linked with the “LD_LIBRARY_PATH” approach you suggested? In any case, that would only be useful on a box with sufficient memory resources for me to (cross)compile Firefox*. I had no idea you could run such a static link argument in the same line as a run command for a prebuilt package, I might just give it a try if no other suggestions arise - as you say, Linus would say it’s bad practice, and I’d like to be able to approach this from as good a practice as possible lol.

*In a duplicate of my first post, @wibble suggests cross-compiling on a box with more RAM.

Other than probably being less lazy, what is the benefit of learning how ldconfig works behind the scenes over using ldconfig itself in the manner you describe? Would it risk breaking backwards compatibility/something else, whereas deploying select commands that it performs behind the scenes wouldn’t?

Next question: does ensuring that one has libstdc++.so.6 and libc.so.6 installed somewhere on the system automatically mean that the relevant GLIBCXX and GLIBC versions are also installed? Is there a way to check this, or install them if they’re missing? Despite my searches, I haven’t yet understood which of those versions apply to which point releases of the libstdc++6 and libc6 libraries :S
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  DietPi OS for PINE H64 MichaIng 0 6,506 12-16-2020, 07:22 AM
Last Post: MichaIng
  LibreELEC testing image for Pine H64 Luke 7 11,425 06-12-2020, 02:38 AM
Last Post: p1x3l3d
  Some test PINE H64 “Model B”-3GB, please! stslit 1 3,468 08-25-2019, 12:41 PM
Last Post: stslit

Forum Jump:


Users browsing this thread: 1 Guest(s)