Linux support.

[nesqi]

On what linux distribution was the linux-binary built?

I noticed that it's using libc-2.14, which is newer than my 2.13 used in most Debian versions.

Allot more people would be able to run Spriter if it was compiled for libc-2.13 and a 32bit system.

I doubt Spriter needs any 64-bit features.

[eien]

Hi nesqi,

file Spriter

Spriter: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x9ad330b89453ea5c95acff3c8a21723194889758, not stripped

ldd Spriter

linux-vdso.so.1 => (0x00007fff1b482000)

libQtGui.so.4 => /lib64/libQtGui.so.4 (0x0000003b2da00000)

libQtCore.so.4 => /lib64/libQtCore.so.4 (0x0000003b2ba00000)

libstdc++.so.6 => /lib64/libstdc++.so.6 (0x0000003f0cc00000)

libm.so.6 => /lib64/libm.so.6 (0x0000003f0a000000)

libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003f0ac00000)

libc.so.6 => /lib64/libc.so.6 (0x0000003f08c00000)

libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003f09400000)

libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x0000003f0bc00000)

librt.so.1 => /lib64/librt.so.1 (0x0000003f09800000)

libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x0000003f0b000000)

libpng15.so.15 => /lib64/libpng15.so.15 (0x0000003f0fc00000)

libz.so.1 => /lib64/libz.so.1 (0x0000003f09c00000)

libfreetype.so.6 => /lib64/libfreetype.so.6 (0x0000003f10800000)

libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x0000003f0b800000)

libSM.so.6 => /lib64/libSM.so.6 (0x0000003b2d600000)

libICE.so.6 => /lib64/libICE.so.6 (0x0000003f22c00000)

libXi.so.6 => /lib64/libXi.so.6 (0x0000003f11800000)

libXrender.so.1 => /lib64/libXrender.so.1 (0x0000003f0ec00000)

libXrandr.so.2 => /lib64/libXrandr.so.2 (0x0000003f10000000)

libXfixes.so.3 => /lib64/libXfixes.so.3 (0x0000003f14c00000)

libXcursor.so.1 => /lib64/libXcursor.so.1 (0x0000003f19800000)

libXinerama.so.1 => /lib64/libXinerama.so.1 (0x0000003f0f800000)

libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x0000003b2b200000)

libXext.so.6 => /lib64/libXext.so.6 (0x0000003f0e000000)

libX11.so.6 => /lib64/libX11.so.6 (0x0000003f0d000000)

libdl.so.2 => /lib64/libdl.so.2 (0x0000003f09000000)

/lib64/ld-linux-x86-64.so.2 (0x0000003f08800000)

libffi.so.5 => /lib64/libffi.so.5 (0x0000003f0c000000)

libuuid.so.1 => /lib64/libuuid.so.1 (0x0000003b2b600000)

libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003f10400000)

libxcb.so.1 => /lib64/libxcb.so.1 (0x0000003f0d800000)

libXau.so.6 => /lib64/libXau.so.6 (0x0000003f0d400000)

I believe that it should be straightforward to build for IA32 but as you know, packaging is a full time job. In the current situation it could be more interesting to freeze a version.

32bit CPU are 2000'th, i don't know why people are still using 32bit distro ..

Regards

[nesqi]

All I'm saying is that when the time comes to compile a new release for Linux, then

it would make sense to compile it for libc-2.13 and 32bit so that as many people as

possible can run it regardless if they have a good or bad reason for not running on a

later system.

spriter$ objdump -T Spriter | grep GLIBC_
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 atan2
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 strlen
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 sqrt
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.14  memcpy
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 __cxa_atexit
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 acos
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 memmove
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 __libc_start_main

[nesqi]

It looks like the symbol for memcpy

0000000000000000      DF *UND*  0000000000000000  GLIBC_2.14  memcpy

is the only reason for the requirement of glibc-2.14.

Se here for a list of solutions to this problem.

http://stackoverflow.com/questions/8823 ... -a-so-file

[lucid]

I'll see what I can do nesqi.

Probably not for the upcoming build because we're so far behind schedule

but I'll work on getting better support in the near future