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!


40 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.


  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:

    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.


  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
    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….

      1. Hello Eric
        The recent Slackware Current update to glibc-2.32 triggers this problem with 32-bit Chromium builds.
        Hope you are able to find and apply a fix.
        It can be suppressed by including the flags:
        –no-sandbox -test-type
        but this is a “less secure” way to run….
        Many thanks

          1. Hi Erik
            Just to report that your 32-bit version of chromium-88.0.4324.182 when run on Current under glibc-2.33 produces the dreaded “aw snap” that you managed to eliminate with glibc-2.32.
            It can be suppressed by including the flags:
            –no-sandbox -test-type
            but this is a “less secure” way to run…. so much so that Google websites refuse to work.
            Thanks for all you do.

        1. I have not been able to find a fix for the “Aw, snap” error and crashes in 32bit Chromium when running on a system with glibc-2.33. Maybe it is the end of 32bit Chromium on Slackware. If you find something relevant online let me know. I thought I was using the same glibc 2.33 patches that Fedora, Arch are also using.

          Perhaps this crash report in qt5-webengine (which shows the same syscall 0422 error I am getting) is relevant: since it’s a crash in the embedded chromium engine that’s part of Qt5’s webengine.

          1. Hi Eric
            Many thanks for pursuing and implementing the syscall 0422 error patch in 32-bit 89.0.4389.90 – well done!

          2. Hi Eric
            I am getting syscall 0383 errors with – so the saga may not be over……

            ../../sandbox/linux/seccomp-bpf-helpers/**CRASHING**:seccomp-bpf failure in syscall 0383
            Received signal 11 SEGV_MAPERR 00000497717f
            #0 0x00005a41202f (/usr/lib/chromium/chromium+0x3e6f02e)
            #1 0x00005a3719d2 (/usr/lib/chromium/chromium+0x3dce9d1)
            #2 0x00005a411c6a (/usr/lib/chromium/chromium+0x3e6ec69)
            #3 0x0000f7f68570 ([vdso]+0x56f)
            #4 0x00005bf6d2ec (/usr/lib/chromium/chromium+0x59ca2eb)
            #5 0x00005bf6d04a (/usr/lib/chromium/chromium+0x59ca049)
            #6 0x0000f7f68570 ([vdso]+0x56f)
            #7 0x000000000000
            gs: 00000063 fs: 00000000 es: 0000002b ds: 0000002b
            edi: 0000017f esi: ffbb35b0 ebp: ffbb3598 esp: ffbb3580
            ebx: 600912c8 edx: ff9999c8 ecx: 0497717f eax: 00077000
            trp: 0000000e err: 00000006 ip: 5bf68c18 cs: 00000023
            efl: 00210202 usp: ffbb3580 ss: 0000002b
            [end of stack trace]
            Calling _exit(1). Core file will not be generated.

          3. Either someone is going to have to chase this and come up with a patch, or I am going to drop 32-bit Chromium. I don’t use this myself and it costs me lots of time to pressure Chromium devs into action – only for the benefit of Puppy Linux.

  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?


  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 to, 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.


  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/ 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.