Hey, we have forums!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - flabbergastedpickle

Pages: [1] 2
1
Never mind. No matter what I tried, I could not reproduce the problem on my machine even when forcefully building a 32-bit version of the app so this clearly has something to do with a discrepancy between build environments and that's that...

2
I was hoping you could produce 2 binaries you suggested in your previous email for me to test as I am not sure how I can check out older branch from icculus (what is the command for that?).

I think the current icculus code already creates properly working executables for me (at least 64-bit ones, BTW how do I build 32-bit one on a 64-bit machine?), so I would need to figure out how to get the original source of the HiB release... Any ideas?

3
I have some time this evening to do some testing... Any chance you could get me the two executables to test as discussed above? That would be awesome :-)

Alternately, is there a repository of source of older executables that I might be able to compile on my own?

4
Actually both of the scenarios you suggested would be interesting to test just to figure out where the problem lies.... If both of these don't exhibit the problem then we'll need to look into build environment/flags in hope to find the culprit...

Another interesting thing is that Myth2 dev built a fully dynamically linked version (including SDL) and the problem persists, albeit I get this weird error when trying to run it:

Inconsistency detected by ld.so: dl-close.c: 743: _dl_close: Assertion `map->l_init_called' failed!

This happens only a few times per session, though... What could this mean when the executable is supposed to be fully dynamic?

http://tain.totalcodex.net/forum/viewtopic.php?f=2&t=5800&start=15

5
Sorry to bother you again, but I am wondering can you tell me what exact OpenGL function did you add and what does it do? I am still having no luck trying to identify the source of this problem even on Aquaria-side. The old and new 32-bit binaries only differ in that the new one relies on system libs and yet when I LD_PRELOAD included one it still doesn't show any problems (unless I am missing something)...

6
Many thanks for all your help!

As it turns out apparently Myth does statically link against SDL and hence LD_PRELOAD has no effect in respect to SDL lib (AFAIK). I am curious to hear why is SDL being statically linked (hopefully they are not using some kind of hacked version) and if there is a way to get a build that is dynamically linked. Myth2 BTW is not open-source so there is no way for me to recompile it...

7
Never mind. I misunderstood what RPATH stood for. I thought it is a prefix for all lib paths but instead it is another path altogether that is searched before looking through system paths. Speaking of hacki-ish ways, couldn't I simply do LD_PRELOAD=path-to-lib executable and do one lib at a time? Alternatively, what version of patchelf would you recommend since there is no recent release for Ubuntu or any other distro (latest one was from 2008 or thereabouts)?

EDIT: tried LD_PRELOAD trick with all 4 of your libs as well as individual ones and no change. I also tried to preload alternative libGL.so.1.2 and that made no difference either... Is there still a point of trying patchelf?

8
Hmmm, this may be potentially possible but I would probably have to move all the libs into that new folder, no? Also, some libs are in /lib32/ and other are in /usr/lib32 folder... Is it possible to change that prefix for only some of the libs?

I am also suspecting that the game might be using statically linked SDL (although I have no proof at this point as nm executable gives me no symbols). so until I hear from the Myth 2 folks, it's going to be difficult to move forward...

Once again, many thanks for all your help!

9
So might it be simply a different SDL lib? Is it really that easy? Going to do some digging around...

(then again, Myth2 AFAIK does not link against it, or at least ldd does not report it)

10
Many thanks for the update! (and sorry to both you and the main dev for giving you the wrong title ;-)

Hmmm, plot thickens... I just tried both aquaria32 and aquaria64 and neither of them have artifacts any more. I did this doing the following:

cp -r /opt/Aquaria /opt/Aquaria.bak
cd /opt/Aquaria
cp -r ~/Downloads/Aquaria_update_linux/* .
./aquaria32
...
./aquaria64

This way I overwrote everything in the Aquaria folder with the stuff found inside Aquaria_update_linux folder. Then I simply ran aquaria32 and aquaria64

aquaria32: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped
aquaria64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped

ls -lshA /opt/Aquaria
8.0K -rwxr-xr-x   1 root root 4.2K 2012-01-18 00:24 aquaria
3.6M -rwxr-xr-x   1 root root 3.6M 2012-01-18 00:24 aquaria32
4.2M -rwxr-xr-x   1 root root 4.2M 2012-01-18 00:24 aquaria64
 32K -rw-r--r--   1 root root  32K 2012-01-16 17:48 aquaria.png
4.0K drwxr-xr-x   2 root root 4.0K 2012-01-16 17:48 config
4.0K drwxr-xr-x   7 root root 4.0K 2012-01-16 17:48 data
4.0K -rw-r--r--   1 root root 2.9K 2012-01-16 17:49 default-1.xml
4.0K drwxr-xr-x   4 root root 4.0K 2012-01-16 17:49 docs
 52K drwxr-xr-x 181 root root  48K 2012-01-16 17:48 gfx
4.0K drwxr-xr-x   2 root root 4.0K 2012-01-18 00:24 lib32
4.0K drwxr-xr-x   2 root root 4.0K 2012-01-18 00:24 lib64
 52K -rwxr-xr-x   1 root root  49K 2012-01-16 17:48 libgcc_s.so.1
244K -rwxr-xr-x   1 root root 242K 2012-01-16 17:48 libopenal.so.1
492K -rwxr-xr-x   1 root root 492K 2012-01-16 17:48 libSDL-1.2.so.0
1.2M -rwxr-xr-x   1 root root 1.2M 2012-01-16 17:48 libstdc++.so.6
4.0K drwxr-xr-x   2 root root 4.0K 2012-01-16 17:49 maptemplates
4.0K drwxr-xr-x   6 root root 4.0K 2012-01-16 17:48 _mods
4.0K drwxr-xr-x   2 root root 4.0K 2012-01-16 17:49 mus
4.0K -rw-r--r--   1 root root  276 2012-01-16 17:48 README-linux.txt
8.0K -rw-r--r--   1 root root 4.6K 2012-01-18 00:24 README.txt
4.0K drwxr-xr-x   8 root root 4.0K 2012-01-16 17:49 scripts
4.0K drwxr-xr-x   4 root root 4.0K 2012-01-16 17:48 sfx
4.0K -rw-r--r--   1 root root 2.6K 2012-01-16 17:48 usersettings.xml
 12K drwxr-xr-x   2 root root  12K 2012-01-16 17:48 vox
4.0K -rwxr-xr-x   1 root root 2.7K 2012-01-16 17:49 xdg-open

(there is still old 64-bit aquaria in there but I did not run that one)

My response: What the heck is going on? What did you change in the 32-bit build since the last time? What is even wierder is that there is no mention of libGL or libGLU in the ldd so what might be the cause of this? Is it perhaps libSDL (but Myth II does not even use that lib)?

Here is the ldd on my machine for Aquaria and Myth II:

$ldd ./aquaria32
   linux-gate.so.1 =>  (0xf771b000)
   libSDL-1.2.so.0 => /opt/Aquaria/./lib32/libSDL-1.2.so.0 (0xf76b9000)
   libpthread.so.0 => /lib32/libpthread.so.0 (0xf767b000)
   libopenal.so.1 => /opt/Aquaria/./lib32/libopenal.so.1 (0xf7631000)
   libstdc++.so.6 => /opt/Aquaria/./lib32/libstdc++.so.6 (0xf7543000)
   libm.so.6 => /lib32/libm.so.6 (0xf7519000)
   libgcc_s.so.1 => /opt/Aquaria/./lib32/libgcc_s.so.1 (0xf750c000)
   libc.so.6 => /lib32/libc.so.6 (0xf7392000)
   libdl.so.2 => /lib32/libdl.so.2 (0xf738c000)
   /lib/ld-linux.so.2 (0xf771c000)
   librt.so.1 => /lib32/librt.so.1 (0xf7383000)
$ldd ~/Games/Myth\ II/Myth2
   linux-gate.so.1 =>  (0xf77a4000)
   libGLU.so.1 => /usr/lib32/libGLU.so.1 (0xf770d000)
   libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7622000)
   libm.so.6 => /lib32/libm.so.6 (0xf75f7000)
   libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf75d9000)
   libc.so.6 => /lib32/libc.so.6 (0xf745f000)
   libGL.so.1 => /usr/lib/i386-linux-gnu/mesa/libGL.so.1 (0xf73ef000)
   libpthread.so.0 => /lib32/libpthread.so.0 (0xf73d4000)
   libdl.so.2 => /lib32/libdl.so.2 (0xf73ce000)
   /lib/ld-linux.so.2 (0xf77a5000)
   libglapi.so.0 => /usr/lib32/libglapi.so.0 (0xf73b8000)
   libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7282000)
   libXext.so.6 => /usr/lib32/libXext.so.6 (0xf726f000)
   libXdamage.so.1 => /usr/lib32/libXdamage.so.1 (0xf726b000)
   libXfixes.so.3 => /usr/lib32/libXfixes.so.3 (0xf7265000)
   libXxf86vm.so.1 => /usr/lib32/libXxf86vm.so.1 (0xf725e000)
   libdrm.so.2 => /usr/lib32/libdrm.so.2 (0xf7252000)
   libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf7233000)
   librt.so.1 => /lib32/librt.so.1 (0xf722a000)
   libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7226000)
   libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf721e000)

What do these two have in common (or had in common)?

EDIT: even if I just put aquaria32 in the /opt/Aquaria folder with no other files included (albeit I've already included addition of new files from the newfiles folder in the package you asked me to download before) it works without the glitches...


11
No problem! Actually, I just built the version from icculus with debug disabled (as per instructions on your site) and it works perfect and all the artifacts are gone, so this is definitely a problem with the ia32-libs. Let me know if you need the binary (I did not strip anything from the binary).

Once again, many thanks for all your help!

12
Here's my ldd output:

./aquaria: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./aquaria)
   linux-vdso.so.1 =>  (0x00007fff8bbb7000)
   libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x00007fc7c6540000)
   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc7c6323000)
   libopenal.so.1 => /usr/lib/libopenal.so.1 (0x00007fc7c6072000)
   libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc7c5d6b000)
   libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc7c5ae7000)
   libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc7c58d0000)
   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc7c5531000)
   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc7c532d000)
   libpulse-simple.so.0 => /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x00007fc7c5128000)
   libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007fc7c4ee1000)
   /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fc7c67fc000)
   librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fc7c4cd9000)
   libpulsecommon-1.0.so => /usr/lib/x86_64-linux-gnu/libpulsecommon-1.0.so (0x00007fc7c4a7a000)
   libjson.so.0 => /usr/lib/x86_64-linux-gnu/libjson.so.0 (0x00007fc7c4872000)
   libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007fc7c462e000)
   libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fc7c4412000)
   libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007fc7c4209000)
   libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007fc7c3fa1000)
   libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007fc7c3d9b000)
   libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fc7c3b98000)
   libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fc7c3991000)
   libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007fc7c3777000)
   libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007fc7c352d000)
   libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007fc7c305d000)
   libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007fc7c2e31000)
   libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007fc7c2c2a000)
   libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fc7c2a0e000)

Seems to complain about GLIBC 2.14. Latest Ubuntu ships with 2.13, so your version might be bleeding edge. Any chance it could be recompiled with 2.13?

13
This is what I get when I run those:

$ file ./aquaria
./aquaria: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.27, not stripped
$ ./aquaria
bash: ./aquaria: No such file or directory
$ ls -lshA
total 5.7M
3.7M -rwxr-xr-x   1 root root 3.7M 2012-01-16 13:14 aquaria
 32K -rw-r--r--   1 root root  32K 2011-11-03 19:28 aquaria.png
4.0K drwxr-xr-x   2 root root 4.0K 2012-01-01 23:44 config
4.0K drwxr-xr-x   7 root root 4.0K 2012-01-01 23:44 data
4.0K -rw-r--r--   1 root root 2.9K 2011-11-03 19:28 default-1.xml
4.0K drwxr-xr-x   4 root root 4.0K 2012-01-01 23:44 docs
 52K drwxr-xr-x 181 root root  48K 2012-01-01 23:44 gfx
 52K -rwxr-xr-x   1 root root  49K 2011-11-03 19:28 libgcc_s.so.1
244K -rwxr-xr-x   1 root root 242K 2011-11-03 19:28 libopenal.so.1
492K -rwxr-xr-x   1 root root 492K 2011-11-03 19:28 libSDL-1.2.so.0
1.2M -rwxr-xr-x   1 root root 1.2M 2011-11-03 19:28 libstdc++.so.6
4.0K drwxr-xr-x   2 root root 4.0K 2011-11-03 21:07 maptemplates
4.0K drwxr-xr-x   6 root root 4.0K 2012-01-01 23:44 _mods
4.0K drwxr-xr-x   2 root root 4.0K 2012-01-01 23:44 mus
4.0K -rw-r--r--   1 root root  276 2011-11-03 19:28 README-linux.txt
4.0K drwxr-xr-x   8 root root 4.0K 2012-01-01 23:44 scripts
4.0K drwxr-xr-x   4 root root 4.0K 2012-01-01 23:44 sfx
4.0K -rw-r--r--   1 root root 2.6K 2011-11-03 19:29 usersettings.xml
 12K drwxr-xr-x   2 root root  12K 2012-01-01 23:44 vox
4.0K -rwxr-xr-x   1 root root 2.7K 2011-11-03 19:29 xdg-open

Maybe I need to remove libs from that folder as they I suspect are 32-bit?

EDIT: tried without those libs in the folder and still the same problem.

14
Again, many thanks for the quick reply. 32-bit issue is an incredibly good point as both games affected are now known to be running in 32-bit so this very well might be it... Now if only we could prove it by running Aquaria in 64-bit without problems :-)

So, I downloaded the said file as instructed, backed up original install directory to /opt/Aquaria.bak and left a the old /opt/Aquaria to mess with. Then I copied all the contents of the Aquaria_linux/newfiles/ into the /opt/Aquaria folder, and finally copied Aquaria_linux/64bit/aquaria into the same /opt/Aquaria/ folder overwriting the old executable. However, now when starting the game I simply get:

./aquaria
bash: ./aquaria: No such file or directory
(I am running from the command line to monitor any potential output... The old version runs just fine from the command line)

The file has proper exec permissions (same as the old executable). Nothing else has changed on my system...

Any ideas?

Many thanks for all your help!

15
Thanks for the reply. This is the Humble Bundle version. I tried changing both framebuffer and darkbuffer and neither (or both) had any effect on the issue... Also, thanks for the .h file. I will try to include that in my report upstream...

As for OS/drivers, I guess each to their own... I have a MBP currently collecting dust on my desk as ideologically I don't agree with the way Apple works. Same for intel card. While its driver is in many ways inferior, which is in part because it is still fairly new, at least it is open and is supported (apart from the aforesaid buggy driver behavior), including suspend and other core usability matters.

Again, thanks for the info...

Pages: [1] 2