Cross compiling user space code

Hi folks,

I’m hoping someone can help me solve a very frustrating problem I’m having. I’d like to cross-compile a binary that I can then transfer to and run on my BeagleBoard. Sure, I can compile my application natively on the BeagleBoard, but a clean compile takes 17 mins…and I’m annoyed that I can’t get this to work. To that end, the contents of helloworld.cpp are:

#include <stdio.h>

int main()
{
fprintf(stdout,“Hello World\n”);
return 0;
}

I cross-compile the program thusly: arm-linux-gnueabihf-gcc helloworld.cpp -o hello

“ldd hello” produces: “not a dynamic executable”. A quick inspection of the /lib/arm-linux-gnueabihf/ and /usr/lib/arm-linux-gnueabihf/ directories shows them to be empty (huh?). So what am I missing? Is there a special package that I need to install on my system (Linux Mint 12)?

Any help is much appreciated,

Tony

sometimes on transfer to the BB i’ve had the executable change file type (ls -F) to non-executable.

TonyD., the executable flag on the permissions is set.

“ldd hello” on the host (my laptop, not the beagle) produces the “not a dynamic executable” output. To add to the weirdness, if I statically link when compiling (-static), then I get a binary that works on the Beagle. IOW, the libraries I need to compile the program exist, but compiling with dynamically loaded libraries is somehow screwed. I can’t believe that I’m the only person who: 1) is cross-compiling a user land program, and 2) has run into this problem since my toolchain is installed from the Ubuntu repos.

It is normal because your hello code is arm, and your host ldd doesn’t know arm format.
I don’t find cross-compile ldd, you can put it on beagleboard to get a try.

Hope this is helpful.

It is normal because your hello code is arm, and your host ldd doesn’t know arm format.

I don’t find cross-compile ldd, you can put it on beagleboard to get a try.

Bah! Good call; and stupid mistake by me. So here are the results of “ldd hello” on the Beagle:

libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x4022c000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x4023d000)
/lib/ld-linux.so.3 => /lib/arm-linux-gnueabihf/ld-linux.so.3 (0x40003000)

That looks good to me. However, trying to run the executable (i.e. ./hello) produces:
-bash: ./hello: No such file or directory

Which is confusing since ls -l hello produces:

-rwxrwxr-x 1 foo foo 5315 Apr 10 20:48 hello

shell problem. do you try something like /bin/sh then ./hello.
i remember bash was not supported in beagleboard, is it?

shell problem. do you try something like /bin/sh then ./hello.

But I can run natively-compiled binaries just fine (e.g. compiling helloworld.cpp on the Beagle and then running it). And as I noted in my initial post, I can statically compile the libraries into the binary and run it on the Beagle.

it may be path not setting well.
try /bin/sh first, then will it be ok? which dynamic library you would like to hello?

it may be path not setting well.
try /bin/sh first, then will it be ok? which dynamic library you would like to hello?

Tried it. Same result: /bin/sh: 6: ./hello: not found.

I really don’t think this is a shell problem. I think this is something to do with linking to the libraries.

Let me try another tack: has anyone on this list successfully cross-compiled any armhf user-space binaries that actually run? If so, then I would love to learn the steps you took to accomplish that, including how you set up your toolchain. Note that I’m not asking how to cross-compile a kernel; that’s old hat.