Why does libEGL.tcz in TCL 16.x/17.x require mesa.tcz, but in TCL 15.x not?

[redtyde]

The difference is noticeable in dep files:

For 17.x, http://tinycorelinux.net/17.x/x86_64/tcz/libEGL.tcz.dep:

Code: [Select]

mesa.tcz
wayland.tczThe 16.x one is the same.

For 15.x, http://tinycorelinux.net/15.x/x86_64/tcz/libEGL.tcz.dep:

Code: [Select]

libGL.tcz
wayland.tczand dependencies of the libGL are:

Code: [Select]

libXdamage.tcz
libXxf86vm.tcz
libdrm.tcz
libxshmfence.tczNo mesa is required.

I’m asking this question because the mesa.tcz required in the new version takes up more space, at least 30M adding its dependency llvm22-lib.tcz!

However, I just intend to run an application in TCL, which is considered a sandboxed environment. And I install TCL in VirtualBox without either graphic hardware acceleration enabled or graphic driver installed. The app is built on the electron, which embeds a browser and depends on libEGL forcefully (AFAIK). But it can function normally even if "GLX initialization error" emerged in terminal output (both on 15.x and 17.x). That is to say, this app doesn't rely on libEGL actually, and for me, after migrating to the 17.x version, the mesa is probably redundant and only makes TCL bloat.

Back to the main point, what changes lead to this? The changelog of libEGL

Code: [Select]

Change-log:     2014/02/14 first version
                2014/10/28 updated 9.2.1 -> 10.3.2
                2015/12/17 updated 10.3.2 -> 11.0.7
                2016/08/01 updated 11.0.7 -> 12.0.1
                2017/02/19 updated 12.0.1 -> 13.0.4
                2017/09/14 updated 13.0.4 -> 17.2.0
                2018/03/30 updated 17.2.0 -> 18.0.0
                2019/04/04 updated 18.0.0 -> 19.0.1
                2019/11/11 updated 19.0.1 -> 19.2.3
                2019/11/23 recompiled
                2020/12/06 updated 19.2.3 -> 20.3.0
                2020/12/27 updated 20.3.0 -> 20.3.1
                2022/01/16 updated 20.3.1 -> 21.3.4
                2023/01/12 updated 21.3.4 -> 22.3.3
                2023/04/13 updated 22.3.3 -> 22.3.7
                2025/03/04 updated 22.3.7 -> 24.1.7
                2025/10/16 updated 24.1.7 -> 25.2.5
Current:        2026/05/24 updated 25.2.5 -> 26.0.7only list an array of version codes (also for libGL). The thread about mesa updating in TCE News

Due to changes in the structure of the mesa graphics libraries several graphics extensions have been updated in the tc-16.x x86_64 repo.

only mentions there are changes in the structure of the mesa graphics libraries. So what exactly is it? Can I replace libEGL with the old version to get rid of the large mesa?

[Juanito]

Here's some background: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/12733

I've been wondering if we shouldn't revert to mesa-24.1.7 and the way things were for x86. We could perhaps eliminate the llvm dependency if we assume that nobody uses software acceleration, but if I understand correctly some graphics adapters need that to function.

I don't think we should revert for x86_64 or armhf/aarch64 otherwise we will lose the support for newer hardware.

Mesa aside, the linux kernel no longer supports 32-bit, so perhaps we could consider a "sunset" x86 version with the last lts kernel supporting 32-bit and mesa-24.1.7.

[redtyde]

Oh, looks like this issue has been dragging on for over a year. Thanks for your reply Juanito.

I think if there is no need for rendering, then the entire related part of mesa should not be installed (even mesa.tcz itself is about 10M, idk what includes). You've raised the same concern as I did .

As such, I'll choose to revert libEGL to version 15.x myself for now until the issue is resolved.

[CNK]

I couldn't stand the LLVM dependency either, especially as I also don't really care about GPU acceleration anyway. My solution was to compile Mesa myself and make my own copies of libEGL.tcz, libGL.tcz, libGLESv2.tcz, libexpat.tcz and mesa.tcz. An easier option which still seems to work just as well is to keep using the old Mesa extensions from the last version without LLVM, but maybe that risks breakage with other extensions as they get rebuilt against the newer Mesa.

Both solutions get undone by tce-install, tce-update and tce-audit. I've modified these scripts on my systems to avoid touching extensions and associated .dep files listed in tcz-black.lst in the tce directory, which was only partly implemented before.

The equivalent mesa.tcz extension with only software rendering enabled (softpipe driver) and no LLVM dep is 2.9MB. I'm happy to share these extensions and the build instructions if desired, but I'm not sure how they could be contributed to the repo without replacing the main Mesa extension including GPU drivers.

I've been wondering if we shouldn't revert to mesa-24.1.7 and the way things were for x86. We could perhaps eliminate the llvm dependency if we assume that nobody uses software acceleration, but if I understand correctly some graphics adapters need that to function.

There are two software renderers in Mesa: softpipe and llvmpipe. As the name suggests, the latter requires LLVM, but the former doesn't, so that's the only driver I enabled for my LLVM-less Mesa build (I have needed to use software acceleration in Mesa before anyway, by the way, but not llvmpipe). The drivers for older AMD GPUs apparantly require LLVM, and possibly others. It seems you need to run the configure script and see whether it complains about LLVM missing to tell for sure whether a driver needs it or not.

I don't think we should revert for x86_64 or armhf/aarch64 otherwise we will lose the support for newer hardware.

Unless the extension system were changed to allow alternative dependencies, so eg. either mesa-full.tcz or mesa-min.tcz could fulfill the dependency for mesa.tcz? Other distro package systems do this, and it's a limitation of TC's which frustrates me. Mesa.tcz could be a "meta-extension" which requires "any one of" it's dependencies, with tce-install modified so it knows to ignore the absence of the other dependencies for such extensions.

Mesa aside, the linux kernel no longer supports 32-bit, so perhaps we could consider a "sunset" x86 version with the last lts kernel supporting 32-bit and mesa-24.1.7.

The Linux kernel isn't going that far yet. The current development sources show 32bit x86 is still a build option.

What they have done is remove the M486 build options since Linux kernel v7.1. I assumed Tiny Core would simply build the next x86 release to target the new minimum x86 architecture of M586 and later. I'll be disappointed if x86 is dropped altogether by TC on this weak basis!

[Rich]

Hi CNK

... Both solutions get undone by tce-install, tce-update and tce-audit. ...

I was under the impression that customized extensions will be left
unmolested if they don't include a  .tcz.md5.txt  file.

[CNK]

Hi CNK

... Both solutions get undone by tce-install, tce-update and tce-audit. ...

I was under the impression that customized extensions will be left
unmolested if they don't include a  .tcz.md5.txt  file.

Unfortunately it seems it's been long enough since I battled with this that not only have I forgotten the details, but I've completely forgotten where I saved my notes or what I called them.

So for now I'll just say the answer is no, deleting .tcz.md5.txt isn't enough. The problem was when there's an extension with the same name in the repo, it (or its dep file) still gets replaced with the repo version sometimes. All details forgotten, but they're all recorded very explicitly in a text file I saved somewhere...

[CNK]

OK, "grep 'tcz-black\.lst' *.txt" found the file, with a filename that makes sense now.

Here are my notes on just deleting the .md5.txt files. Basically first tce-install helpfully recreates them, then if you trick it into not doing that the extensions still get replaced when downloading/updating extensions that depend on the extensions without a .md5.txt file. It's a minefield and I spent some time trampling all over it:

Code: [Select]

* Remove [extension].tcz.md5.txt file
  - tce-install will recreate it when installing new extensions that
    depend on that extension and try to fix non-matching checksum.
  - Have to create dummy extensions for deps you don't want installed
    at all, which are used by other version of extensions:
  eg.
        ls -l llvm*
        -r--rw-r-- 1 cnk staff 0 Feb 28 21:50 llvm19-bin.tcz
        -r--rw-r-- 1 cnk staff 0 Feb 28 21:50 llvm19-bin.tcz.dep
        -r--rw-r-- 1 cnk staff 0 Feb 28 21:50 llvm19-bin.tcz.tcz
        -r--rw-r-- 1 cnk staff 0 Feb 28 21:50 llvm19-bin.tcz.tcz.dep
        -r--rw-r-- 1 cnk staff 0 Feb 28 22:16 llvm19-dev.tcz
        -r--rw-r-- 1 cnk staff 0 Feb 28 22:16 llvm19-dev.tcz.dep
        -r--rw-r-- 1 cnk staff 0 Feb 28 21:50 llvm19-lib.tcz
        -r--rw-r-- 1 cnk staff 0 Feb 28 21:50 llvm19-lib.tcz.dep
        -r--rw-r-- 1 cnk staff 0 Feb 28 21:50 llvm19-lib.tcz.tcz
        -r--rw-r-- 1 cnk staff 0 Feb 28 21:50 llvm19-lib.tcz.tcz.dep
   - Then tce-install tries to replace them too!
* Make extension files read-only.
  - permissions of files inside the tce directory get changed at start-up.
* Make extensions symlinks so they don't get replaced
  - symlinks get replaced anyway.
* Add extensions to /etc/sysconfig/tcedir/tcz-black.lst which contains
  regexps for grep.
  - This may work for tce-update, but isn't checked by tce-install or
    update-everything when processing dependencies.

So I decided improving the support for tcz-black.lst in the scripts was the best option.

Also noted:

Patch adding tcz-black.lst support is here:
https://forum.tinycorelinux.net/index.php/topic,21445.msg134335.html