Ancient Domains of Mystery - Page 2 - maemo.org

lma | # 11 | 2012-10-07, 13:21 | Report

Ah, so it's dynamically linked but bundled with its own private libs? Let's see...

Nope:

Code:

$ /lib/ld-2.5.so --library-path ./libs ./adom 
./adom: error while loading shared libraries: ld-linux-armhf.so.3: cannot open shared object file: No such file or directory

Originally Posted by szopin View Post

Make sure ld-2.5.so is so named in diablo, (running 'ls /lib/ld*' should tell you that, change the last line accordingly) libs folder can be deleted at this point, so only files needed are run script and adom raspbian binary. When trying to run it cried missing libtinfo.so, symlink to libncurses did the trick:

Getting farther, but still no go:

Code:

$ /lib/ld-2.5.so  ./adom 
./adom: /lib/libc.so.6: version `GLIBC_2.7' not found (required by ./adom)

Last edited by lma; 2012-10-07 at 13:26.

The Following 2 Users Say Thank You to lma For This Useful Post:
Addison, szopin

szopin | # 12 | 2012-10-07, 14:06 | Report

I was getting that lix-armhf missing when trying to mix provided libs with -2.5 (overwriting 2.13 with 2.5 was my first attempt) that GLIBC_2.7 looks like the final nail though, unless diablo kernel is just new enough to run a bit newer glibc?

szopin | # 13 | 2012-10-07, 14:36 | Report

I've uploaded N900's libc here: http://depositfiles.com/files/dxz1kuz1i

You could try unpacking it in the directory where run script and binary are and do:

Code:

export LD_LIBRARY_PATH=.
./run

Most likely you'll end up with the fatal kernel too old message, but I'm out of ideas at this point

The Following User Says Thank You to szopin For This Useful Post:
Addison

lma | # 14 | 2012-10-07, 14:57 | Report

Originally Posted by szopin View Post

unless diablo kernel is just new enough to run a bit newer glibc?

Or maybe figure out what symbols (if any besides 'GLIBC_2.7') it needs out of glibc 2.7 and give them those in a separate lib.

Originally Posted by szopin View Post

I've uploaded N900's libc here:

I don't think that will help (even if it starts, it will probably crash due to the different instruction sets).

But... since you mention it, Fremantle runs 2.5 too, right? Let's have a look... Apparently Nokia patched it to also report support for 2.7, debian/patches/eventfd.diff should apply easily on the Diablo version too.

Of course this is all academic, it would be much easier than either of the above to just rebuild adom for Diablo :-)

The Following User Says Thank You to lma For This Useful Post:
Addison

szopin | # 15 | 2012-10-07, 15:07 | Report

Closed source, not gonna happen. When you say Nokia patched it to report 2.7 - any way to trick it outside of patching libc (not even sure how to do that)? If it is just a patch in reporting, did they also patch something in to return kernel too old msg? The above approach shouldn't crash anything except adom, as Addison managed to run quite a few console-only N900 binaries on his N800, was hoping N900 libc wouldn't complain (vs raspbian 2.13 which is a lot newer)

The Following User Says Thank You to szopin For This Useful Post:
Addison

lma | # 16 | 2012-10-07, 15:27 | Report

Originally Posted by szopin View Post

Closed source, not gonna happen.

Ah, so it is :-(

Originally Posted by

When you say Nokia patched it to report 2.7 - any way to trick it outside of patching libc (not even sure how to do that)?

Might be doable. The adom binary seems to require only a couple 2.7 functions:

Code:

$ readelf -a adom  | grep @GLIBC_2.7
    18: 0000980c     0 FUNC    GLOBAL DEFAULT  UND __isoc99_sscanf@GLIBC_2.7 (4)
    74: 000097d0     0 FUNC    GLOBAL DEFAULT  UND __isoc99_fscanf@GLIBC_2.7 (4)

so something like this could work.

Originally Posted by

If it is just a patch in reporting, did they also patch something in to return kernel too old msg?

No, the Fremantle libc is just 2.5 plus a few patches, it doesn't need a newer kernel for anything.

Originally Posted by

The above approach shouldn't crash anything except adom, as Addison managed to run quite a few console-only N900 binaries on his N800, was hoping N900 libc wouldn't complain (vs raspbian 2.13 which is a lot newer)

Just tried it:

Originally Posted by

$ LD_PRELOAD=./libc-2.5.so /lib/ld-2.5.so ./adom
Illegal instruction (core dumped)

The Following 2 Users Say Thank You to lma For This Useful Post:
Addison, szopin

szopin | # 17 | 2012-10-07, 15:43 | Report

Originally Posted by lma View Post

Ah, so it is :-(

Sadly, yes. Jochen from the adom team said he might look into making maemo version (they have amiga/raspbian and are pretty happy with fringe compatibility) but he didn't have the hardware. I offered to lend him my spare N900 for testing, but it seems raspian binary is fine for fremantle and this would not help diablo

Originally Posted by

Might be doable. The adom binary seems to require only a couple 2.7 functions:

Code:

$ readelf -a adom  | grep @GLIBC_2.7
    18: 0000980c     0 FUNC    GLOBAL DEFAULT  UND __isoc99_sscanf@GLIBC_2.7 (4)
    74: 000097d0     0 FUNC    GLOBAL DEFAULT  UND __isoc99_fscanf@GLIBC_2.7 (4)

so something like this could work.

Interesting... Would this require diablo-toolchain, or can this possibly be done on N900?

Originally Posted by

Just tried it:

Hmmm, did they possibly update ld.so while faking libc reporting? I can upload N900's ld if that might help

The Following User Says Thank You to szopin For This Useful Post:
Addison

szopin | # 18 | 2012-10-07, 15:52 | Report

Just checked some history posts of Addison fighting with adom, glibc-2.7 showed up even when trying to qemulate 10 year old adom binary (1.1.1, yeah adom's been resurrected after a decade), so it was definitely qemu crying fould, not the adom binary at that point, one solution would be getting diablo qemu binary if someone has access to diablo tool-chain

The Following User Says Thank You to szopin For This Useful Post:
Addison