libgdk_pixbuf-2.0.so.o missing

[PDP-8]

I'm stumped.  Rxvt throws this error with CorePlus 12.0, but it depends:

1) From a fresh CorePlus 12.0, if I do a simple cloud-mode install of rxvt, (download and load) it shows up in the wbar and works as expected.

2) If I use the TC-Install gui in CorePlus to make a writable stick of itself, (on a different stick of course) and immediately try to install rxvt, it shows up in wbar but nothing happens.

I have double-checked that rxvt is in my onboot.lst file.

If I try to launch rxvt from within aterm, this is the error that is thrown:

Code: [Select]

error while loading shared libraries:
libgdk_pixbuf-2.0.so.o:
cannot open shared object file:
no such file or directory.
I'll do more research, but found it odd that the read-only CorePlus 12.0 could do a simple cloud mode of rxvt, but my own burn using the tc-installer gui for whatever reason, gets rxvt confused with the missing object library.

I have also used the apps util to check for missing tcz's and dependencies, but nothing appears wrong.

UPDATE:
A quick fix appears that adding
gtk-pixbuf2.tcz

was a quick fix to get rxvt working on the stick burned with CorePlus 12.0 tc-install gui.

This is a solution, but not sure if it's the best one.

[Rich]

Hi PDP-8
Here's what is happening. If you  grep  the  .dep  files of the ISO for  pixbuf  you find:

Code: [Select]

/cde/optional/gtk2.tcz.dep:gdk-pixbuf2.tcz
/cde/optional/icewm.tcz.dep:gdk-pixbuf2.tcz
/cde/optional/librsvg.tcz.dep:gdk-pixbuf2.tcz
If you continue up the tree:

Code: [Select]

rich@tcbox:~$ grep gtk2 /cde/optional/*.dep
/cde/optional/libglade.tcz.dep:gtk2.tcz
rich@tcbox:~$
rich@tcbox:~$ grep libglade /cde/optional/*.dep
/cde/optional/openbox.tcz.dep:libglade.tcz
rich@tcbox:~$
rich@tcbox:~$ grep librsvg /cde/optional/*.dep
/cde/optional/jwm.tcz.dep:librsvg.tcz
/cde/optional/openbox.tcz.dep:librsvg.tcz
rich@tcbox:~$It turns out  icewm, openbox, and jwm  pull in  gdk-pixbuf2.  All 3 of these are listed in  /cde/onboot.lst  which is what
the first 7 menu entries of the ISO use. So  gdk-pixbuf2  is already present.

When you did your install, you probably did not select one of those 3 window managers, so  gdk-pixbuf2  was not present.

The dependency on  gdk-pixbuf2  is new. The TC11 and TC10 versions do not have this dependency. Neither does the
TC12 x86_64 version.

Also, the  rxvt.tcz.info  files (x86 and x86_64) are out of date. They reflect the state of the TC10 version, even though
they were updated in TC11 and TC12.

Updated the  rxvt.tcz.dep  file in the TC12 x86 repository.

[PDP-8]

Thanks Rich - somehow you are always able to read my mind!

Great explanation, and thanks for the dependency update...

[Rich]

Hi PDP-8

... Great explanation, ...

Glad you enjoyed it.

... and thanks for the dependency update...

You're quite welcome.

[andyj]

Rxvt does not have a dependency on libgdk_pixbuf-2.0:

Code: [Select]

$ ldd urxvt
linux-vdso.so.1 (0x00007fff4c204000)
libm.so.6 => /lib/libm.so.6 (0x00007f3e1d020000)
libfontconfig.so.1 => /usr/local/lib/libfontconfig.so.1 (0x00007f3e1cfe0000)
libfreetype.so.6 => /usr/local/lib/libfreetype.so.6 (0x00007f3e1cd28000)
libXft.so.2 => /usr/local/lib/libXft.so.2 (0x00007f3e1cd10000)
libXrender.so.1 => /usr/local/lib/libXrender.so.1 (0x00007f3e1cb00000)
libX11.so.6 => /usr/local/lib/libX11.so.6 (0x00007f3e1c9e0000)
libXmu.so.6 => /usr/local/lib/libXmu.so.6 (0x00007f3e1c9c0000)
libXt.so.6 => /usr/local/lib/libXt.so.6 (0x00007f3e1c960000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f3e1c940000)
libc.so.6 => /lib/libc.so.6 (0x00007f3e1c7b8000)
/lib/ld-linux-x86-64.so.2 (0x00007f3e1d150000)
libbz2.so.1.0 => /usr/local/lib/libbz2.so.1.0 (0x00007f3e1c7a8000)
libharfbuzz.so.0 => /usr/local/lib/libharfbuzz.so.0 (0x00007f3e1c718000)
libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x00007f3e1c610000)
libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x00007f3e1c5d0000)
libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x00007f3e1c5a0000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f3e1c580000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f3e1c568000)
libgraphite2.so.3 => /usr/local/lib/libgraphite2.so.3 (0x00007f3e1c340000)
libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x00007f3e1c318000)
libuuid.so.1 => /lib/libuuid.so.1 (0x00007f3e1c310000)
libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x00007f3e1c2e8000)
libXau.so.6 => /usr/local/lib/libXau.so.6 (0x00007f3e1c2e0000)
libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x00007f3e1c2d8000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f3e1c2d0000)
libSM.so.6 => /usr/local/lib/libSM.so.6 (0x00007f3e1c2c0000)
libICE.so.6 => /usr/local/lib/libICE.so.6 (0x00007f3e1c2a0000)
libXext.so.6 => /usr/local/lib/libXext.so.6 (0x00007f3e1c288000)

What did you change regarding rxvt? Is this something the maintainer (me) should know about?

[Rich]

Hi andyj

... What did you change regarding rxvt? ...

I made no changes to  rxvt.  Nor would I without first consulting you.

... Is this something the maintainer (me) should know about? ...

Yes, yes it is.

All I did was diagnose the issue PDP-8 ran into:

Code: [Select]

tc@E310:~/temp$ wget http://tinycorelinux.net/12.x/x86/tcz/rxvt.tcz
--2021-02-23 08:53:51--  http://tinycorelinux.net/12.x/x86/tcz/rxvt.tcz
Resolving tinycorelinux.net... 89.22.99.37
Connecting to tinycorelinux.net|89.22.99.37|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 409600 (400K) [text/plain]
Saving to: 'rxvt.tcz'

rxvt.tcz                       100%[====================================================>] 400.00K   982KB/s    in 0.4s   

2021-02-23 08:53:52 (982 KB/s) - 'rxvt.tcz' saved [409600/409600]

tc@E310:~/temp$ unsquashfs -d rxvt rxvt.tcz
Parallel unsquashfs: Using 2 processors
9 inodes (205 blocks) to write

[===========================================================================================================|] 205/205 100%

created 9 files
created 10 directories
created 0 symlinks
created 0 devices
created 0 fifos
tc@E310:~/temp$ ldd rxvt/usr/local/bin/urxvt 2>&1 | grep -i gdk
        libgdk_pixbuf-2.0.so.0 => /usr/local/lib/libgdk_pixbuf-2.0.so.0 (0xb7c55000)
tc@E310:~/temp$

... Also, the  rxvt.tcz.info  files (x86 and x86_64) are out of date. They reflect the state of the TC10 version, even though
they were updated in TC11 and TC12. ...

Even though the  .info  files do not indicate it, changes were made to the 32 and 64 bit versions. Note the size differences.

32 bit:

Code: [Select]

-rw-rw-r-- 1 root staff 368640 Jul  6  2019 /10.x/x86/tcz/rxvt.tcz
-rw-rw-r-- 1 root staff 376832 Feb  8  2020 /11.x/x86/tcz/rxvt.tcz
-rw-rw-r-- 1 root staff 409600 Jan 30 18:48 /12.x/x86/tcz/rxvt.tcz
64 bit:

Code: [Select]

-rw-rw-r-- 1 root staff 376832 Jul  6  2019 /10.x/x86_64/tcz/rxvt.tcz
-rw-rw-r-- 1 root staff 372736 Jul  6  2019 /11.x/x86_64/tcz/rxvt.tcz
-rw-rw-r-- 1 root staff 397312 Jan 30 18:50 /12.x/x86_64/tcz/rxvt.tczI also don't know why the TC10 and TC11 versions both have a Jul 6 timestamp.

Maybe someone else submitted updates without first contacting you ??

[andyj]

These are the build depenencies for rxvt:

xorg-proto
Xorg-7.7-dev
fontconfig-dev
libXft-dev
ncursesw-utils

Looking through the build logs I see in TC 11:

Code: [Select]

checking for gdk-pixbuf-2.0... ok

But in TC 12 (for now, because it wasn't loaded as dependency to something else):

Code: [Select]

checking for gdk-pixbuf-2.0... no

Rxvt will use gdk-pixbuf if it finds it, but it is apparently optional. I am not using this configure option:

Code: [Select]

  --enable-pixbuf         enable integration with gdk-pixbuf for background images

The question is, for consistency, shall I force it ON or OFF? What do we gain or lose?

I took this to indicate rxvt.tcz.dep was changed:

Updated the  rxvt.tcz.dep  file in the TC12 x86 repository.

Hi andyj

... What did you change regarding rxvt? ...

I made no changes to  rxvt.  Nor would I without first consulting you.

Between these two comments I'm confused.

I use submitqc to calculate the size. I do recompile all the extensions I maintain for each TC version change, but I don't normally mark them as changed in the changelog if nothing else of any significance has changed. I used to say they were recompiled, but with over 200 info files I've gotten lazy and I don't put that in anymore unless there is another change too.

[Rich]

Hi andyj

... Between these two comments I'm confused. ...

I did not change  rxvt.tcz.  I did add  gdk-pixbuf2.tcz  to the  rxvt.tcz.dep  file in the TC12 x86 repository.
Correcting a dependency file after submission is not an unusual event.

... The question is, for consistency, shall I force it ON or OFF? What do we gain or lose? ...

I don't know the answers to those questions. I just ran  ldd  on the 6 extensions and determined that only the
32 bit TC12  version had a dependency on  gdk-pixbuf2.tcz.  I added that to the dependency file and noted that in my
post so you would be aware of it.

... but I don't normally mark them as changed in the changelog if nothing else of any significance has changed. I used to say they were recompiled, but with over 200 info files I've gotten lazy and I don't put that in anymore unless there is another change too.

I can appreciate that, but there are times when knowing that information can be useful, even if only recompiled.

Example:
A bug shows up because the compiler (or linker, or a dependency, etc.) behavior changed in some way, but there
is no record of anything changing.

Example:
Someone notices an extension was changed across 2 releases, but the change log indicates otherwise. So that
individual spends 45 minutes searching the forum to see who else might have sent in an update.

[andyj]

Experimenting with the rxvt builds, if I add support for Asian fonts (ZH, KR, and JP, used by >10**9 people), background images via pixbuf and 24-bit color it about doubles in size to just under 700k. The question is how much bloat can we tolerate in TC vs wide support?

[curaga]

We don't tend to have many Asian users, since their native text entry systems require a lot of pieces not present here. They get a better experience using the big distros.

[Juanito]

..and a background image is probably not a priority...

[PDP-8]

I don't need a background image either.  In fact, my setup looks exactly like the default TC Aterm.

When the dependency error first showed up, I thought that *maybe* I could fool it by using some sort of urxvt configuration foo to make it go away and not need the dependency.

in .Xdefaults:   (note - not a real urxvt option, just for example)

Code: [Select]

URxvt.pixelBuffer: false
I thought just adding something like this in .Xdefaults might work, but I'm not a urxvt zen master.  Not sure if something like this would work...

[andyj]

I wouldn't use a background image either, not because of the bloat, but it's just distracting (which is why I disable the core wallpaper, sorry). For posterity, it would look something like this:



There isn't a way to not have the dependency on gdk-pixbuf2 optional because it's not a plugin, so I'll recompile it without the background image and Asian font support. That will leave it just under 400kb and without the gdk-pixbuf2 dependency.

[PDP-8]

Thanks Andy!  Appreciate your efforts on this and other submissions.

I'm spoiled by TC though - where bloat is relative.   Is it ram-bloat, or disk-space bloat where multi-gigabyte storage devices are normal now.

For example, my 32 bit stick running Xvesa, loaded up with options from tc-install gui, and installing not much more than rxvt, and a single DejaVu ttf font to look good, along with the gdk-pixbuf2 dependency, results in only 70mb of ram use when seen with free-m.

And usually a little less when I clear the cache first.

Maybe I'm drifting OT, but personally I'm ok with that dependency if it turns out to be a splitting-hairs thing.

[andyj]

For now I'm looking at the size of rxvt.tcz, but according to Apps the combined size of the dependencies is more than 5 MB without gdk-pixbuf2. I don't know how much more space would be required with gdk-pixbuf2 or how likely it would be that it will already be loaded if it is a common dependency, but I do know that gdk-pixbuf2 for the background image is the only purpose it serves so it falls into my personal definition of bloat.

On other notes, there are a few patches to rxvt-unicode that I am experimenting with, like 24-bit color which adds about 4k. Another is sixel support, which lets you display graphics directly in the terminal window:



In theory with a script like lsix you could "ls" thumbnails of images in the terminal. This works in xterm on Slackware. Unfortunately, the sixel code for rxvt seems to use a lot of RAM (> 100 MB) and has some other problems so it will have to wait until someone fixes it. Seeing that it has been three years since the last update, that doesn't seem likely anytime soon.