The Testing Area :: April extensions



Quote
/etc/ld.so.conf does get updated with the /opt/gtk+-2.12.9/lib directory in the most recent DSLs


Perhaps we need to ping Robert and see if he would consider changing this so the additions are made at the top of ld.so.conf.  That sed line above for example will do it.

Similarly: /opt/bin might be best at the beginning of PATH for the same reason, if it isn't already - so that extension  binaries get found before those on the system.

In case you need to add the little script above:  I'll edit it  now to exit if the line has already been added.
Quote

Perhaps we need to ping Robert and see if he would consider changing this so the additions are made at the top of ld.so.conf.  That sed line above for example will do it.


The only issue I see is that adding to the beginning of /etc/ld.so.conf can break things in base.  But that will happen whether they are added manually or automatically.  So I don't know if it would be good to do that universally for all extensions.  But a good idea nonetheless.It looks like DSL 5.x will be small enough not to have many conflicts when loading extensions, since the less in base the less there is to conflict with.  There is one app in base that depends on the base glib2, and I cannot remember the name or if it gets broken.  Usually newer libraries do not break old apps, but a possibility.

As for /opt/bin being at the beginning of $PATH I fully agree since when you load a .uci or .tar.gz you of course are wanting to use the commands in /opt/bin instead of /usr/* if there are duplicates.  With gtk+-2.12.9 installed, issuing the command 'fc-cache' will not work.  /opt/gtk+-2.12.9/bin/fc-cache has to be used.  I do not have symlinks in /opt/bin (I will add them before I resubmit) but the result would be the same - base fc-cache would be called up.  Maybe having /opt/bin at the beginning of the $PATH could be done.
Quote
/etc/ld.so.conf can break things in base.


If the uci is umounted, you mean an entry to /etc/ld.so.conf that no longer exists after ldconfig is run causes a problem?

Perhaps try testing this after umounting your uci.  Wouldn't it be fixed by just running ldconfig again after umounting?

EDIT: If not, easy enough to have another little script to REMOVE the line from ld.so.conf (or restore the backup).

Code Sample


#!/bin/bash

# Remove path to gtk libs from ld.so.conf

if ! grep -q '/opt/gtk+-2.12.9/lib' /etc/ld.so.conf; then
     # already done
      exit 1;  
fi

if [ -L /etc/ld.so.conf ]; then
   exit 1
fi

sed -i  '/\/opt\/gtk+-2.12.9\/lib/dg'  /etc/ld.so.conf

ldconfig

exit 0
Quote

Quote
/etc/ld.so.conf can break things in base.


If the uci is umounted, you mean an entry to /etc/ld.so.conf that no longer exists after ldconfig is run causes a problem?


Not that, but linking base apps to libs in an extension could possibly break the app.  But it is necessary of course to put the extension library path at the beginning of /etc/ld.so.conf with the gtk.uci extensions  and it seems to work pretty well.  

I am pretty sure that directory entries in /etc/ld.so.conf that do not exist or have no libs in them are harmless, though.
Re empty dirs in ld.so.conf: without  checking, that's what I assumed it would be.

Running ldd on everything in the executables directories and greping for your extension libs, if I haven't forgotten any bin dirs that is:

Code Sample
#!/bin/bash

DIR="/KNOPPIX/bin /KNOPPIX/usr/bin /KNOPPIX/usr/X11R6/bin /KNOPPIX/sbin /KNOPPIX/usr/sbin /KNOPPIX/usr/local/bin /KNOPPIX/usr/local/sbin"

CD=$PWD
for F in ${DIR}; do
cd ${F}
for G in *; do
H="$F/$G"
[ -d "$H" ] && continue
if [ -x "$H" ]; then
ldd "$H" 2>/dev/null | grep '/opt/gtk+-2.12.9/lib' && echo "[ $H ]"
fi
done
done

cd $CD



On tonight's old running dsl that gives:

Quote

libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x4005e000)
libpng12.so.0 => /opt/gtk+-2.12.9/lib/libpng12.so.0 (0x4007c000)
[ /KNOPPIX/usr/bin/Ted ]
libfontconfig.so.1 => /opt/gtk+-2.12.9/lib/libfontconfig.so.1 (0x4001b000)
libfreetype.so.6 => /opt/gtk+-2.12.9/lib/libfreetype.so.6 (0x40045000)
libexpat.so.1 => /opt/gtk+-2.12.9/lib/libexpat.so.1 (0x400c2000)
libxml2.so.2 => /opt/gtk+-2.12.9/lib/libxml2.so.2 (0x40211000)
[ /KNOPPIX/usr/bin/fc-cache ]
libfontconfig.so.1 => /opt/gtk+-2.12.9/lib/libfontconfig.so.1 (0x4001b000)
libfreetype.so.6 => /opt/gtk+-2.12.9/lib/libfreetype.so.6 (0x40045000)
libexpat.so.1 => /opt/gtk+-2.12.9/lib/libexpat.so.1 (0x400c2000)
libxml2.so.2 => /opt/gtk+-2.12.9/lib/libxml2.so.2 (0x40211000)
[ /KNOPPIX/usr/bin/fc-list ]
libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x4005e000)
libpng12.so.0 => /opt/gtk+-2.12.9/lib/libpng12.so.0 (0x4007c000)
[ /KNOPPIX/usr/bin/ted ]
libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x402f1000)
libtiff.so.3 => /opt/gtk+-2.12.9/lib/libtiff.so.3 (0x40310000)
[ /KNOPPIX/usr/bin/xtdesk ]
libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x40183000)
libpng12.so.0 => /opt/gtk+-2.12.9/lib/libpng12.so.0 (0x401a2000)
[ /KNOPPIX/usr/bin/xzgv ]
libtiff.so.3 => /opt/gtk+-2.12.9/lib/libtiff.so.3 (0x40029000)
libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x4007c000)
[ /KNOPPIX/usr/X11R6/bin/xpaint ]
libpng12.so.0 => /opt/gtk+-2.12.9/lib/libpng12.so.0 (0x4006b000)
libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x4008e000)
[ /KNOPPIX/usr/local/bin/bm_srv12 ]
libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x4001b000)
libpng12.so.0 => /opt/gtk+-2.12.9/lib/libpng12.so.0 (0x40039000)
[ /KNOPPIX/usr/local/bin/dillo ]
libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x40151000)
[ /KNOPPIX/usr/local/bin/gs ]
libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x40042000)
libtiff.so.3 => /opt/gtk+-2.12.9/lib/libtiff.so.3 (0x40060000)
[ /KNOPPIX/usr/local/bin/xsri ]


So if you feel like it run this on your doubtless more up to date dsl and it will give you an idea what is at risk of breaking from your uci, if it does break that is.

afaik newer libs like this aren't supposed to break apps depending on earlier minor releases with the same major release number.

Re
Quote
The only issue I see is that adding to the beginning of /etc/ld.so.conf can break things in base.  But that will happen whether they are added manually or automatically.  So I don't know if it would be good to do that universally for all extensions.


I think it would be worth trying.  That's why we have a testing repo. Robert may or may not agree.    Presumably? reversible by uninstalling the extension anyway.

EDIT: Another thank you - some of the old gtk2 apps in the repo are looking fabulous with this uci - a new lease of life!
Next Page...
original here.