Chromium 81 – and the new build process for Slackware 14.2

Google released version 81 of their Chromium browser sources last week, after spending a lot of effort to bring security patches to the 80.x releases in the weeks before. As said before, Google is going to skip the 82 release entirely because of the staffing challenges resulting from the Corina crisis, and will jump straight to release 83 somewhere mid-May.
I uploaded packages for chromium 81.0.4044.92 a few days ago – but those were only for Slackware-current.

I found it impossible to compile the latest Chromium 81 code on Slackware 14.2 and I had been trying for days. Yesterday I finally succeeded after more than a week of trying since the sources were released. I can not sit behind my computer for long, but that was not too much of a setback in this particular case. I kept running into new compiler or linker errors, then I would think of a fix, set the box to compile again and had to wait for hours to see the result… and lie down in the meantime. For an entire week, I met failure upon failure.

I asked in the chromium-packagers group online, how to fix these issues I was facing – for Chromium 81 and onward, several of the libraries in Slackware 14.2 that Chromium wants, are simply too old.
I was told to try what Google also does when building their own Chrome binaries that are meant to run on a wide range of Linux OS-es: use a “sysroot”, essentially a core set of Debian Sid packages, extracted, tweaked and zipped into an archive. Apparently Chromium code can be compiled in such a way that it uses the Debian shared libraries, but the resulting Chromium binaries (for Slackware in my case) are not depending on these Debian libraries. If someone knows how that works, please enlighten me.

So, I set out to learn how this “sysroot” can be utilized on a Slackware computer. It took another bunch of iterations, but eventually the changes to the chromium.SlackBuild are not even that intrusive. And I produced a working chromium package for Slackware 14.2, only to discover that yesterday, Google released chromium-81.0.4044.113. So, I had to start over.

Anyway – the Slackware 14.2 packages for chromium-81.0.4044.92 have been uploaded for your enjoyment. I am building a new set of Chromium 81.0.4044.113 packages for both Slackware 14.2 and -current, in 32bit and 64bit flavors of course. Hopefully that will run its course event-free and you’ll have those in a day or so.

Enjoy the 81 release!

Eric

31 thoughts on “Chromium 81 – and the new build process for Slackware 14.2

  1. since you asked, my understanding is they would use static compiled libs. Ie. the lib source is compiled into the main program executable. It makes the executable a bit bigger, but as the libs are inside the binary instead of accessing system libs, it should run on anything that can handle the same bit-ness. If it is only done for a few small problem libs, the rest being linked dynamically (at runtime) the results are a program that works without getting too big.
    thanks for all your work eric, and I trust your health issues improve. I had to work for a couple years on my back, and a laptop to vnc/ssh into my other computers was a saviour. I found an external keyboard and mouse was esential, and a frame to support the weight of the laptop was also needed.


    1. I compared the package sizes of Chromium 81 compiled using a Debian sysroot on 14.2 and the package for -current which did not require a sysroot. The one built on -current actually was a bit bigger: 73792004 versus 73199928 bytes.
      Several of the packages in my own repository use statically compiled libraries to minimize or eradicate external dependencies (vlc, libreoffice, ffmpeg, calibre to name a few) but these internalized dependencies first have to be built statically. Looking at the extracted Debian sysroot image, it is indeed full of static libraries (*.a). Pity… that will make it hard if not impossible to try and create a sysroot image built from Slackware-current packages (Slackware does not ship static libraries as part of its packages by default).


      1. yes. a shame since the switch to remove .a files, those type of work-arounds are harder to implement, without changing all the slackbuilds back to how they were… roll on slackware 15! hopefully now we have a LTS v5.x kernel in current it will come out soon, and these problems will be history.


  2. Thank you Eric. I installed your first -current 81 package yesterday and everything was fine.
    You said that you cannot sit in front of the computer for long. I hope you’re doing OK and if not, get well soon.



  3. Thanks for all that hard work!

    I didn’t get this update until you already had .113 loaded.

    It’s working great on Slackware64 14.2.

    I hope you get over whatever it is forcing you to take regular naps. To get you through those horizontal moments, maybe put on what I’m listening to on 81.0.4044.113 as I write this, if it’s your style: Stabat Mater/Pergolesi, Hymn of the Cherubim/Tchaikovsky, Miserere Mei, Deus/Allegri, and Matthäus Passion – Erbarme dich/Bach. I started on Bach and let Youtube guide me to the rest.

    TKS


  4. Hope you heal quickly! I had a back injury a few years ago, and while it’s better, sometimes it still hurts. Back injuries just suck.



  5. Pingback: Links 18/4/2020: Linux 5.8 Plans and Darktable 3.0.2 Released | Techrights



  6. It should be theoretically possible to move callable functions from one ELF file to another. I.e. repackage the contents of shared libraries into one or more other shared lib(s).
    Since an executable binary is also just an ELF file, one could integrate all dynamically linked libraries into the executable itself. Or – even better – only the necessary subset of actually called functions.
    Technically the linking would still stay dynamic (using symbol table lookups instead of direct jump instructions), but from the outside it would just look like static linking.

    “statifier” seems to do exactly that: http://statifier.sourceforge.net/statifier/main.html

    I’ve got no idea what the chromium build really does, but the concept seems to work.



    1. I do not like nameless internet trolls.
      Also, I am currently running VLC without problems on an uptodate Slackware64-current which contains glew-2.2. So, where’s the issue?
      Your statement ‘vlc in -alien’ is so generic, I am not going to spend more time on it.



  7. Eric
    A quick thank you for Chromium 81, which I’ve installed on 14.2 with no problems.
    I am using it to do many teleconferences using Jitsi-meet. Works flawlessly
    in contrast to several other current browsers.
    Great work.

    Steve


  8. Hi Eric
    Just a heads up that there is an Aw Snap! issue with 32-bit Chromium when used on systems with GLibc-2.31
    https://github.com/OSSystems/meta-browser/issues/357
    describes the issue and provides a patch.
    The issue is apparently that there are changes in GLibc-2.31 that the Chromium code is unable to deal with.
    Just to forewarn you for the future….
    Cheers
    peebee



  9. Hi Eric,

    on my Slackware 14.2 I tried “installpkg chromium-81.0.4044.122-x86_64-1alien.txz”. I get errors “GLIBC_2.27”, “GLIBC_2.29”, “GLIBC_2.28” not found though. Checking with ldd shows “GLIBC_2.23”, which I think is what comes with 14.2. Did I miss something obvious here?

    BR,
    Per




  10. Hi, sorry for hijacking an unrelated post but I wasn’t where to report this.

    The last updates to -current upgraded nettle to 3.6 and there was a .so bump from libnettle.so.7 to libnettle.so.8, which breaks your qemu package.

    Silly me, didn’t notice before upgrading :/ so I’m downloading your sources to make a new package for myself.

    Also, there’s a very recent qemu 5.0.0 in case you want to upgrade to this version directly instead of just recompiling qemu 4.2.0.

    Cheers!




  11. On my machine, calibre fails to convert epub to pdf, complaining about

    /usr/lib64/calibre/python2: symbol lookup error: /usr/lib64/calibre/calibre/plugins/libheadless.so: undefined symbol: FcPatternCreate

    Not sure it is not a particular problem on my machine, but there has been a huge python update recently. Just thought you may want to know if you use this calibre feature.


    1. The python2 in my calibre package is an internal version, accompanied by various the python modules that Calibre needs. This should be independent of what happens to the system-wide python.
      But I see the same issue here on -current.
      No idea what happens here and no time to do the research needed for this, so I will wait for someone to provide a solution or patch. Perhaps recompiling will ‘just’ fix this,


      1. Unfortunately upgrading/recompiling calibre on -current did not fix this symbol lookup error. Suggestions are welcome.
        The calibre package for Slackware 14.2 (into which I compiled the Qt5 dependencies instead of relying on system libraries) does not show this error. Weird?




          1. In the end, I compiled a new calibre package with all the Qt5 related libraries built-in. This makes the package size increase considerably, but at least now the PDF conversion works again and the library error is gone.
            I still can not explain why this is an issue when using Pat’s system libraries for Qt5.



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.