Confirmed. Maybe 5.0.7 is in 3.3 RC1 where it is not in 3.2?
All in all, again, a really welcome addition. Thanks, Juanito (I messed up the quoting in the previous post)
I uploaded my first DSL extension also, netwide assembler for all. =) Hope I did not too bad with packaging it.I had the same problem with some extensions I am playing with makeing. 5.0.7 comes from the gcc-with-libs or gnu-utils.libstdc++.so.5.0.7 is added by gcc1-with-libs, since I would have compiled with this loaded I guess this is why the ntfsprogs symlink points to it. I confirm ntfsprogs wipes out the desktop icons because of this.
Edit ---- Before I re-post ntfsprogs.dsl - I thought it might be a good idea to check on the "correct" way to modify the package:
On boot, without loading any packages, /usr/bin/libstdc++.so is set up in DSL as follows:
# ls -l /usr/lib/libstdc++.* /usr/lib/libstdc++.so.5 -> /KNOPPIX/usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.5.0.5 -> /KNOPPIX/usr/lib/libstdc++.so.5.0.5
# ls -l /KNOPPIX/usr/lib/libstdc++.* /KNOPPIX/usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.5 /KNOPPIX/usr/lib/libstdc++.so.5.0.5 is a file, not a symlink
gcc1-with-libs.dsl only contains one /usr/bin/libstdc++.so file:
ls -l /ramdisk/tmp/gcc1-with-libs/usr/lib/libstdc++.* /ramdisk/tmp/gcc1-with-libs/usr/lib/libstdc++.so.5.0.7
my initial ntfsprogs.dsl package contained the following symlink:
ls -l /ramdisk/tmp/ntfsprogs/usr/lib/libstdc++.* /ramdisk/tmp/ntfsprogs/usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.7
From all of this, I guess the correct thing to do would be to delete the lib/libstdc++.so.5 symlink in the ntfsprogs package and let it use the default DSL symlink.
Could somebody confirm that this is the correct assumption?I can't recall having any particular problems with that lib while gcc1-with-libs was installed, so ..
Since you compiled ntfsprogs against the newer lib, I'd be inclined to include the newer lib from gcc1-with-libs and its soname symlink in the ntfsprogs extension and overwrite the older library. This would probably be a definite must if (? - I haven't checked) there are headers for the newer lib in gcc1-with-libs and these got included during the compile.
The convention is that newer minor releases of libraries are not supposed to break applications that depend on older versions, so it should be ok (this rule doesn't always seem to work, but that's the theory).
You could try just using the existing older version of the library on the system. People keen to strip a few kB from extensions might say testing this is a must.
Since this is an extension that could do real harm if it goes wrong, I'd be inclined to play it safe and include dependant libs that match those present during the compile if headers got included.I would agree with WDef that if you compiled against the 5.0.7 library, you should use that instead and be on the safer side.
However, with a quick look at the (current) ntfsprogs.dsl in testing, it seems like - it doesn't need libstdc++ at all (using ldd, it seems like it only needs libc) - you can strip out "libntfs.la" (afaik .la files are useful for recompiling)Next Page...
original here.
(I messed up the quoting in the previous post)