Elias came up witha good solution to that a while ago.

My best guess: Sconvolt.bin is a 64 bit executable, but Knoppix is 32 bit.

Show the output of "stat Sconvolt.bin" and "file Sconvolt.bin" if you would.

[EDIT]

Building the monolithic library is an option in Cmake when you compile allegro. (WANT_MONOLITH)

So if the Knoppix live CD is 32 bit, it can't run Sconvolt.bin. If you compiled everything as 32 bit then it would probably work. IIRC, you can compile 32 bit progs from gcc by using the -m switch, but it'd probably be easier to do it in a virtual machine using a 32 bit distro. Of course, this implies that anybody trying to run it on a 64 bit distro would have the 32 bit compatibility libraries, which is usually the case. Maybe you could provide both versions?

If it doesn't run on Knoppix 64 bit, I don't know what the trouble is.

There are a few things you'll have to check.

• The file mode to make sure everything that needs to be executable is.

• Obviously the processor architecture as Arthur pointed out.

• The Allegro shared object library or your own program may have additional dependencies, which may not exactly match what is available on each system, so to be safe you'd have to distribute those as well.

• If your distro uses SELinux then you may have to make sure the appropriate context is applied to your files and/or the device they are on.

For the dependencies check the output of ldd ./liballeg.so.4.4 and ldd ./Sconvolt.bin. Those should list mandatory dynamically loaded libraries that are loaded by the linker at run-time. They typically have paths in them. IIRC, those paths can be either absolute or relative. Make sure whatever paths they are have matches within the system you're trying to run on. If not you may need to copy libraries to a relative path in order to link with them. I'm not 100% sure what the difference is between relative and absolute paths when linking.

bambams@test-chamber-1:~/src$ cd ldd-example/
bambams@test-chamber-1:~/src/ldd-example$ ls -la
total 20
drwx------  2 bambams bambams 4096 Dec 24 16:18 .
drwx--x--x 65 bambams bambams 4096 Dec 24 16:18 ..
-rw-------  1 bambams bambams   76 Dec 24 16:11 main.c
-rw-------  1 bambams bambams  190 Dec 24 16:17 Makefile
-rw-------  1 bambams bambams   78 Dec 24 16:09 so.c
bambams@test-chamber-1:~/src/ldd-example$ make
gcc -c -fPIC -Wall -o so.o so.c
gcc -o libmy.so -shared -Wl,-soname,libmy.so so.o
gcc -c -fPIC -Wall -o main.o main.c
gcc -o a.out libmy.so main.o
bambams@test-chamber-1:~/src/ldd-example$ ls -la
total 44
drwx------  2 bambams bambams 4096 Dec 24 16:18 .
drwx--x--x 65 bambams bambams 4096 Dec 24 16:18 ..
-rwx------  1 bambams bambams 7138 Dec 24 16:18 a.out
-rwx------  1 bambams bambams 6432 Dec 24 16:18 libmy.so
-rw-------  1 bambams bambams   76 Dec 24 16:11 main.c
-rw-------  1 bambams bambams 1400 Dec 24 16:18 main.o
-rw-------  1 bambams bambams  190 Dec 24 16:17 Makefile
-rw-------  1 bambams bambams   78 Dec 24 16:09 so.c
-rw-------  1 bambams bambams 1520 Dec 24 16:18 so.o
bambams@test-chamber-1:~/src/ldd-example$ LD_LIBRARY_PATH=$(pwd) ./a.out
Hello
bambams@test-chamber-1:~/src/ldd-example$ ldd ./libmy.so ./a.out 
./libmy.so:
	linux-vdso.so.1 =>  (0x00007fff13f8b000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f358a019000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f358a5b3000)
./a.out:
	linux-vdso.so.1 =>  (0x00007fffb09c5000)
	libmy.so => not found
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb12e9b5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fb12ed4e000)
bambams@test-chamber-1:~/src/ldd-example$ LD_LIBRARY_PATH=$(pwd) ldd ./a.out 
	linux-vdso.so.1 =>  (0x00007ffff99e9000)
	libmy.so => /home/bambams/src/ldd-example/libmy.so (0x00007fdcc5333000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdcc4f9c000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fdcc5536000)
bambams@test-chamber-1:~/src/ldd-example$ 

It's really rather silly to distribute shared object files like this though. They're intended to be shared, but when they're bundled like this they tend not to be. You're better off just statically linking when possible. That said, I'm not sure how easy or difficult it is to statically link an Allegro program. I suppose it depends on how hard the dependencies are to statically link too.