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
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.
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).
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.
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.
That took a heroic effort on your part, Eric.
Thank you for your dedication to Slackware!
Be well.
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
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.
Thank you very much for your work! Most of all, keep safe and take care of yourself 🙂
Thanks as always for your hard work, Eric.
Thank you, I installed chromium 81.0.4044.113 on Slackware 14.2
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.
vlc in -alien needs a rebuild against glew 2.2
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.
And there\’s another round (81.0.4044.122), https://chromereleases.googleblog.com/2020/04/stable-channel-update-for-desktop_21.html
I think this is the most stable updates, i\’ve had in such a short period.
Thanks for your hard work!
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
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
Good to know. Slackware is still at glibc 2.30. Either Google patches its code, or I will when it becomes relevant.
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
peebee
The patch mentioned in the bug report you referenced earlier should fix this issue with 32bit Chromium.
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.
Regards
peebee
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: https://bbs.archlinux32.org/viewtopic.php?id=3055 since it’s a crash in the embedded chromium engine that’s part of Qt5’s webengine.
Eric, Thank you for raising:
https://groups.google.com/a/chromium.org/g/chromium-packagers/c/EwWwdXmCcgY
Hope the existing patch for syscalls 403 and 407 can be extended to also cover 422 as glibc-2.33 now seems to need….
Hi Eric
Many thanks for pursuing and implementing the syscall 0422 error patch in 32-bit 89.0.4389.90 – well done!
peebee
Hi Eric
I am getting syscall 0383 errors with yahoo.com – so the saga may not be over……
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**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.
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.
Many thanks Eric – I was going to raise the 0383 problem myself on
https://groups.google.com/a/chromium.org/g/chromium-packagers/c/EwWwdXmCcgY
but see that you have beaten me to it.
I do greatly appreciate your efforts on this – hopefully it will also help 32-bit Slackware users whilst Slackware continues to provide 32-bit builds as well as 64-bit builds.
Thanks again
peebee
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
I have a newer release online now, 81.0.4044.129. Try that one.
That was it! I’ve now got Chromium 81 up and running on Slackware 14.2. Thank you!
BR,
Per
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!
Yeah, qemu is already on my TODO… but I always forget to look there after adding stuff.
No rush Eric, qemu 4.2.0 compiled fine here with nettle 3.6 🙂
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.
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,
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?
A similar error is logged as a bug here: https://bugs.launchpad.net/calibre/+bug/1842344
The developer’s advice is to recompile Calibre when Qt5 is updated. However, Qt5 was not updated and second, the rebuild did not help.
As a test, I rebuilt the qt5 package (same sources, no version bump), but the error in calibre remains.
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.
Thank you Eric. I will test it as soon as possible.