could Ardour's YTK be used as a GTK2 replacement? lazarus / 32-Linux ---------------------------------------------------------------------- robert rozee · 2026-03-04 05:15 has anyone experimented with Ardour's YTK (https://git.ardour.org/ardour/ardour/src/branch/master/libs/tk) as a replacement for GTK2? according to google's AI: "Stripped Features: YTK is a "stripped-down" version of GTK2, meaning it excludes many components of the original toolkit that Ardour does not use, further reducing its size compared to a standard system GTK installation. Static Linking: In most official Ardour bundles, YTK is linked directly into the application, meaning you don't need to manage it as a separate, space-consuming "package" on your system." this leaves me thinking that it may be possible to have YTK statically linked into a Lazarus/FPC application. if the result was an ELF binary that was, say, 5mb larger then this would for most folks be an acceptable compromise. alternatively, for applications distributed within an installer YTK could be handled as either a dependency, or packaged alongside the the main application. comments? worth looking into further? cheers, rob   :-) ---------------------------------------------------------------------- marcov · 2026-03-04 10:33 Why don't you try, and report back ? ---------------------------------------------------------------------- valdir.marcos · 2026-03-07 02:47 Quote from: robert rozee on March 07, 2026, 03:25:58 am... btw: i started another thread titled "could Ardour's YTK be used as a GTK2 replacement?" (https://forum.lazarus.freepascal.org/index.php/topic,73590.0.html), but only MarcoV posted to it - and that was not a very useful posting. while i'm not in a position to kick off such a project (integrating YTK into Lazarus as another widget set option) myself, it does seem like something worth exploring. no, not writing code! exploring in the sense of gaining some idea of how much bulk it would add to an ELF binary, to what degree YTK retains function calls that the LCL would need - and what needed function calls are missing, and the extent of modification to the LCL that would be needed. being able to (via existing GTK2 support along with incorporating YTK source) would add another string to Lazarus' bow going forward. cheers, rob   :-)I am trying and dealing with some errors and without a running binary so far. ---------------------------------------------------------------------- robert rozee · 2026-03-07 03:04 Quote from: valdir.marcos on March 07, 2026, 03:47:55 am[...] I am trying and dealing with some errors and without a running binary so far. have you been able to produce any binary yet? even if not runnable, it can yield useful information - such as by how much the size of the binary is increased when YTK is incorporated. cheers, rob   :-) ---------------------------------------------------------------------- valdir.marcos · 2026-03-07 04:13 Quote from: robert rozee on March 07, 2026, 04:04:38 amQuote from: valdir.marcos on March 07, 2026, 03:47:55 am[...] I am trying and dealing with some errors and without a running binary so far. have you been able to produce any binary yet? even if not runnable, it can yield useful information - such as by how much the size of the binary is increased when YTK is incorporated. cheers, rob   :-)Nope. Not so far. ---------------------------------------------------------------------- dbannon · 2026-03-07 07:21 Quote from: robert rozee on March 04, 2026, 06:15:48 am this leaves me thinking that it may be possible to have YTK statically linked into a Lazarus/FPC application. if the result was an ELF binary that was, say, 5mb larger then this would for most folks be an acceptable compromise. From memory, a gtk2 install requires about 200Meg. Davo ---------------------------------------------------------------------- robert rozee · 2026-03-07 07:28 Quote from: dbannon on March 07, 2026, 08:21:35 amFrom memory, a gtk2 install requires about 200Meg. well, hopefully we will find out how large the added footprint of YTK is in the not too distant future - if it is indeed 200mb that is a problem; if it is 5mb then we are onto a winner. cheers, rob   :-) ---------------------------------------------------------------------- Thaddy · 2026-03-07 12:07 It is nowhere near 5 and depending on distribution and cpu between 150 and 220. (It compares to a Windows install) But note that that includes a lot of "unnecessary" tooling that an advanced user may remove: there are distro's that are GTK2 based and under 75. Anyway, that solution is not mainstream so worthless in the sense you can not apply that to a default distribution. ---------------------------------------------------------------------- robert rozee · 2026-03-07 12:51 Quote from: Thaddy on March 07, 2026, 01:07:15 pmIt is nowhere near 5 and depending on distribution and cpu between 150 and 220. (It compares to a Windows install) But note that that includes a lot of "unnecessary" tooling that an advanced user may remove: there are distro's that are GTK2 based and under 75. Anyway, that solution is not mainstream so worthless in the sense you can not apply that to a default distribution. hi Thaddy, i am afraid that you are talking rubbish. the current Ardour downloader is a 75mb .run file. so that gives us an 'upper limit' to start with. one this is unpacked there appear to be a couple of YTK libraries of size 4.3mb (ytklib.so.2) and 3.9mb (libytkmm.so.2), giving a total of 8.2mb. there are also a few much smaller libraries, and one much larger library that seems to be the bulk of the main applications functionality (of which we have no interest in). we need to wait a moment and see what valdir.marcos comes up with for a reliable estimate - even a non-functional ELF binary will reveal some idea of size and dependencies. speculation before then is unreliable. cheers, rob   :-) ---------------------------------------------------------------------- dbannon · 2026-03-09 02:31 When Thaddy talks its sometimes rude, sometimes unpleasant. Never rubbish ! I have wasted most of a day trying to get a gtk2 version of my app as an AppImage. Because, Robert, that is what you want. An AppImage is built by examining your ready to run binary and gathering together "all" the required libraries, compressing them up and adding code to extract, as required, at run time. It (obviously) gets the libraries from the system its built on, it does not use the libraries from the machine it runs on. It does have to use local infrastructure sooner or later of course. My version, here, bundles some 257 libraries including the xcb set and, as I understand it, the gtk2 set. Sadly, it does not work ! Seems the linuxdeploy people do not put a high priority on gtk2 ! But useful to see what it is trying to build. The AppDir is where all the libraries are assembled before compression so, while we know it is incomplete, its an indication of the size of a statically linked binary. Code: Bash  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i dbannon@dell:~/AppImageGtk2/tomboy-ng/tomboy-ng_0.42b-1$ ls -l tomboy- ng-x86_64.AppImage -rwxr-xr-x 1 dbannon dbannon 27429368 Mar  9 12:53 tomboy-ng-x86_64.AppImagedbannon@dell:~/AppImageGtk2/tomboy-ng/tomboy- ng_0.42b-1$ du -hs ../AppDir/94M     ../AppDir/ Remember, this is for my app, it obviously uses only a subset of GTK2, a general purpose library, to cater for all Lazarus apps would be a lot bigger. The AppImage itself is smaller due to compression, proving, to me, beyond all doubt its a better solution than static linking ! Still a dopey solution, but I make Qt5/6 AppImages available and they do get some downloads. Davo ---------------------------------------------------------------------- AmatCoder · 2026-03-09 05:52 @Davo: I have the necessary infrastructure to make GTK2/3 static builds (and I was bored) so I built your app to test. I can give you some numbers: GTK2 (symbols stripped) -> 25.92MGTK2 (symbols stripped / compress with UPX) -> 7.57MGTK3 (symbols stripped) -> 31.64MGTK3 (symbols stripped / compress with UPX) -> 9.14M Quote from: dbannon on March 09, 2026, 03:31:07 amMy version, here, bundles some 257 libraries including the xcb set and, as I understand it, the gtk2 set. Although the number of libraries depends on the distribution, 257 seems excessive. I use about ~50 for GTK2 and ~60 for GTK3. When I get more time I will build a Qt6 version to compare. ---------------------------------------------------------------------- robert rozee · 2026-03-09 07:26 Quote from: AmatCoder on March 09, 2026, 06:52:36 amI have the necessary infrastructure to make GTK2/3 static builds (and I was bored) [...] are you by any chance able to give a (detailed) description on how to do this? cheers, rob   :-) ---------------------------------------------------------------------- robert rozee · 2026-03-09 12:37 Quote from: dbannon on March 09, 2026, 03:31:07 am[...] I have wasted most of a day trying to get a gtk2 version of my app as an AppImage. Because, Robert, that is what you want [...] one of the greater sins in life is telling people what they want  however, your efforts do provide another useful data point: 27429368, which i presume is 27mb. this result represents an upper limit, as it will no doubt include a whole load of other stuff that is of no interest. for instance, X11 does not need to be included, unless GTK2 and X11 are (god forbid) bound together at specific version number pairings. cheers, rob   :-) ---------------------------------------------------------------------- fifr · 2026-03-10 13:06 For those who are interested: I managed to compile and link Lazarus against ytk. This does not mean that the result works (it crashes), but this is expected as I had to remove some unsupported code (without a proper replacement). However, the whole experiment was to see if ytk can be used in principle and how much work would have to be done. In case you want to try yourself, here's what I did: extract the ztk, ydk, ydk-pixbuf, ytk from Ardour's source tree (see the attached ytk.tar.gz). I added some hand-crafted makefiles that compile everything to static libraries (Ardour uses waf as build system, which I do not know, and using simple makefiles was easier). Note that other libraries like glib, gio, gobject, pango, cairo ... are still linked dynamically.remove some unsupported functions from the fpc package (see the attached fpc-ytk.patch). I used the 3.2.2 release of fpcremove some unsupported functions from Lazarus/LCL (see the attached lazarus-ytk.patch) and link against the static libscompile the patched fpc and use it to compile Lazarus like make bigide LCL_PLATFORM=gtk2 PP=/path/to/patched/fpc OTHERLIBDIR=/path/to/ytk/static/libs This worked on my machine (void-linux, x86_64). Note that number of changes/removals is not too bad. Most of them are related to functions that are deprecated in gtk2 anyway (e.g. gtk_clist_* gtk_pixmap_* gtk_list_* etc) and those deprecated functions have been removed from ytk. So probably these places could be updated without too much effort (maybe take some code from gtk3 or use proper replacements). But as I said, Lazarus compiles and starts but crashes right after the start (probably due to some of my changes). Nevertheless, it seems that using ytk instead of gtk is indeed possible with some reasonable effort. And if you like numbers: here are the binary sizes of a stripped lazarus executable on my system with gtk2 (dynamically linked) and ytk (statically linked): gtk2: 41.4 MBytk: 45.5 MB Here are the ytk-sources including my makefiles. They are too large to be attached to this post: https://limewire.com/d/NhcP6#T0SnfydlLc ---------------------------------------------------------------------- Fred vS · 2026-03-10 13:13 @fifr:  WOW, You are a game-changer. ---------------------------------------------------------------------- robert rozee · 2026-03-10 14:18 Quote from: fifr on March 10, 2026, 02:06:58 pm[...] here are the binary sizes of a stripped lazarus executable on my system with gtk2 (dynamically linked) and ytk (statically linked): gtk2: 41.4 MBytk: 45.5 MB wow - those results are impressive! dynamic GTK2 -> static YTK = 4.1mb increase in ELF binary size. these results suggest this is certainly a project worth pursuing. amongst other things, it would mean we could have a single linux binary for the lazarus IDE that would work on any linux system that uses X11. this would be far better that the current situation where the Sourceforge packages initially only work with GTK2, and also extend to covering Wayland (provided XWayland is also present). in addition (following the "extra string to our bow" philosophy), with lazarus now not only be able to build for "GTKx" and "Qtx" widgetsets, but also for what is effectively an "X11 direct" widgetset; for embedded targets there would be a significant saving on the disk space required (between "between 150[mb] and 220[mb]" according to Thaddy in his earlier post). while a few hundred mb is nothing on desktop linux systems, embedded systems are far more 'disk space sensitive'. perhaps someone should reach out to the Ardour developer(s) to see if they are interested in offering us any help? the name that pops up is Paul Davis: https://github.com/pauldavisthefirst. cheers, rob   :-) ---------------------------------------------------------------------- fifr · 2026-03-12 18:29 I managed to successfully compile and run Lazarus with ytk. You can find the changes on gitlab: ytk: https://gitlab.com/fifr/ytk-fpcfpc: https://gitlab.com/fifr/fpc/-/tree/ytk/ (branch ytk based on fpc-3.2.2)lazarus: https://gitlab.com/fifr/lazarus/-/tree/ytk/ (branch ytk based on lazarus_4_6)I tried to split all changes in smaller pieces, one widget at the time, so reviewing them should not be too hard. The following changes were necessary: ytk: unfortunately, the ardour authors made a change that is ABI incompatible with gtk2: they added three new methods in the middle of the vtable of GtkWidget (instead of appending them). This is no problem for them (because of static linking) but a problem for fpc because the binding on the pascal side makes an assumption on the layout of that vtable. The branch in this repo moves the three methods to the end of the vtable (without this change Lazarus crashes on start). fpc: Basically a lot of deprecated gtk2 types have been deleted (I just removed the corresponding "include" from the gtk2 package). And the package now links the ytk static libs instead of gtk, of course. lazarus: Similarly a lot of old code has been removed. It turned out that most parts are not that critical because the code was not used anyway (some old artifacts from gtk1 or so -- some are even there in the gtk3 binding). There three "bigger" changes: GtkCombo has been replaced by GtkComboBoxEntryGtkList has been replaced by GtkTreeViewGtkCalendar has been disabledThe first two may cause some problems. I did my best to change not too much, but I had to remove some workarounds implemented specifically for GtkCombo or GtkList. So components using one of them may behave differently now (or have some bugs). These changes should (in theory) be compatible with gtk2 (in particular, linking with gtk2 instead of ytk still works). Everything that has been removed has been deprecated in gtk2. The only exception is GtkCalendar, which is not deprecated but also not part of ytk. I just disabled the widget for now. Possible solutions would be to add the widget to ytk again or to implement the LCL widget without the gtk backend. With these changes, Lazarus starts (on my system), but only with the classic (i.e. multi-window) IDE. The docked IDE crashes (probably something with the GtkList or so, I do not know, yet). ---------------------------------------------------------------------- dbannon · 2026-03-13 04:20 Pretty impressive Frank, pretty impressive ! Davo ---------------------------------------------------------------------- robert rozee · 2026-03-14 12:30 yes Frank, am impressed here too! what sort of output do you see when you use readelf to extract a list of dependencies for your YTK version of the IDE? on my setup, from the standard (GTK2) 3.6 version of the lazarus IDE i get: user@user-DH61BE:/usr/share/lazarus/3.6.0$ ls -l startlazarus -rwxr-xr-x 1 root root 41221520 Apr 19  2025 startlazarus user@user-DH61BE:/usr/share/lazarus/3.6.0$ user@user-DH61BE:/usr/share/lazarus/3.6.0$ user@user-DH61BE:/usr/share/lazarus/3.6.0$ readelf -d startlazarus | grep -i "needed"  0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]  0x0000000000000001 (NEEDED)             Shared library: [libgdk-x11-2.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libgtk-x11-2.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libX11.so.6]  0x0000000000000001 (NEEDED)             Shared library: [libgdk_pixbuf-2.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libgobject-2.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libglib-2.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libgthread-2.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libgmodule-2.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libpango-1.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libcairo.so.2]  0x0000000000000001 (NEEDED)             Shared library: [libatk-1.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6] user@user-DH61BE:/usr/share/lazarus/3.6.0$ user@user-DH61BE:/usr/share/lazarus/3.6.0$ in theory, with YTK statically linked, i think you should be getting something like:  0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]  0x0000000000000001 (NEEDED)             Shared library: [libX11.so.6]  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6] cheers, rob   :-) ---------------------------------------------------------------------- fifr · 2026-03-14 13:34 the following dynamic libraries are linked: Code: [Select]$ ldd startlazarus linux-vdso.so.1 (0x00007fd45de30000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fd45dcbf000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007fd45db6a000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007fd45db06000) libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007fd45dace000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00007fd45dabe000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00007fd45d990000) libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x00007fd45d79d000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00007fd45d783000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00007fd45d714000) libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x00007fd45d5ed000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007fd45d59f000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007fd45d4d9000) libm.so.6 => /usr/lib/libm.so.6 (0x00007fd45d3eb000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00007fd45d3d6000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007fd45d3c9000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007fd45d3c4000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007fd45d3bf000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007fd45d3b6000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00007fd45d38d000) libc.so.6 => /usr/lib/libc.so.6 (0x00007fd45d1a3000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fd45d178000) libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0 (0x00007fd45d0c8000) libffi.so.7 => /usr/lib/libffi.so.7 (0x00007fd45d0bc000) libz.so.1 => /usr/lib/libz.so.1 (0x00007fd45d0a0000) libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0x00007fd45d092000) libxcb-shm.so.0 => /usr/lib/libxcb-shm.so.0 (0x00007fd45d08d000) libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x00007fd45cfd6000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fd45de32000) libmount.so.1 => /usr/lib/libmount.so.1 (0x00007fd45cf5f000) libfribidi.so.0 => /usr/lib/libfribidi.so.0 (0x00007fd45cf3d000) libthai.so.0 => /usr/lib/libthai.so.0 (0x00007fd45cf32000) libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x00007fd45cf08000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007fd45cedb000) libbz2.so.1 => /usr/lib/libbz2.so.1 (0x00007fd45cec8000) libbrotlidec.so.1 => /usr/lib/libbrotlidec.so.1 (0x00007fd45ceb8000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fd45ceb3000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fd45ceab000) libblkid.so.1 => /usr/lib/libblkid.so.1 (0x00007fd45ce4b000) libdatrie.so.1 => /usr/lib/libdatrie.so.1 (0x00007fd45ce41000) libbrotlicommon.so.1 => /usr/lib/libbrotlicommon.so.1 (0x00007fd45ce1c000) or, if you prefer the readelf output Code: [Select]$ readelf -d startlazarus | grep -i "needed"  0x0000000000000001 (NEEDED)             Shared library: [libX11.so.6]  0x0000000000000001 (NEEDED)             Shared library: [libglib-2.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libgobject-2.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libpng16.so.16]  0x0000000000000001 (NEEDED)             Shared library: [libpangocairo-1.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libcairo.so.2]  0x0000000000000001 (NEEDED)             Shared library: [libgio-2.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libpangoft2-1.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libpango-1.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libharfbuzz.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libfontconfig.so.1]  0x0000000000000001 (NEEDED)             Shared library: [libfreetype.so.6]  0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]  0x0000000000000001 (NEEDED)             Shared library: [libXext.so.6]  0x0000000000000001 (NEEDED)             Shared library: [libXrender.so.1]  0x0000000000000001 (NEEDED)             Shared library: [libXinerama.so.1]  0x0000000000000001 (NEEDED)             Shared library: [libgthread-2.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libgmodule-2.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libatk-1.0.so.0]  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6] Note that only gtk, gdk, gdk-pixbuf and ztk are part of ytk. Dependent libraries like several font-related libs as well as glib, gobject, gio are still linked dynamically (but those are not deprecated). ---------------------------------------------------------------------- Fred vS · 2026-03-14 14:21 Hello Fifr. The compilation of libraries ytk-fpc-main from your GitLab site was out-of-the-box: WOW, only "make" command did the trick. But to apply the patches to fpc/lazarus source using the link of your previous post: Quote* fpc-ytk.patch (27.76 kB - downloaded 43 times.) * lazarus-ytk.patch (23.21 kB - downloaded 28 times.) The patches are not working when using: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i $ cd /dir/of/fpc-source$ patch fpc-ytk.patch The same for lazarus patch. What am I missing? And where should the ytk libraries be placed? For the patch for fpc, could it be used also for fpc 3.2.2 source? In any case, congratulations on this courageous and brilliant fight. ---------------------------------------------------------------------- robert rozee · 2026-03-14 14:33 aha, i see where i went astray... that rather short list i had (libdl.so.2 , libX11.so.6 , libc.so.6) was based on looking at the ELF binary of an application built for Qt5, but with libQt5Pas.so.1 deleted from the list. i'm picking that for the ELF binary i was looking at, those other dependencies you have listed are things that (in my example) were quietly being brought in by libQt5Pas.so.1. my mistake! btw - is there a simple way of recursively looking for dependencies? or would that lead one down an infinite rabbit hole?! cheers, rob   :-) ---------------------------------------------------------------------- fifr · 2026-03-14 14:34 Quote from: Fred vS on March 14, 2026, 03:21:29 pmBut to apply the patches to fpc/lazarus source using the link of your previous post:  for lazarus patch. What am I missing? Forget about those patches, they are pretty out-of-date. Just checkout the ytk branch of the three repos I posted earlier (you also need ytk from the repo because I had to make change). Those versions should be compatible. And you can place the libraries wherever you want. Just specify the path when compiling lazarus Code: [Select]$ make bigide LCL_PLATFORM=gtk2 OTHERLIBDIR=/path/to/ytk/libs ---------------------------------------------------------------------- fifr · 2026-03-14 14:36 Quote from: robert rozee on March 14, 2026, 03:33:22 pmbtw - is there a simple way of recursively looking for dependencies? or would that lead one down an infinite rabbit hole?! I think ldd should show all recursively required dependencies (except those that are potentially loaded at runtime using dl). ---------------------------------------------------------------------- Fred vS · 2026-03-14 14:46 Quote from: fifr on March 14, 2026, 03:34:27 pmQuote from: Fred vS on March 14, 2026, 03:21:29 pmForget about those patches, they are pretty out-of-date. Just checkout the ytk branch of the three repos I posted earlier (you also need ytk from the repo because I had to make change). Those versions should be compatible. Ha, perfect there is the ytk branches, with all your changes. OK, write you later. ---------------------------------------------------------------------- Fred vS · 2026-03-14 15:28 Re-Hello Fifr. Sorry but I can only say, once again, WOW.  Out-of-the-box (very important for me) and working great. @Rob: The size of startlazarus is 60.8 MiB unstripped. And stripped (and still working!) 14.7 MiB. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i $ readelf -d startlazarus | grep -i "needed" 0x0000000000000001 (NEEDED)           Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED)           Shared library: [libX11.so.6] 0x0000000000000001 (NEEDED)           Shared library: [libglib-2.0.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libgobject-2.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libpng16.so.16] 0x0000000000000001 (NEEDED)             Shared library: [libpangocairo-1.0.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libcairo.so.2] 0x0000000000000001 (NEEDED)           Shared library: [libgio-2.0.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libpangoft2-1.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libpango-1.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libharfbuzz.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libfontconfig.so.1] 0x0000000000000001 (NEEDED)           Shared library: [libfreetype.so.6] 0x0000000000000001 (NEEDED)           Shared library: [libm.so.6] 0x0000000000000001 (NEEDED)           Shared library: [libXext.so.6] 0x0000000000000001 (NEEDED)           Shared library: [libXrender.so.1] 0x0000000000000001 (NEEDED)           Shared library: [libXinerama.so.1] 0x0000000000000001 (NEEDED)             Shared library: [libgthread-2.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libgmodule-2.0.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libatk-1.0.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libc.so.6] ] [EDIT] I did test with one of mine LCL app:             Using original LCL-GTK2: 7.2 MiB.             Using LCL-YTK: 10.8 MiB. (and is working) Fifr you are the greatest. ---------------------------------------------------------------------- robert rozee · 2026-03-14 16:27 Quote from: fifr on March 14, 2026, 03:36:46 pmQuote from: robert rozee on March 14, 2026, 03:33:22 pmbtw - is there a simple way of recursively looking for dependencies? or would that lead one down an infinite rabbit hole?! I think ldd should show all recursively required dependencies (except those that are potentially loaded at runtime using dl). brilliant, ldd worked a treat. filtered the output to get just the library names using: ldd project1 | cut -d'=' -f1 | sort applied this to the ELF binaries of a project built first using GTK2, then using Qt5. pasted the outputs into a 2-column LibreOffice document, lined up matching entries and colour coded those that did not match. the result is an 'interesting' table for further study! Fred: what happens if you use your newly created IDE to build a very simple GUI application into an ELF binary? how large is it? for GTK2/Qt5 i'd expect something like 3mb, and guess that for YTK it is perhaps 9mb? cheers, rob   :-) ---------------------------------------------------------------------- Fred vS · 2026-03-14 20:48 Quote from: robert rozee on March 14, 2026, 05:27:15 pmFred: what happens if you use your newly created IDE to build a very simple GUI application into an ELF binary? how large is it? for GTK2/Qt5 i'd expect something like 3mb, and guess that for YTK it is perhaps 9mb? Not sure to understand. My previous post said: Quote I did test with one of mine LCL app:             Using original LCL-GTK2: 7.2 MiB.             Using LCL-YTK: 10.8 MiB. (and is working) I encourage you to use fifr sources; it's out-of-the-box. ---------------------------------------------------------------------- robert rozee · 2026-03-14 23:13 Quote from: Fred vS on March 14, 2026, 09:48:40 pmQuote I did test with one of mine LCL app:             Using original LCL-GTK2: 7.2 MiB.             Using LCL-YTK: 10.8 MiB. (and is working) my bad - i had missed those few lines when i read your previous post. that is exactly the information i was after... showing the size difference between GTK2 and YTK is just 3.6mb for smaller applications. this is a number massively less that what Thaddy and others had earlier predicted. cheers, rob   :-) ---------------------------------------------------------------------- Fred vS · 2026-03-15 01:44 Dear Rob and all others. Here how to test the magic work of fifr. - Download (or clone) ytk-fpc: https://gitlab.com/fifr/ytk-fpc   Then in console (after unzip): Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i $ cd /directory/of/ytk-fpc$ makeCopy the 4 libxxx.a libraries in /directory/of/ytk-fpc and paste (sudo needed) it into /usr/lib  (maybe there is a other better place or update the lib-search-path but this work). - Download (or clone) fpc source branch ytk: https://gitlab.com/fifr/fpc/-/tree/ytk?ref_type=heads   Compile + install fpc-ytk   I used this script in /dir/of/fpc-source-ytk (run it with sudo privilege). Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i #!/bin/sh COMPILER=fpcINSTALLDIR=/usrmake all FPC=$COMPILER OPT="-Fl/usr/local/lib" make FPC=$COMPILER install INSTALL_PREFIX=$INSTALLDIR - Download (or clone) lazarus source branch ytk: https://gitlab.com/fifr/lazarus/-/tree/ytk?ref_type=heads   Unzip it then in console: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i $ cd /directory/of/lazarus-ytk$ make That's all guys! ---------------------------------------------------------------------- AmatCoder · 2026-03-15 07:09 But... why YTK? You can do the same with plain GTK2. A few deprecated functions won't make any size difference. It's not worth it. Quote from: robert rozee on March 15, 2026, 12:13:08 am ...showing the size difference between GTK2 and YTK is just 3.6mb for smaller applications. this is a number massively less that what Thaddy and others had earlier predicted. Because only libgtk/libgdk are statically linked All the others libraries needed by the application are not. For example, my static build included all libraries and it takes up 25M but...this means that It even works on systems that don't have GTK/GLib installed! ---------------------------------------------------------------------- robert rozee · 2026-03-15 08:29 Quote from: AmatCoder on March 15, 2026, 08:09:55 amBut... why YTK? [...] for exactly the same reason that the Ardour project does, of course. https://ardour.org/ Quote from: AmatCoder on March 15, 2026, 08:09:55 am[...] All the others libraries needed by the application are not. For example, my static build included all libraries and it takes up 25M but...this means that It even works on systems that don't have GTK/GLib installed! true - that is a point i have been considering. are you able to tell us what other libraries are exclusively part of GTK2? alternatively, is there anyone out there who has a distro available that has no GTK present (perhaps even no widget set at all, just X11), and can therefore test which dependencies are not being met? cheers, rob   :-) ---------------------------------------------------------------------- robert rozee · 2026-03-15 09:30 Fred: when i run the 5 line shell script i get: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i --- heaps of lines above here clipped out ---fpc -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU../../rtl/units/x86_64-linux -Cg -dx86_64 -dRELEASE ../unix/cwstring.ppfpc -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU../../rtl/units/x86_64-linux -Cg -dx86_64 -dRELEASE fpcylix.ppfpc -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU../../rtl/units/x86_64-linux -Cg -dx86_64 -dRELEASE ../inc/softfpu.ppfpc -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU../../rtl/units/x86_64-linux -Cg -dx86_64 -dRELEASE ../inc/sfpux80.ppfpc -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU../../rtl/units/x86_64-linux -Cg -dx86_64 -dRELEASE ../inc/ufloatx80.ppfpc -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU../../rtl/units/x86_64-linux -Cg -dx86_64 -dRELEASE ../inc/sfpu128.ppfpc -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU../../rtl/units/x86_64-linux -Cg -dx86_64 -dRELEASE ../inc/ufloat128.ppmake[7]: Leaving directory '/home/user/pascal/Lazarus (local)/fpc-ytk/rtl/linux'make[6]: Leaving directory '/home/user/pascal/Lazarus (local)/fpc-ytk/rtl'make[5]: Leaving directory '/home/user/pascal/Lazarus (local)/fpc- ytk/compiler'make cycleclean compilermake[5]: Entering directory '/home/user/pascal/Lazarus (local)/fpc-ytk/compiler'/usr/bin/rm -f pp pp.o libppp.a libimppp.a/usr/bin/rm -rf units/usr/bin/rm -rf bin/usr/bin/rm -f *.o *.ppu *.rst *.s *.a *.so *.ppl/usr/bin/rm -rf *.sl/usr/bin/rm -f fpcmade.* Package.fpc ./ppas.sh script.res link.res  /usr/bin/rm -f *_ppas.sh ppas.sh ppaslink.shmake -C utils cleanallmake[6]: Entering directory '/home/user/pascal/Lazarus (local)/fpc-ytk/compiler/utils'/usr/bin/rm -f fpc ppufiles ppudump ppumove mka64ins mkarmins mkx86ins fpc.o ppufiles.o ppudump.o ppumove.o mka64ins.o mkarmins.o mkx86ins.o libpfpc.a libpppufiles.a libpppudump.a libpppumove.a libpmka64ins.a libpmkarmins.a libpmkx86ins.a libimpfpc.a libimpppufiles.a libimpppudump.a libimpppumove.a libimpmka64ins.a libimpmkarmins.a libimpmkx86ins.a/usr/bin/rm -f units/x86_64-linux/ppu.ppu units/x86_64-linux/crc.ppu/usr/bin/rm -rf units/usr/bin/rm -rf bin/usr/bin/rm -f *.o *.ppu *.rst *.s *.a *.so *.ppl/usr/bin/rm -rf *.sl/usr/bin/rm -f fpcmade.* Package.fpc ./ppas.sh script.res link.res  /usr/bin/rm -f *_ppas.sh ppas.sh ppaslink.shmake[6]: Leaving directory '/home/user/pascal/Lazarus (local)/fpc- ytk/compiler/utils'/usr/bin/rm -rf x86_64/units/usr/bin/rm -rf x86_64/bin/usr/bin/rm -f x86_64/*.o x86_64/*.ppu x86_64/*.rst x86_64/*.s x86_64/*.a x86_64/*.so x86_64/*.ppl/usr/bin/rm -f x86_64/ppc386 x86_64/ppc68k x86_64/ppcppc x86_64/ppcsparc x86_64/ppcarm x86_64/ppcarmeb x86_64/ppcx64 x86_64/ppcppc64 x86_64/ppcmips x86_64/ppcmipsel x86_64/ppcavr x86_64/ppcjvm x86_64/ppc8086 x86_64/ppca64 x86_64/ppcsparc64/usr/bin/rm -f ppcx64/usr/bin/mkdir -p x86_64/units/x86_64-linuxfpc -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu../rtl/units/x86_64-linux -Fix86_64 -FE. -FUx86_64/units/x86_64-linux -Cg -dRELEASE -dx86_64 -dGDB -dBROWSERLOG -Fux86 pp.pas/usr/bin/mv -f ./pp ppcx64make[5]: Leaving directory '/home/user/pascal/Lazarus (local)/fpc-ytk/compiler'make echotimemake[5]: Entering directory '/home/user/pascal/Lazarus (local)/fpc-ytk/compiler'Start now 22:13:47make[5]: Leaving directory '/home/user/pascal/Lazarus (local)/fpc-ytk/compiler'make[4]: Leaving directory '/home/user/pascal/Lazarus (local)/fpc- ytk/compiler'/usr/bin/rm -f ppc1/usr/bin/mv -f ppcx64 ppc1make 'FPC=/home/user/pascal/Lazarus (local)/fpc-ytk/compiler/ppc1' 'OLDFPC=' next CYCLELEVEL=2make[4]: Entering directory '/home/user/pascal/Lazarus (local)/fpc-ytk/compiler'Makefile:135: *** Compiler /home/user/pascal/Lazarus (local)/fpc-ytk/compiler/ppc1 not found.  Stop.make[4]: Leaving directory '/home/user/pascal/Lazarus (local)/fpc-ytk/compiler'make[3]: *** [Makefile:4339: ppc2] Error 2make[3]: Leaving directory '/home/user/pascal/Lazarus (local)/fpc- ytk/compiler'make[2]: *** [Makefile:4347: cycle] Error 2make[2]: Leaving directory '/home/user/pascal/Lazarus (local)/fpc- ytk/compiler'make[1]: *** [Makefile:2800: compiler_cycle] Error 2make[1]: Leaving directory '/home/user/pascal/Lazarus (local)/fpc- ytk'make: *** [Makefile:2832: build-stamp.x86_64-linux] Error 2root@user-DH61BE:/home/user/pascal/Lazarus (local)/fpc-ytk# i think the line where things fall apart is line 50: Makefile:135: *** Compiler /home/user/pascal/Lazarus (local)/fpc- ytk/compiler/ppc1 not found.  Stop. ideally, i'd like to be able to create a directory in my home directory, and for everything to be built and contained within in just that directory. is this possible? cheers, rob   :-) btw, instead of cloning, i just downloaded as .zip files, from which i unpacked the top directories to give: user@user-DH61BE:~/pascal/Lazarus-(local)$ ls -l total 63748 -rw-rw-r-- 1 user user  4803016 Mar 15 21:50 '1.ytk-fpc-main.zip' -rw-rw-r-- 1 user user 60458217 Mar 15 21:55 '2.fpc-ytk.zip' drwxrwxr-x 8 user user     4096 Mar 15 22:13  fpc-ytk drwxrwxr-x 6 user user     4096 Mar 15 21:55  ytk-fpc-main user@user-DH61BE:~/pascal/Lazarus-(local)$ ls ytk-fpc-main/ -l total 86004 -rw-rw-r-- 1 user user      197 Mar 13 21:56 GNUmakefile -rw-rw-r-- 1 user user 12312214 Mar 15 21:53 libydk.a -rw-rw-r-- 1 user user  2359746 Mar 15 21:53 libydk-pixbuf.a -rw-rw-r-- 1 user user 70688496 Mar 15 21:55 libytk.a -rw-rw-r-- 1 user user  2658906 Mar 15 21:52 libztk.a drwxrwxr-x 6 user user     4096 Mar 15 21:53 ydk drwxrwxr-x 5 user user     4096 Mar 15 21:52 ydk-pixbuf drwxrwxr-x 4 user user    20480 Mar 15 21:55 ytk drwxrwxr-x 3 user user     4096 Mar 15 21:52 ztk user@user-DH61BE:~/pascal/Lazarus-(local)$ ls fpc-ytk/ -l total 200 drwxrwxr-x  24 user user 12288 Mar 15 22:20 compiler -rw-rw-r--   1 user user   254 Mar 13 21:56 fpmake_add1.inc -rw-rw-r--   1 user user  1225 Mar 13 21:56 fpmake.pp -rw-rw-r--   1 user user   194 Mar 13 21:56 fpmake_proc1.inc drwxrwxr-x   2 user user  4096 Mar 13 21:56 installer -rw-rw-r--   1 user user 72466 Mar 13 21:56 Makefile -rw-rw-r--   1 user user  8859 Mar 13 21:56 Makefile.fpc drwxrwxr-x 151 user user  4096 Mar 13 21:56 packages drwxrwxr-x  61 user user  4096 Mar 15 22:05 rtl -rwxrwxr-x   1 user user   140 Mar 15 22:11 script drwxrwxr-x  11 user user  4096 Mar 13 21:56 tests drwxrwxr-x  28 user user  4096 Mar 13 21:56 utils ---------------------------------------------------------------------- robert rozee · 2026-03-15 10:07 Fred: should the four libxxx.a files be placed in /usr/local/lib or /usr/lib? and should the fourth line of the shell script end in OPT="-Fl/usr/local/lib" or instead OPT="-Fl/usr/lib"? cheers, rob   :-) ---------------------------------------------------------------------- Thausand · 2026-03-15 10:35 Quote from: robert rozee on March 15, 2026, 11:07:23 amshould the four libxxx.a files be placed in /usr/local/lib or /usr/lib? Not one and not other. I not have looked but if single time static link then not put in system. Can be anywhere when add library path option to location. Quoteand should the fourth line of the shell script end in OPT="-Fl/usr/local/lib" or instead OPT="-Fl/usr/lib"? library path option is point to what is location static library. Can be locate anywhere. If use one time for link static libraries then this is work. I have ask why is need all fpc source ? patch for fpc 3.2.2 more easy. Also more easy for make patch use define. ---------------------------------------------------------------------- Fred vS · 2026-03-15 13:04 Quote from: robert rozee on March 15, 2026, 10:30:37 amFred: when i run the 5 line shell script i get: ... Hello Rob. I dont know why you get problems, here it was ootb. The directory of my fpc-ytk is: /home/fred/Downloads/fpc-ytk You need to paste the script in that directory. Regarding `OPT="-Fl/usr/local/lib"`, it might not be necessary. I use it because it can be required for BSD, and I use the same script for all Unix operating systems. As for where to put the static libraries, I put them in `/usr/lib` because at linking ld finds them there. But of course, it's possible to put them elsewhere since they are static but then afaik to compile lazarus a parameter is needed for "make" (and I dont remember witch). ---------------------------------------------------------------------- Thausand · 2026-03-15 13:29 Quote from: Fred vS on March 15, 2026, 02:04:22 pmI dont know why you get problems, here it was ootb. Maybe have write COMPILER=fpc is for bootstrap fpc (3.2.0). may be robert have other version fpc in path. QuoteRegarding `OPT="-Fl/usr/local/lib"`, it might not be necessary. I use it because it can be required for BSD, and I use the same script for all Unix operating systems. Is not problem and can be there. afaik robert have write want stand alone, then can have if want. QuoteAs for where to put the static libraries, I put them in `/usr/lib` because at linking ld finds them there. But of course, it's possible to put them elsewhere since they are static but then afaik to compile lazarus a parameter is needed for "make" (and I dont remember witch). Make smart fpc-ytk.sh script. Code: [Select]to/fpc -n @to/fpc.cfg -dytk $@ then in fpc.cfg have make IFDEF ytk and have -Fl"where_is_static_ytk_lib" fpc is pass option for linker. Only is problem when use custom linker setup and have interfere (example is when use custom linker script). If have custom linker configuration then person is smart and know how can solve. When configure Lazarus then have fpc compiler is use fpc-ytk.sh (no fpc). Lazarus is complain that is no valid compiler  but that no matter (make raise middle finger  ) ---------------------------------------------------------------------- robert rozee · 2026-03-15 13:46 well, turns out the problem was due to the name of directory i was working in: "Lazarus (local)", with something in the build scripts taking exception to there being an opening bracket in the name! once i rename the directory to "Lazarus-local" everything ran to completion. except... if i now try to build an existing Lazarus project, just by double-clicking on a .lpi file, i get the errors: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Compile Project, Mode: Default, Target: /home/user/pascal/GFXterm 2.1d/project1: Exit code 1, Errors: 1, Warnings: 1Warning: Recompiling Gtk2Int, checksum changed for /usr/lib/fpc/3.2.2/units/x86_64- linux/gtk2/gdk2pixbuf.ppugtk2int.pas(15,16) Error: Can't find unit Gtk2Int used by Interfaces my guess is that the build scripts have 'leaked out' of the directory i was working in, partially overwriting my existing installation of FPC. in retrospect, i should have done this all in a VM. how do i undo this unholy mess?! cheers, rob   :-( ---------------------------------------------------------------------- Fred vS · 2026-03-15 14:27 Code: [Select][quote author=robert rozee link=topic=73590.msg578504#msg578504 date=1773582363] Warning: Recompiling Gtk2Int, checksum changed for /usr/lib/fpc/3.2.2/units/x86_64-linux/gtk2/gdk2pixbuf.ppu gtk2int.pas(15,16) Error: Can't find unit Gtk2Int used by Interfaces[/quote] I dont know, here it works ootb. Maybe try to compile lazarus with make clean at init and be sure the fpc-ytk is used for compilation. ---------------------------------------------------------------------- Fred vS · 2026-03-15 14:35 @Rob. It seems that the problem comes because you are using the official  fpc 3.2.2 and not fpc-ytk. Did you install fpc-ytk on your system? Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i #!/bin/sh  COMPILER=fpc INSTALLDIR=/usr make FPC=$COMPILER install INSTALL_PREFIX=$INSTALLDIR  It is the easy way, after your test you may reinstall official fpc. ---------------------------------------------------------------------- Fred vS · 2026-03-15 14:46 @Rob: for your eyes only: https://github.com/fredvs/test/releases/download/vstrum/project1.zip ---------------------------------------------------------------------- robert rozee · 2026-03-15 15:09 right - have paused attempts at repair and moved over to working on a VM. Linux Mint 21.2, x86-64. FPC and Lazarus were already installed in the VM, so i uninstalled them before starting. first thing i discovered was that i needed FPC to be installed to run the 5-line script - kind of obvious as there is no bootstrap compiler, a minor point but worth mentioning in any instructions. so i reinstalled just the FPC compiler package from Sourceforge and re-ran the script. apart from that small hiccup, everything else ran to completion fine. once finished i did have to go searching for startlazarus, it was (of course) sitting in the lazarus-ytk directory and ran fine from that location. with the IDE running i managed (with a bit of effort) to load a project - just a single window with a digital clock running in it, my standard test program. it compiled and then ran successfully! here are the results of comparing the two ELF binaries, one built before i started for GTK2, the other just built for YTK: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i user@test:~/Pascal/Clock$ ls -l 'project1 ('*-rwxrwxr-x 1 user user 2985720 Mar 25  2025 'project1 (GTK2)'-rwxrwxr-x 1 user user 6570664 Mar 16 03:25 'project1 (YTK)'user@test:~/Pascal/Clock$ user@test:~/Pascal/Clock$ user@test:~/Pascal/Clock$ readelf -d 'project1 (GTK2)' | grep -i "needed" 0x0000000000000001 (NEEDED)           Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED)           Shared library: [libgdk-x11-2.0.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libgtk-x11-2.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libX11.so.6] 0x0000000000000001 (NEEDED)             Shared library: [libgdk_pixbuf-2.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libgobject-2.0.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libglib-2.0.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libgthread-2.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libgmodule-2.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libpango-1.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libcairo.so.2] 0x0000000000000001 (NEEDED)           Shared library: [libatk-1.0.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libc.so.6]user@test:~/Pascal/Clock$ user@test:~/Pascal/Clock$ user@test:~/Pascal/Clock$ readelf -d 'project1 (YTK)' | grep -i "needed" 0x0000000000000001 (NEEDED)           Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED)           Shared library: [libX11.so.6] 0x0000000000000001 (NEEDED)           Shared library: [libglib-2.0.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libgobject-2.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libpng16.so.16] 0x0000000000000001 (NEEDED)             Shared library: [libpangocairo-1.0.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libcairo.so.2] 0x0000000000000001 (NEEDED)           Shared library: [libgio-2.0.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libpangoft2-1.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libpango-1.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libharfbuzz.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libfontconfig.so.1] 0x0000000000000001 (NEEDED)           Shared library: [libfreetype.so.6] 0x0000000000000001 (NEEDED)           Shared library: [libm.so.6] 0x0000000000000001 (NEEDED)           Shared library: [libXext.so.6] 0x0000000000000001 (NEEDED)           Shared library: [libXrender.so.1] 0x0000000000000001 (NEEDED)           Shared library: [libXinerama.so.1] 0x0000000000000001 (NEEDED)             Shared library: [libgthread-2.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libgmodule-2.0.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libatk-1.0.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libc.so.6]user@test:~/Pascal/Clock$ i'll fix up my main machine's FPC tomorrow - it is just gone 4am here! cheers, rob   :-) ---------------------------------------------------------------------- robert rozee · 2026-03-15 15:19 Quote from: Fred vS on March 15, 2026, 03:46:56 pm@Rob: for your eyes only: https://github.com/fredvs/test/releases/download/vstrum/project1.zip that is extremely cool!    cheers, rob   :-) ---------------------------------------------------------------------- robert rozee · 2026-03-15 16:11 Quote from: Fred vS on March 15, 2026, 03:35:55 pm[...] after your test you may reinstall official fpc. i did just that in the end - ran the FPC install from SourceForge (fpc-laz_3.2.2-210709_amd64.deb) and everything on my main machine started working again. finally am really heading off to bed, it is now just after 5am here  cheers, rob   :-) ---------------------------------------------------------------------- abouchez · 2026-03-16 09:23 This is great job! Do you think there is a chance your YTK branch could be merged into Lazarus somewhat officially? Perhaps with some $ifdef$ in the official source and a new "YTK" LCL widget type? Ability to create pure X11 app could be a killer feature for Lazarus, especially waiting for GTK3 support to be finalized. ---------------------------------------------------------------------- JuhaManninen · 2026-03-16 13:29 Quote from: robert rozee on March 15, 2026, 09:29:10 amfor exactly the same reason that the Ardour project does, of course. https://ardour.org/ I found this:  https://www.phoronix.com/news/Ardour-Removes-GTK-Option I also doubt the final size is much smaller. However they seem to develop the lib further, adding features and fixing bugs which is a valid reason to fork a project. ---------------------------------------------------------------------- fifr · 2026-03-16 13:35 The only significant change that I found (at least in the version that I looked at), besides removing a lot of deprecated stuff, was that they added support for touch events (and unnecessarily broke ABI compatibility when doing so, btw). Everything else was only renaming some files. Maybe I missed something, of course. I only checked this for gtk, not gdk or gdk-pixbuf. ---------------------------------------------------------------------- robert rozee · 2026-03-16 13:43 Quote from: abouchez on March 16, 2026, 10:23:16 am[...] Do you think there is a chance your YTK branch could be merged into Lazarus somewhat officially? [...] technically, there is no reason why not. a there are still a few kinks to be resolved, and a good deal of testing would be required, but after that it should be possible to have it integrated into the Lazarus IDE in just the same way as GTK2, Qt5, and the others are; YTK being one more option that sits beside a list of other widget-set options. practically, i could see there being a great deal of push-back. in particular, some folks have raised concerns about incompatible licensing of the GTK2 source code on which YTK is based, although my personal view is that this concern could be resolved with relative ease. other folks seem to object to YTK posing a threat to the development of support for GTK3. yet other folks see dangers associated with effectively working directly with X11. cheers, rob   :-) ---------------------------------------------------------------------- PascalDragon · 2026-03-16 15:38 Important note for anyone wanting to use either GTK or YTK with static linking: both are licensed as LGPL, which means that you are not allowed to distribute a proprietary application cause the LGPL only allows dynamic linking for proprietary code. ---------------------------------------------------------------------- Fred vS · 2026-03-16 15:59 Quote from: PascalDragon on March 16, 2026, 04:38:44 pmImportant note for anyone wanting to use either GTK or YTK with static linking: both are licensed as LGPL, which means that you are not allowed to distribute a proprietary application cause the LGPL only allows dynamic linking for proprietary code. Not true, to be legal for LGPL v2.1: Facilitate Relinking: This is the "static linking requirement." You must provide your application's private static library (.a or .lib) so that a user can combine your code with their own modified version of YTK to create a new executable. Specifically, in your source create a directory containing the static .a ytk libraries you use AND the link to the original ytk source code + fifr-ytk source code. ---------------------------------------------------------------------- Fred vS · 2026-03-17 13:23 Quote from: Fred vS on March 16, 2026, 04:59:52 pmSpecifically, in your source create a directory containing the static .a ytk libraries you use AND the link to the original ytk source code + fifr-ytk source code. And for static linking of .a libraries stored in your source directory, use the excellent Guva tip. ---------------------------------------------------------------------- PascalDragon · 2026-03-19 21:36 Quote from: Fred vS on March 16, 2026, 04:59:52 pmQuote from: PascalDragon on March 16, 2026, 04:38:44 pmImportant note for anyone wanting to use either GTK or YTK with static linking: both are licensed as LGPL, which means that you are not allowed to distribute a proprietary application cause the LGPL only allows dynamic linking for proprietary code. Not true, to be legal for LGPL v2.1: That's why I wrote “distribute” which means as-is without any linking required by the user. ---------------------------------------------------------------------- Fred vS · 2026-03-19 23:23 Quote from: PascalDragon on March 19, 2026, 10:36:51 pmQuote from: Fred vS on March 16, 2026, 04:59:52 pmQuote from: PascalDragon on March 16, 2026, 04:38:44 pmImportant note for anyone wanting to use either GTK or YTK with static linking: both are licensed as LGPL, which means that you are not allowed to distribute a proprietary application cause the LGPL only allows dynamic linking for proprietary code. Not true, to be legal for LGPL v2.1: That's why I wrote “distribute” which means as-is without any linking required by the user. Okay, you're nitpicking as usual. Your best AI friend say: In short, in your distribution's readme.txt file, providing the link to the ytk static .a libraries + the link to the ytk source code (GitHub) + the link to your application (GitHub) is perfectly compliant with the LGPL license. The core goal of the LGPL (Lesser General Public License) is User Freedom. Unlike the standard GPL, which requires your entire app to be open source, the LGPL allows you to keep your app's logic private—on one condition: the user must never be "trapped" with the version of the library you provided. The license is designed to ensure two specific freedoms: -    The Right to Fix/Update: If a security bug is found in GTK or YTK, a user must be able to fix that bug in the library and "inject" it into your application without needing your permission or your help. -   The Right to Audit: A user has the right to see exactly how the open-source library is being used and to modify it to see how those changes affect the program. Why Static Linking is Tricky     With Dynamic Linking (.dll / .so): The user just replaces the library file on their hard drive. Easy.     With Static Linking (.exe): The library is "baked into" your application. The user can't replace it unless you provide the source code or object files so they can "re-bake" (re-link) the executable themselves. In short: The LGPL exists to make sure the library remains "free" and "replaceable," even if the application using it is not. Since you are providing your app's source code on GitHub, you are giving the user the ultimate "key" to exercise these freedoms. To Resume (The "Static Linking" Rule): If your app is...   Must share App Source?   Must share Library Source?   Must share Object Files?                         GPL     YES                                          YES                                  No (Source is enough)                         LGPL     NO                                          YES                                  YES Quote as-is without any linking required by the user. The application you distribute only needs to be "relinked" if the user wants to use other ytk libraries. ---------------------------------------------------------------------- robert rozee · 2026-03-20 00:03 the reality is that, in the case of FPC + Lazarus, the source code is freely available, and the end user can rebuild both FPC and Lazarus IDE from this widely available source code. there is ABSOLUTELY NO REASON why YTK should not be distributed as a part of the Lazarus package as downloadable from SourceForge, with YTK provided in the IDE as a selectable build mode. the question then becomes: what of a non-open-source application that a user of Lazarus wishes to create? this can be addresses as: what someone uses Lazarus to create is no business of the Lazarus developers. the 'beef' over the nature of said user-created application is entirely between the creator and and any 'offended' party. if a user of Lazarus chooses to use it to create an application that violates the LGPL, not our problem. just as if a user of Lazarus chooses to use it to create an application that enables the commission of some crime, not our problem. likewise, the Ford Motor Company is not responsible if someone uses a Ford Motor Vehicle to commit a bank robbery, a murder, or to deliver WMDs. we should be concentrating our efforts not on creating straw man arguments, but on figuring out how to get YTK fully integrated into the Lazarus IDE as a widget-set option available for users to select. the solution created by fifr still needs a little more work: - currently it works by being the 'default' option in the Lazarus IDE. it needs to be changed to a non-default, user selectable option called something like "YTK/X11 direct". just like GTK3 and Qt5 currently are. - it really should not need a modified version of FPC. - the process of creating the four .a files should be separated out. while the source code for YTK needs to remain available, it does not need to be distributed with the Lazarus IDE. just distributing the four .a files with the IDE should suffice. we are tantalizingly close to having a slot-in turnkey solution that can be presented to the Lazarus developers! cheers, rob   :-) ---------------------------------------------------------------------- Fred vS · 2026-03-25 20:30 To developers of Lazarus: seize this fantastic opportunity; it's a wonderful new string to your bow. Add the YTK widget to your toolkit. Tested with LazPaint, the result is perfect (+3 MB vs. GTK2). Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i $ readelf -d lazpaint | grep -i "needed" 0x0000000000000001 (NEEDED)           Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED)           Shared library: [libX11.so.6] 0x0000000000000001 (NEEDED)           Shared library: [libglib-2.0.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libgobject-2.0.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libpng16.so.16] 0x0000000000000001 (NEEDED)             Shared library: [libpangocairo-1.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libcairo.so.2] 0x0000000000000001 (NEEDED)           Shared library: [libgio-2.0.so.0] 0x0000000000000001 (NEEDED)           Shared library: [libpangoft2-1.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libpango-1.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libharfbuzz.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libfontconfig.so.1] 0x0000000000000001 (NEEDED)             Shared library: [libfreetype.so.6] 0x0000000000000001 (NEEDED)           Shared library: [libm.so.6] 0x0000000000000001 (NEEDED)           Shared library: [libXext.so.6] 0x0000000000000001 (NEEDED)           Shared library: [libXrender.so.1] 0x0000000000000001 (NEEDED)           Shared library: [libXinerama.so.1] 0x0000000000000001 (NEEDED)           Shared library: [libgthread-2.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libgmodule-2.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libatk-1.0.so.0] 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6] ---------------------------------------------------------------------- robert rozee · 2026-03-27 13:47 hi Fred,     it looks like everyone else has left the discussion  i feel the best way forward is to create a patch to one of the existing releases of Lazarus for Linux, as posted on SourceForge. my preference would be to use the .deb packages of version 3.6 as it has been out for a while now without any major problems; it would be hopeless to try to work with the GitLab sources as these represent a moving target. step 1: we need to figure out how to create a new "LCLWidgetType" entry (see attached screenshot) for Project -> Project Options -> Compiler Options -> Additions and Overrides, calling it something like "YTK/X11". this differs from what fifr has done, where he has just repurposed the existing "GTK2" option. step 2: next step is to figure out how to differentiate between "GTK2" and "YTK/X11". i presume that at the moment fifr's changes are just edits to various pieces of the LCL source code related to GTK2. at the least we need an extra flag to indicate YTK has been selected for building, and conditionally compile either the (original) GTK2 segments or fifr's (new) YTK segments, depending upon this YTK flag. or do we go down the more complicated route of creating a complete second set of routines, so we have an "original" GTK2 set of routines, and alongside this a "new" GTK2 (renamed as YTK) set. this path will likely involve a whole load more work, but be less of a kludge. step 3: examine what changes fifr has made to FPC. are these necessary? can they be achieved by instead making changes to only Lazarus code? ideally it would be nice to not need to make any changes to FPC. once the above 3 steps are completed, we should have a version of the Lazarus IDE that can still build ELF binaries for GTK2, but can also build ELF binaries for a new target called YTK/X11. and, more importantly, we can bundle this all up as a relatively small patch (plus the four .a files) that anyone can use by: a. downloading the original three .deb packages from SourceForge for Lazarus 3.6 (or whatever other version we pick), and install them as normal. then, b. run a patch program we supply that goes through and patches the Lazarus IDE's source and the LCL source to support YTK/X11, then, c. rebuild the Lazarus IDE and LCL. alas, i have absolutely no idea how to do most of this! i'm really hoping that fifr may be able to offer some pointers in massaging his code into the needed form, and indeed that perhaps valdir.marcos or zeljko may even chip in - in particular with the steps needed to add in a new "LCLWidgetType" entry in the Lazarus IDE. cheers, rob   :-) ---------------------------------------------------------------------- Thaddy · 2026-03-27 14:03 You are running behind, maybe mislead by the The Register publication (what @dbannon explained to some extend) Current focus is GTK3, with Qt6 (NOT 5!!) already Wayland proof as far is Wayland is, well, Wayland and a moving target on top of that:features that are in are frozen, but new API's are added). Do you really think a niche solution contributes to a real solution? ---------------------------------------------------------------------- fifr · 2026-03-27 14:16 Just to make a few things clear: ytk was only an exercise for me. I do not really see any value, mainly, because it's the latest gtk2 minus some removed deprecated/unused functions. You can just compile and statically link against the latest gtk2 as well. I did not make any changes to fpc but only to the gtk2 package that is shipped with fpc. And I only removed deprecated functions that are not available in ytk and would lead to linking failures. And of course I changed the (hard coded) dynamic linking to static linking. It is probably possible to either compile a static version of gtk2 or a dynamic version and link to it with some rpath flags (so there is no need to install the lib globally in the system). As long as there is no real development/maintenance of ytk as a separate product, I do not see any advantage in using ytk instead of gtk2. In my opinion it would be wasted time. That said, please note that I'm a happy Wayland user. It works pretty well for me and my use cases (and often better than x11). ---------------------------------------------------------------------- Fred vS · 2026-03-27 15:57 Quote from: fifr on March 27, 2026, 03:16:28 pmJust to make a few things clear: ytk was only an exercise for me. I do not really see any value, mainly, because it's the latest gtk2 minus some removed deprecated/unused functions. You can just compile and statically link against the latest gtk2 as well. I did not make any changes to fpc but only to the gtk2 package that is shipped with fpc. And I only removed deprecated functions that are not available in ytk and would lead to linking failures. And of course I changed the (hard coded) dynamic linking to static linking. It is probably possible to either compile a static version of gtk2 or a dynamic version and link to it with some rpath flags (so there is no need to install the lib globally in the system). As long as there is no real development/maintenance of ytk as a separate product, I do not see any advantage in using ytk instead of gtk2. In my opinion it would be wasted time. That said, please note that I'm a happy Wayland user. It works pretty well for me and my use cases (and often better than x11). Hello fifr. First of all, a huge thank you for your work. I find it excellent and it perfectly meets my needs. You demonstrate how to use a static library, and it works wonderfully. Of course, we can now use GTK2 libraries, but with your YTK libraries, all the dependencies are lighter. I tested it with complex applications, like LazPaint, and I didn't encounter any problems. The binary is only 3 MB larger with static libraries. I was also able to use the dynamic (.so) files of your fpc-ytk libraries. Wayland certainly has its advantages, but for X11, GTK2/LCL is excellent and stable, without FPC-specific dependencies or licensing issues like with Qt. In any case, I don't want your work to be lost; it could be useful to others. So I've done a release of your fantastic work: https://github.com/fredvs/lazfpc4ytk/releases . Of course, I would have preferred that the Lazarus developers adopt your YTK solution. Have fun. Fre;D ---------------------------------------------------------------------- Thaddy · 2026-03-27 15:58 I really appreciate such efforts, but it is not a long term solution: be warned you are spending effort which may become obsolete very soon. Stick to what needs to be done:GTK3(+) or Qt6 as default. ---------------------------------------------------------------------- Fred vS · 2026-03-27 16:04 Quote from: Thaddy on March 27, 2026, 04:58:45 pmI really appreciate such efforts, but it is not a long term solution: be warned you are spending effort which may become obsolete very soon. Stick to what needs to be done:GTK3(+) or Qt6 as default. Hello Thaddy. Actually, it's the exact opposite. GTK3 and GTK4 will quickly become obsolete, whereas fifr's solution is timeless; it works on old distros as well as current and future ones. And since Wayland has no plans to get rid of XWayland, fifr's solution is perfect for both X11 and XWayland. ---------------------------------------------------------------------- robert rozee · 2026-03-27 16:20 Quote from: Thaddy on March 27, 2026, 03:03:53 pm[...] Do you really think a niche solution contributes to a real solution? hi Thaddy,     a solution that is agnostic to the installed widget-set seems to hardly be niche. in using YTK it is possible to create an ELF binary with Lazarus that (fingers crossed) only requires that X11 be present. i see Fred vS has posted a similar comment as i wrote this. i say 'fingers crossed' in the sense that the remaining dynamic library dependencies of the generated ELF binary do still need to be closely examined to ensure that no "pieces of GTK" are still being made use of! testing will require finding a Linux distro that does not include any GTKx widget-set, create a VM running it, then copy into that VM a 'representative' set of ELF binaries created (outside of the VM) with Lazarus/FPC. if they run, all is good. if not, we may have a problem to resolve. it is important that Lazarus not be loaded into the VM, as doing so may pull in pieces of GTK as a dependency - thereby tainting it. fifr: i also much appreciate your work; you have demonstrated what is possible. your comment, "I did not make any changes to fpc but only to the gtk2 package that is shipped with fpc. And I only removed deprecated functions that are not available in ytk and would lead to linking failures", in itself provides further useful information; that troublesome GTK2 package that is shipped with FPC is what kind-of kicked off the present discussion in dbannon's thread: https://forum.lazarus.freepascal.org/index.php/topic,73405.0.html cheers, rob   :-)