Shop OBEX P1 Docs P2 Docs Learn Events
tokenizer.so for x86_64 — Parallax Forums

tokenizer.so for x86_64

bjaneskobjanesko Posts: 2
edited 2011-08-21 08:45 in BASIC Stamp
Hello. I am new to the BASIC Stamp. I'm attempting to run the bstamp tools on an x86_64 Linux box. Both bstamp, and the example program provided by Parallax with the "BASIC Stamp Tokenizer", give error message

./tokenizer.so: wrong ELF class: ELFCLASS32: Success

First, I assume that this is because tokenizer.so is compiled for i386 32-bit architecture. Is this correct? Second, is there anything that I can do to fix this, short of "run it on a different computer"?

Comments

  • chaugen1chaugen1 Posts: 6
    edited 2011-08-19 14:36
    I am having the same problem here. Example "Stampapp" compiles just fine, but just run into problems while trying to run it.

    bjanesko, any news on your end? figure anything out?

    maybe if we could get the source code and compile it ourselves on a 64-bit OS

    Also, any way to reverse engineer the windows tokenizer.dll (and re-compile it in linux) seems to work on 64-bit windows just fine?
  • TorTor Posts: 2,010
    edited 2011-08-20 03:43
    What Linux distros are you both using? Many x86_64/amd64 Linux distros also provide a 32-bit environment. On my Debian amd64 distro, for example, I install a standard package called 'ia32-libs' and all 32-bit applications (including those I use with my propeller) run without problems. Other distros will often have some similar option available for their 64-bit varieties.

    -Tor
  • chaugen1chaugen1 Posts: 6
    edited 2011-08-20 15:40
    I am currently running Ubuntu 11.04 Natty Narwhal, just because I wanted to try it out. I do plan on dual-booting with 10.04 soon so I will keep you posted on if it happens on that too.

    As far as the ia32-libs, I double checked and sure enough it is already installed. I ran the sample program again and it failed when calling the tokenizer with the same ELFCLASS32 problem.

    I have gotten the windows DLL file de-compiled, now I just need to convert it to 64-bit assembly... and recompile it... and I should be good to go? right? If anyone has any experience converting/translating 32 to 64 bit asm, let me know, give me some tips.

    If I get it done, I'll be sure to post it on SourceForge so no one else has to go through the same hassle.

    Or if anyone has any suggestions about getting the 32-bit file to work on amd64... please share

    -Cor
  • $WMc%$WMc% Posts: 1,884
    edited 2011-08-20 19:01
    And they say Windows has to many bugs.....
  • chaugen1chaugen1 Posts: 6
    edited 2011-08-20 20:42
    lets keep the Linux BASH-ing... get it!! haha to a minimum... I am running windows 7 side by side with Ubuntu and tend to use windows most of the time. The real reason I switched to Ubuntu was because I was having issues with wxPython installing properly, and that's what I want to use to interface the tokenizer. I have not had any issues with python on Linux so far so that is why I am trying to get tokenizer.so to work on my current setup. If necessary I will revert to a 32-bit version but I like to see this as a sort of challenge to myself. And eventually we'll go to a 128-bit system, just as we have come from 8, 16, and 32 bit systems, so this should at some point benefit all BASIC Stamp enthusiasts, who write their own IDEs.

    All OS's have pros and cons, just trying to find the one that fits best for the situation.
  • Kevin WoodKevin Wood Posts: 1,266
    edited 2011-08-20 20:49
    >>> And they say Windows has to many bugs.....

    But this isn't a bug...

    @chaugen1 - Did you try recompiling the source from here...http://sourceforge.net/projects/bstamp/files/

    I compiled it on Scientific Linux x64, and running ldd against the binary shows it linked against lib64. It runs... but doesn't find a BS2 because I need a usb/serial for my HW board...

    So give it a try and let us know how you fare.
  • chaugen1chaugen1 Posts: 6
    edited 2011-08-20 22:08
    I'll be sure to check that out tomorrow and let you know how it goes.

    As far as the de-compiled DLL file goes, I had to scratch it. it wasn't what I thought it would be. Instead I went ahead a did "objdump -D" on the .so file so i will be trying to convert that to 64-bit assembly and then compiling that.

    does anyone know of a 32 to 64-bit converter? If it does not exist, it might be a good project for Github. It wouldn't do everything for you but simply scripting the register changes would be nice, eventually building up to a full-blown converter.

    -Cor
    Code free and prosper
  • TorTor Posts: 2,010
    edited 2011-08-21 04:14
    Decompiling a Windows 64-bit lib and re-assembling for 64-bit Linux? That's entirely the wrong approach.. it's much better to either a) figure out why the 32-bit compat libs won't work, or b) go the source code way and go native.

    I may have to download these tools myself just to get a look, but whatever the cause of the original problem it's just wrong to try going via 64-bit Windows DLLs and de-reassembly.

    -Tor
  • chaugen1chaugen1 Posts: 6
    edited 2011-08-21 08:45
    You are absolutely right. it was dumb to even go near the DLL. I'll be looking into both of your methods at the same time to maybe get one that works.
Sign In or Register to comment.