ldd doesn't work on shell scripts but take a copy of run-mudlet.sh (I don't use that myself so I an not familiar with what environment stuff it is probably trying to configure) under new name and in the copy prefix the bit that calls mudlet with ldd and report back with the output - that should report the libraries that cannot be found. For example in a build I have to hand this gives:
initially,mudlet with and without the run script failed, not being able to find libzip.so.2
I where and how I got the library, but it ended up in the mudlet bin directory, which means the script got past the error, but then came the xcb error. I played with ldd and googling the error message for 2-3 hours and had decided that it had exceeded my attention span, but I couldn't let it go. ldd claimed libzip.so.2 was the only file not found and find said the only copy was in the mudlet bin dir, so what if I put the library in the same place as libzip.so.1 list by ldd, /lib/x86_64-linux-gnu/...
it works, using just the mudlet executable. the shell script stil has the problem.
Well something like libzip.so.2 could be a symbolic link to a real file with more numbers, and if it is a dangling symlink there is NOT such a file on the other end of the link (the symlink literally contains little else than the path to the real file so will easily be less than 100 bytes of so) - try a ls -l ./libzip.so.2 in that directory and see what the real file (on the end of the "->") is. I find it hard to believe that the wanted library is not around as lots of things use it and it is free after all. Unusually, I am not running Debian Linux at present, (having to run 'Doze to update my Sat. Nav. with some manufacturer's updates and they only support Doze/Macs *sigh*) but I'll see what and where the full size library is when I get back to normal...
I am trying to upgrade to 3.0.0-delta on this debian 32bit computer. I uninstalled the 2.1 using aptitude and installed 3.0 using the .run file download.
Using the desktop icon didn't work, and found I had to give execute privileges to the ..bin/mudlet file. Then I was able to execute ..bin/run-mudlet.sh.
However now I get the error:
./mudlet: /home/ashley/mudlet-3.0.0-delta/bin/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /usr/lib/i386-linux-gnu/libicui18n.so.52)
./mudlet: /home/ashley/mudlet-3.0.0-delta/bin/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /usr/lib/i386-linux-gnu/libicuuc.so.52)
But this is odd because libstdc++.so.6 is present in the /bin directory in that given path. So I'm wondering if the wrong version was bundled in the 32bit archive? Also, I have libstdc++4.9.2-10.dev and libstdc++6 (which is 4.9.2-10) installed on this system.
I'm not familiar with that method of installation (as I, of course, have the source code being repeatedly being edited and recompiled in an IDE) but ldd also works if given the full path to a libXXX.so type file so I'd try:
and see what that reports as missing - then try and the (file)name of what it says with: locate xxx - at a guess though I wonder whether there is a mis-match between the libraries that are supplied in the .run file and your system ones...
I really like many of the improvements in the delta release, but is there a work-around the prevent the window from resizing? Or is my own option to take a later dev build and compile my own? I'm guessing that's the solution but that will be a new adventure for me.
Are you a MacOS user - I'm not sure of the issues but IIRC there has been problems on that platform (not my own unfortunately), perhaps Vadim might make an observation when he is able...