Porteus

HI all,

I noticed that porteus 5.0 does not create the file /etc/ld.so.cache on startup.
This leads to problems with some applications.
If I insert a module in the terminal with activate or install a package ldconfig is executed
and the said file is created.
In RC3 this problem did not exist and I think in 5.0 it should be the same.

With the Porteus-XFCE-v5.0-x86_64.iso the /etc/ld.so.cache file is not existing after boot nor after activating e.g. the netsurf xzm. Running ldconfig as root sometimes (!?!) gives a bus error.
With the Cinnamon iso the file seems to be pre-existing (dated Feb 14, 2020). Running ldconfig creates a much smaller file.
What version do you run and what problems with what applications do you see?

<double post>

yeah.. this is one those things that's been pushed to the side for a while .. i don't think it would have been much different in RC3 ...
ldconfig is called by activate, so activating a module should 'fix' the issue (superficially) ..

originally, the cache was generated as part of the build process of each 003-DE module (technically after build, booted,generated then added back to the tree and rebuilt)
but as brokenman hand responsibility for 003-DEs to others, this trick was not apparent in the build scripts..
..jssouza it seems had an awareness of this, hence cinnamon and kde at least retained the cache in their trees ... myself and fulalas, not so much..

i see two ways to go: put it more firmly into the cache update part of the build process(ie. in cache-module script) or put it(ldconfig) in the boot process..
my thinking now, is more toward that ldconfig should added somewhere in the boot process (rc.S or something) so that any extra modules loaded are covered too..

Liveslak and I run ldconfig during boot, PartedMagic does it during the build.

yeah, i'll add it to the init processes somewhere for the next update..
in the meantime, workarounds are:
activate a module
possibly: cheatcode: cliexec=ldconfig
or stick it in /etc/rc.d/rc.local

@ncmprhnsbl
Thank you for the detailed answer.
I now know that a solution is being worked on.

ncmprhnsbl wrote:
...i don't think it would have been much different in RC3...

You are right, i checked again in my RC3.
The cache was included statically by me.

So i wait for the update and until then i use a modified rc.M
Thanks