nesqi Posted February 26, 2013 Report Share Posted February 26, 2013 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. Quote Link to comment Share on other sites More sharing options...
eien Posted February 26, 2013 Report Share Posted February 26, 2013 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 Quote Link to comment Share on other sites More sharing options...
nesqi Posted February 26, 2013 Author Report Share Posted February 26, 2013 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 atan20000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 strlen0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 sqrt0000000000000000 DF *UND* 0000000000000000 GLIBC_2.14 memcpy0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 __cxa_atexit0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 acos0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 memmove0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 __libc_start_main Quote Link to comment Share on other sites More sharing options...
nesqi Posted February 26, 2013 Author Report Share Posted February 26, 2013 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 Quote Link to comment Share on other sites More sharing options...
lucid Posted February 27, 2013 Report Share Posted February 27, 2013 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.