FLTK 1.4 for TC 16

[polikuo]

It would be a good timing to move on to FLTK-1.4 (currently, the latest is 1.4.1)
How are you going to compile it (with xft, with wayland ... etc)
BTW, they are switching to CMAKE instead of the usual autotools, when will cmake be available ?

I think we should start a separate thread for this since there’s several things to discuss and x86 may be treated differently to x86_64.

How are we going to compile FLTK ?

In older releases, we have 3 types of libraries (fltk-1.3 for bare-bone minimum; fltk-xft with libXft support; fltk-full that is fully featured)

Are we going to add fltk-way for wayland support or are we going to make fltk-way the default option ?

BTW, FLTK now use CMAKE as the default build system

  FLTK 1.4.x will be the last version(s) of FLTK supporting
  autotools (configure + provided Makefiles) to build FLTK.
  FLTK 1.5.0 and higher will only support FLTK builds using CMake.

  We suggest to explore and use the CMake build system generators
  for your own FLTK builds as soon as possible. Some new FLTK build
  options will only be supported by CMake based builds.
  Please see README.CMake.txt for details and instructions.

  User projects that use CMake for their own build can benefit
  substantially if the FLTK library has been built using CMake.

[curaga]

There was some talk about a wayland version, with a separate repo. If that's the way, then the normal repo would not have anything wayland, fltk would have it disabled there, but presumably the wayland repo's fltk would be fully enabled.

[polikuo]

What about link time optimization ?

Specifically LLVM or GCC, the size difference.

I've done some test on raspberry pi with 1.4.0 a few month ago

Link Time Optimization (LTO) + distcc

With LTO, the shared libraries are smaller, the LLVM builds are smaller than the GCC builds.

The static ones, on the other hand, the LLVM builds are roughly 1.5 times the size of the GCC builds.

However, static libraries are only used in rare cases.

[hiro]

There was some talk about a wayland version, with a separate repo.

Is that because there's interest in maintaining both in parallel? Will everybody try and contribute to both things?
How are other people here planning to manage this transition? Personally I haven't left X land because my (extremely customized) window manager and favourite terminal are both X only.

[hiro]

What about link time optimization ?

Specifically LLVM or GCC, the size difference.

I've done some test on raspberry pi with 1.4.0 a few month ago

Link Time Optimization (LTO) + distcc

With LTO, the shared libraries are smaller, the LLVM builds are smaller than the GCC builds.

The static ones, on the other hand, the LLVM builds are roughly 1.5 times the size of the GCC builds.

However, static libraries are only used in rare cases.

what does that have to do with FLTK? sorry if i'm missing the context here.
I disagree about your last sentence. I have increasingly used static linking, and convinced as many to follow suit around me as possible. In practice the benefits outweigh the costs. Or in other words, I'm not up to bear the costs of dynamic linking any more.
The idea that static linking should be made artificially impossible must be some kind of GNU psyops
In golang land otoh it's commonplace now and the community has been growing. Most golang programmers don't even realize, but even they are indirectly supporting my stance IMHO.

[curaga]

Is that because there's interest in maintaining both in parallel? Will everybody try and contribute to both things?
How are other people here planning to manage this transition? Personally I haven't left X land because my (extremely customized) window manager and favourite terminal are both X only.

Juanito was interested in doing one for it being the future. It's also less bloat if apps are only compiled for one screen tech. The repos weren't meant to diverge outside of that - command-line stuff could be copied, etc., or possibly a fallback check could be added. Contributing would be based on interest. But it's all still open for discussion I believe.

My personal opinion is that Wayland doesn't solve any issues I have, but it introduces several new ones. So I will be using X for the foreseeable future.

[polikuo]

Hi, hiro.

what does that have to do with FLTK? sorry if i'm missing the context here.

Well, I'm sorta asking if we are going to LTO the FLTK extensions.

I disagree about your last sentence. I have increasingly used static linking

Would you mind elaborate a little more on that ?

So that we can know the benefits.

I'm a hobbyist at best in programming, I don't quite know where static linking is being used.

Right now, we have {fltk-1.3-dev(with static), fltk-xft-dev(with static), fltk-full-dev(with static)}

If I make it {fltk-1.4-dev(without static), fltk-xft-dev(without static), fltk-full-dev(without static), fltk-static(from fltk-full-dev)}

Will that break anything ?

[GNUser]

My personal opinion is that Wayland doesn't solve any issues I have, but it introduces several new ones. So I will be using X for the foreseeable future.

Hi curaga. I have a frugal install of TCL + Wayland (labwc) on a separate partition. It is not better than my TCL + Xorg (fluxbox) daily driver in any way. In fact, the Wayland setup is considerably more complex just to (almost) achieve feature parity with the Xorg setup.

I keep my toes in Wayland just in case someday I have no choice between Xorg and Wayland. For as long as I have a choice, Xorg is clearly a better fit for me because it gives me more for less.

[Rich]

Hi polikuo

... I don't quite know where static linking is being used.
Right now, we have {fltk-1.3-dev(with static), fltk-xft-dev(with static), fltk-full-dev(with static)} ...

Static libraries are only included with -dev packages. They are
not required when running programs that are linked to them.

Say we have a program called adventure and libraries
called libxyzzy.so and libxyzzy.a.

Most programs use shared libraries (so=shared object).

If adventure gets linked to libxyzzy.so, then that library
must be present on the system for adventure to run.
When adventure gets linked to libxyzzy.so, it doesn't pull
in any code. The linker just tells adventure where it can
find the functions provided by libxyzzy.so.

If adventure gets linked to libxyzzy.a, then that library
is not needed on the system for adventure to run.
When adventure gets linked to libxyzzy.a, it does pull
in code. The linker finds the needed functions provided
by libxyzzy.a and adds them to adventure so it can run
stand alone.

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.

[hiro]

It's also less bloat if apps are only compiled for one screen tech.

This may be, but it needs a good consensus to avoid a situation like the ipv4/ipv6 switchover. I would call this the best-case scenario.
It will be more bloat if apps are compiled for both screen tech.

I got wayland forced upon me at work in some instances, which still creates a huge instability in my everyday work days whenever I err on not simply ssh'ing in from my tinycorelinux laptop, so other distros are not doing good advertisement work to foster the adoption rates of wayland.

I kinda trust you guys here, so my hope was to wait before trying to voluntarily use wayland again until tinycorelinux shows me how it's done correctly.

[hiro]

Would you mind elaborate a little more on that ?

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]

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.

Beautifully dry and concise. Thank you

[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: [Select]

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