Cross-compilation

The answer depends somewhat (or a lot) on the details of the embedded system and your compiler. If your problem is that you are using dynamically linked libraries (.dll in Windows, .so in Linux, for example) and that having all of the required libraries exceeds the available space, then you may be able to "statically link" your executable, instead. This pulls the relocatable object code from the library into your app, but it brings in only the functions that are required and not everything in the library, thus the size of that one app is smaller. If *everything* is statically linked then the aggregate system size is much larger, so typically dynamic linking is preferred but there are exceptions.

This is the old "5 pound sack trick"

How do you fit 10 pounds of stuff into a 5 pound sack.

Answer:

Put in less stuff.

hamilton

PS: This means you will need to re-write all the libraries to make them smaller.

Or, possibly, the linker isn't currently stripping out unused functions. If that's the case, you can get rid of 5 pounds of stuff you aren't actually using, rather than having to do rewrites. Check your various and sundry settings, make sure you're stripping the crap out. Likewise, unoptimized code is brutal on size; maybe you can get away with turning on size optimization and recompiling everything.

Or maybe none of those tricks will work, or you're already using them, in which case it's time to start writing library code.

But I only used printf once!! :)

This is one of those "Depends" questions. How is your linker handling things? Is it REALLY libraries you are talking about and not DLLs and some such? Are you needlessly using floating point number *OR* linking in floating point libraries you don't need?

There are a LOT of unanswered questions on top of those.

LOL, yep, with the floating point version...

I.e., you are running x86 code with some set of libraries that were designed *for* the PC environment. Now, you are trying to move the same code to a different target while using "similar" libraries (similar in name/functionality but not implementation)

No, the embedded system is too small for the code that you want to run on it! :>

Your embedded system won't *run* without the "required libraries". That's like saying "I want to remove pages 6 through 9 of my code from the program and make it run".

This only makes sense if the stuff you remove isn't actually being used!

Look at your load map and see *what* is being included. Make sure your linkage editor is only pulling the functions that you are

Make sure you aren't using DEBUG versions of the libraries (in the embedded system) as these are often larger executables.

Make sure the library was built with the right options, memory model, etc. for your needs.

If *only* the things you need are being included and in the correct configuration/implementation, then your program is just too big for the embedded system. Period.

OTOH, if you look *carefully* at the load map, you can see what each function is costing you and decide if that cost is justified in your environment. E.g., using memcpy(3c) and strcpy(3c) to do essentially similar things. (Hint: printf(3c) will eat your lunch... rethink *how* you are using it. itoa et al. might be better choices)

There are no free lunches. If you need X, then you need to have *room* for X!

And while you're doing all the things that everyone else is suggesting, consider if perhaps you're using an itty bitty bit of functionality that's pulling in a huge library.

I.e., if you're using floating point in just one spot, because you don't want to be bothered with recasting to integer math.

Or if you're using printf where some simpler output function would do.

Etc. Ask yourself "is there an easy change I can make that'll render swaths of library code unnecessary?"

Thank you everyone for your suggestions and comments. They were very helpful for me, very!

Since I'm not that experienced in embedded development, I think I will have to first research about this linking and cross-compiling.

cheers

--------------------------------------- Posted through

have

I think I need one more clarification: I have curl and openssl packages specific for my arm architecture. On the contrary, suppose I want to install those packages in my target embedded system so that I don't have to statically link them during cross-compiling.

So, according to my understanding, to install them in the target embedded system I just have to copy the packages to a certain directory, say under "/" (root) directory, in the embedded system. So how can I test my app so that it uses the curl and openssl libraries under the / directory of my embedded system?

--------------------------------------- Posted through

Op Mon, 24 Oct 2011 09:04:09 +0200 schreef manaila :

That implies that your embedded system has a filesystem and a dynamic loader+linker, probably from an operating system that you haven't mentioned yet.

the

embedded

embedded

under

so

Yes, my embedded system has an NFS file system and uses arm-linux OS. I'm not sure about a dynamic loader+linker. So is it correct to just copy those curl and openssl libraries to the / directory of my embedded system, because they are already cross-compiled (I think, as there are some .so, .a, .h files in them) and how do I maket my app "see" them?

--------------------------------------- Posted through

Op Mon, 24 Oct 2011 10:28:26 +0200 schreef manaila :

If your Linux system has a shell (like ksh, bash or busybox), then it has a dynamic loader+linker. The normal place where the system looks for user-provided dynamically linked libraries is /usr/local/lib or /usr/lib, depending on the preferences of your Linux vendor.

Note that this behaviour is not different from that of a regular Linux system, and so they are off-topic in comp.arch.embbedded.

You want to use a 'chroot' environment. There are many howtos around. Basically, when you 'chroot', your base directory is your chrooted directory, and it's _almost_ like nothing else above or beside it exists.

Also, VMs are all the rage with the kids these days. That's a possibility.