Debian Etch - GLIBC 2.4 dependency, possibility of static build, alternatives?

[xhajt03]

Hi *,

I installed the full version on Debian Etch. I only played the demo in browser previously so I wasn't aware of possible issues (especially after the previous experience with Samorost 2 which didn't require any special binaries and thus also worked perfectly on that machine). At first, I encountered the missed libnss3.so dependency mentioned in another thread and solved it by configuring LD_LIBRARY_PATH with a reference to the iceweasel/seamonkey directory in my launcher for Machinarium. However, the next problem was a complaint about the libc version - glibc 2.4 is stated as the minimum version. Unfortunately, Debian Etch only provides glibc 2.3.6. Is there an easy way to solve this (I suspect that there are no special features of glibc 2.4 used there anyway)? Would it be possible to get a static build of that binary so that it's less dependent on differences across the various Linux distributions? Or is it possible to provide an alternative to the binary (although possibly less convenient from user perspective - e.g. locate the flash player on your drive and start it with parameters X, Y and Z and also the full path reference to the first flash file which is 0000nnnn.nnn)?

Thanks

Tomas

[nicolas]

Try to see on http://packages.debian.org if you can find a more recent glibc.

In fact, the problem is that the game use a standalone Flash player which is directly distributed as a binary and which is proprietary. So, even if some dependencies could be not really essential, we can't change that. And there doesn't seem to be another solution to make a Linux binary for a Flash game than use this standalone player by Adobe. 

The main Flash file isn't one of these xxxxxxxx.xx (with x = 0 or 1), but is actually packaged into the binary. However, you can easily find on the Web a free Linux executable which is able to extract the raw SWF file from a Flash EXE (from Machinarium for Windows). It can be a solution if you really don't succeed to launch the Linux port. 

[kenritz]

What the hell are you people talking about?

Are you from another planet? 

This gibberish is way over my head!

Welcome to Earth!

I really envy you computer Genius`s 

                                             Jokingly yours!

                                              Kenny!

PS. I still have`nt  figured out, how to stop the clock from blinking on my VCR!

[xhajt03]

Try to see on http://packages.debian.org if you can find a more recent glibc.

In fact, the problem is that the game use a standalone Flash player which is directly distributed as a binary and which is proprietary. So, even if some dependencies could be not really essential, we can't change that. And there doesn't seem to be another solution to make a Linux binary for a Flash game than use this standalone player by Adobe. 

The main Flash file isn't one of these xxxxxxxx.xx (with x = 0 or 1), but is actually packaged into the binary. However, you can easily find on the Web a free Linux executable which is able to extract the raw SWF file from a Flash EXE (from Machinarium for Windows). It can be a solution if you really don't succeed to launch the Linux port. 

OK, I see. Newer glibc is not possible with Debian Etch, it's only supported for newer Debian versions, but I didn't want to upgrade the whole installation to the newer release (yet). I'll try to find such a decompiler and see how it works. Getting the SWF directly from the authors would be obviously somewhat easier, but let's hope that this approach works too. Thanks for your hint.

[xhajt03]

Try to see on http://packages.debian.org if you can find a more recent glibc.

In fact, the problem is that the game use a standalone Flash player which is directly distributed as a binary and which is proprietary. So, even if some dependencies could be not really essential, we can't change that. And there doesn't seem to be another solution to make a Linux binary for a Flash game than use this standalone player by Adobe. 

The main Flash file isn't one of these xxxxxxxx.xx (with x = 0 or 1), but is actually packaged into the binary. However, you can easily find on the Web a free Linux executable which is able to extract the raw SWF file from a Flash EXE (from Machinarium for Windows). It can be a solution if you really don't succeed to launch the Linux port. 

OK, I see. Newer glibc is not possible with Debian Etch, it's only supported for newer Debian versions, but I didn't want to upgrade the whole installation to the newer release (yet). I'll try to find such a decompiler and see how it works. Getting the SWF directly from the authors would be obviously somewhat easier, but let's hope that this approach works too. Thanks for your hint.

Alright. I managed to find the exe2swf tool and used it to extract machinarium.swf (I placed it in the same folder where the original Machinarium binary, i.e. the version with embedded player, was also installed). I also installed the latest update of the standalone Flash Player binary (release build) version 9; I know that the most recent version available is version 10, but that's exactly the version which doesn't work under Debian Etch due to the .so troubles described above (especially the glibc version) and the demo version running in a browser works OK with the version 9 plugin.

I created a shell script changing the directory first (as discussed in the thread related to launcher creation) and then starting the flashplayer binary from the directory containing the newly extracted machinarium.swf and providing it with the "machinarium.swf" file name as a parameter, I get a "nice" empty black screen. :-( I realized that after exiting the player, Machinarium.sol was created in the ~/.macromedia/... path as described in the launcher thread, so in spite of starting the standalone player in the right directory, it looked as if it still had troubles with using the right directory (although I'd BTW prefer storing the save file in the user specific directory anyway to allow different users share the same installation, but that's another story). To avoid this problem, I tried adding symbolic links to the 00, 01, 10 and 11 directories in that savefile location to make the other files accessible for the player. This worked to the extent that if I removed the savefile before running the shell script, it was not created any longer on the next run. However, the screen remained constantly black.

I also found that the player allows creating the "projector" binary (this time obviously based on the underlying version 9 of the Flash player rather than the originally used version 10). I created a new binary and modified the shell script to start this binary (again from the right directory). The only difference I observed was that the .sol file isn't being created any longer regardless of the availability or unavailability of the symbolic links to the 00, 01, 10 and 11 directories in the savefile location. Any further ideas, anybody?

[pepelopez]

Hi,

I'm still using Slackware 11, which also has GLIBC 2.3.

I managed to successfully run Machinarium by installing Flash Player 10 plugin (not standalone player) using this patch, which allows to use newer versions of flash with glibc 2.3. You can also hack it with an hex editor but this is faster:

http://svolli.org/software/eeepc/#flash10patcher

Then I extracted the .swf using the tool you mentioned, exe2swf, and just opened it from my web browser (well, I renamed it from machinarium.exe.swf to machinarium.swf, I suppose that doesn't matter but I don't like double extensions) from the same folder, with the 00, 01, etc as subfolders.

Edit: I have been able to patch the standalone player, I just renamed it to libflashplayer.so (as flash10patcher expects the file to have that name) and then renamed the resulting patched.libflashplayer.so to flashplayer. The bytes that need to be changed are the same so it worked flawlessly. That way I can run Machinarium outside the browser.

[xhajt03]

Try to see on http://packages.debian.org if you can find a more recent glibc.

In fact, the problem is that the game use a standalone Flash player which is directly distributed as a binary and which is proprietary. So, even if some dependencies could be not really essential, we can't change that. And there doesn't seem to be another solution to make a Linux binary for a Flash game than use this standalone player by Adobe. 

The main Flash file isn't one of these xxxxxxxx.xx (with x = 0 or 1), but is actually packaged into the binary. However, you can easily find on the Web a free Linux executable which is able to extract the raw SWF file from a Flash EXE (from Machinarium for Windows). It can be a solution if you really don't succeed to launch the Linux port. 

OK, I see. Newer glibc is not possible with Debian Etch, it's only supported for newer Debian versions, but I didn't want to upgrade the whole installation to the newer release (yet). I'll try to find such a decompiler and see how it works. Getting the SWF directly from the authors would be obviously somewhat easier, but let's hope that this approach works too. Thanks for your hint.

Alright. I managed to find the exe2swf tool and used it to extract machinarium.swf (I placed it in the same folder where the original Machinarium binary, i.e. the version with embedded player, was also installed). I also installed the latest update of the standalone Flash Player binary (release build) version 9; I know that the most recent version available is version 10, but that's exactly the version which doesn't work under Debian Etch due to the .so troubles described above (especially the glibc version) and the demo version running in a browser works OK with the version 9 plugin.

I created a shell script changing the directory first (as discussed in the thread related to launcher creation) and then starting the flashplayer binary from the directory containing the newly extracted machinarium.swf and providing it with the "machinarium.swf" file name as a parameter, I get a "nice" empty black screen. :-( I realized that after exiting the player, Machinarium.sol was created in the ~/.macromedia/... path as described in the launcher thread, so in spite of starting the standalone player in the right directory, it looked as if it still had troubles with using the right directory (although I'd BTW prefer storing the save file in the user specific directory anyway to allow different users share the same installation, but that's another story). To avoid this problem, I tried adding symbolic links to the 00, 01, 10 and 11 directories in that savefile location to make the other files accessible for the player. This worked to the extent that if I removed the savefile before running the shell script, it was not created any longer on the next run. However, the screen remained constantly black.

I also found that the player allows creating the "projector" binary (this time obviously based on the underlying version 9 of the Flash player rather than the originally used version 10). I created a new binary and modified the shell script to start this binary (again from the right directory). The only difference I observed was that the .sol file isn't being created any longer regardless of the availability or unavailability of the symbolic links to the 00, 01, 10 and 11 directories in the savefile location. Any further ideas, anybody?

OK, this trouble (empty black screen on startup) was simply due to the fact that the files in 00, 01, 10 and 11 were owned by a user unknown in this machine after unpacking the installation package and the access rights were set to 600. After I fixed this, it works with Flash Player 9...

[xhajt03]

Hi,

I'm still using Slackware 11, which also has GLIBC 2.3.

I managed to successfully run Machinarium by installing Flash Player 10 plugin (not standalone player) using this patch, which allows to use newer versions of flash with glibc 2.3. You can also hack it with an hex editor but this is faster:

http://svolli.org/software/eeepc/#flash10patcher

Then I extracted the .swf using the tool you mentioned, exe2swf, and just opened it from my web browser (well, I renamed it from machinarium.exe.swf to machinarium.swf, I suppose that doesn't matter but I don't like double extensions) from the same folder, with the 00, 01, etc as subfolders.

Edit: I have been able to patch the standalone player, I just renamed it to libflashplayer.so (as flash10patcher expects the file to have that name) and then renamed the resulting patched.libflashplayer.so to flashplayer. The bytes that need to be changed are the same so it worked flawlessly. That way I can run Machinarium outside the browser.

Very good. This approach works not only for the standalone player (flashplayer), but also for the original Machinarium binary. :-)

[binht4]

Does somebody know something easy method of upgrading GLIBC to version 2.4
from 2.3.6 without upgrading Etch to Lenny?
Thanks!