Tiny Core Extensions > TCE Talk
FLTK 1.4 for TC 16
hiro:
--- Quote from: polikuo on February 06, 2025, 09:50:39 AM ---Would you mind elaborate a little more on that ?
--- End quote ---
What I said was already extremely verbose tbh. It's better documented by others. The keyword is "static linking". I knew multiple people who pride themselves with "knowing the people who invented dynamic linking", and it's hard to even discuss static linking with them. GNU folks with their dependence on glibc seem to be intent on freeing you from the big burden of having to chose between static and dynamic linking. Personally, I don't think increasing the scalability of dumping many more features and thus megabytes into each of your program's dependencies (thus dll) is not as important. Careful curation of dependencies is necessary, and if done correctly will result in very small statically linked applications.
The idea that everything has to grow exponential ad infinitum is flawed. And thus I do not like the currently super vogue super optimized runtime dynamic linking frameworks meant to enable this.
"So that we can know the benefits." mainly here it's about managing the downsides. that's my personal takeaway from modern programming trends. more is offered than anybody needs, which makes everybody crave for less, or at the very least (these people are unable to see they should agree with me) nothing (they have given up on humanity mostly).
"I'm a hobbyist at best in programming" As long as it's fun I don't think you can commit atrocities like they do professionally. If they did more like you, I think their life would indeed also be more fun.
"Will that break anything ?" No clue? i know very little about recent advances in fltk, sorry.
Last time I spoke about this I asked if tc will upgrade fltk bec. I hoped this would enable utf-8 support, but I learned fltk folks back then (loooong time ago) made a regrettable release according to the typical pattern of second system syndrome. Curiously it seems they noticed and admit the error, which is very emotionally strong and professional behavior.
My take-away here was to live with the lack of utf-8 as it's the lesser evil in comparison to the amount of unmanageable change the alternative would introduce. I think the logic might be still applicable in your case, but not sure :)
hiro:
--- Quote from: Rich on February 06, 2025, 11:41:15 AM ---Static linking allows a program to not be dependent on
which library version is present. The cost is a larger
program because needed functions are compiled in.
--- End quote ---
Beautifully dry and concise. Thank you :P
Juanito:
To give some background to this, for xorg and wayland to work, mesa needs to be compiled against them.
The current mesa (Xorg*-3d, libEGL, libGL, libGLES*) status is:
x86: xorg only
x86_64: xorg and wayland
armhf: xorg and wayland
aarch64: xorg and wayland
In x86, mesa was compiled against xorg only to keep things as small as possible.
In armhf, even though the RPi cpu's are relatively slow and, in some versions, the amount of memory is small, all of them have a gpu, which wayland compositors can use to speed graphics up. For this reason mesa was compiled against xorg and wayland.
Up until fltk-1.3.x, it was only possible to compile fltk against xorg, which means the tinycore gui applets will not work with a wayland compositor unless xwayland is used, adding bloat.
With fltk-1.4.x it is possible to compile against both x11 and wayland, which means the tinycore gui applets work with both x11 window managers and wayland compositors.
Also with fltk-1.4.x, it is possible to compile mesa against wayland only, fltk-1.4.x against wayland only and run tinycore without x11 using a wayland compositor.
----
Taking the above into account, for tc-16.x, if we propose to move to fltk-1.4.x, I would suggest we compile an xorg only version for x86 and a combination xorg/wayland version for the other repos.
Note that a trial, wayland only, version of tc-15.x x86_64 was made, but there was not a great deal of interest in taking it forwards.
I will experiment with various options to build fltk-1.4.x with a view to getting the smallest possible xorg and xorg/wayland versions:
Without printing enabled
Without xft if possible
With lto (I make a pass without lto for the static libs)
Using ldscripts elf_i386.xbn and elf_x86_64.xbn
Using gcc initially, but maybe llvm later.
Comments welcome.
yvs:
> In armhf, all of them have a gpu, which wayland compositors can use to speed graphics up.
>
"can use", but does it use GPU acceleration? (taking into account provided GL version 2x)
Juanito:
Here are the first results on x86.
Using:
--- Code: ---CC="gcc -flto -march=i486 -mtune=i686 -Os -pipe -Wl,-T/usr/local/lib/ldscripts/elf_i386.xbn" CXX="g++ -flto -march=i486 -mtune=i686 -Os -pipe -fno-exceptions -fno-rtti -Wl,-T/usr/local/lib/ldscripts/elf_i386.xbn" ./configure --prefix=/usr/local --enable-shared --localstatedir=/var --disable-gl --disable-xinerama --disable-xft --disable-xfixes --disable-xcursor --disable-xrender --disable-print --disable-wayland --disable-test
--- End code ---
Gives:
lto
---
1,117,160 libfltk.so.1.4
22,008 libfltk_forms.so.1.4
158,496 libfltk_images.so.1.4
ldscripts + lto
---------------
1,110,224 libfltk.so.1.4
17,704 libfltk_forms.so.1.4
150,220 libfltk_images.so.1.4
ldscripts
---------
1,141,824 libfltk.so.1.4
17,892 libfltk_forms.so.1.4
151,608 libfltk_images.so.1.4
Whereas:
762,980 libfltk.so.1.3
21,940 libfltk_forms.so.1.3
43,416 libfltk_images.so.1.3
..so fltk-1.4.x is substantially larger than fltk-1.3.x although there is additional functionality, ref https://www.fltk.org/articles.php?L1955+I0+T+P1+Q
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version