> 3. I have to statically link libstdc++ into my application, because > it's not part of the RFS which is flashed into the FoxBoard (mine is > still the "old" MCM, being 4MB flash, 16MB RAM).
Ack. > It's not part of the RFS, simply because if it would be part of the > RFS, the complete image (kernel + RFS) would not fit any more into > that 4MB flash. I see. But please note that probabily libstdc++.so fits (you don't need the static library there). Or it might not fit, I'm just guessing. Actually, if static linking is a matter of space, you'd better staticlink only libstdc++, and not the libc code (which I suspect is available as a shlib on the target anyways). To do that, specify the full pathname of libstdc++.a in your link command without "-static", while letting the linker choose libc by itself (it will pick the shared one). If you work this way, you could copy libstdc++.a in a place of your choice, and strip _that_ copy, leaving the original with full debug info. As an aside, you need debug info there because if it segfaults for example within printf, you can use stack backtracing and you'll know it is actually printf, instead of some unmeaningful hex address. > Well, if I'm stripping my application *after* the linking phase, also > the debug info needed to debug *my* application would be gone, isn't > that so? If yes, than that's not an option for me since I want to be > able to debug my app. Ok. But to do that you usually mount the app via NFS, while the one shipped with the (tiny) target is stripped. So you link static (with full debug info) to track bugs on a big disk, and you link dynamic and strip the copy you ship in the flash. Anyways, it's a matter of personal taste, so I'm not arguing, just suggesting. All the best /alessandro
