[Buildroot] On strip and debugging symbols

[Thomas Petazzoni]

On Wed, 23 Jun 2010 11:36:17 +0200
Peter Korsgaard <jacmet at uclibc.org> wrote:

>  Thomas> As mentionned before, adding $(STAGING_DIR)/usr/bin to the
>  Thomas> path is just wrong. The possible solutions to this are :
> 
> True, but it's happening today, and adding target binaries to staging
> without a very clear notice to people is bound to be a support
> headache.

Even today there are a few target binaries being installed in
$(STAGING_DIR) together with some libraries for which we do
<pkg>_INSTALL_STAGING=YES. But, granted, it's not the general case.

Yes, we'll have to put a clear notice in the documentation and release
notes about this, but it doesn't seem impossible to me. We'll get some
support requests for sure, but they don't seem to be particularly
difficult to handle: as soon as we'll see someone with a failure saying
that "cannot execute binary file", we'll know what the problem is.

>  Thomas>  * Install the toolchain outside of $(STAGING_DIR) and then
>  Thomas> re-use what we do for external toolchains, and then tell
>  Thomas> people to not add $(STAGING_DIR)/usr/bin to their PATH, but
>  Thomas> rather the location where the toolchain was installed. This
>  Thomas> has the added benefit that $(STAGING_DIR) would not contain
>  Thomas> binaries compiled for the host, mixed with binaries compiled
>  Thomas> for the target.
> 
> That means that people have to start passing -sysroot options,
> otherwise the compiler cannot find the header files / libraries.

Yes, if we don't do the wrappers thing.

> Would these wrappers then set sysroot? That could perhaps work. I
> wonder if the shell overhead would be significant.

Yes, these wrappers would set sysroot.

I'm not sure the cost of a shell wrapper is significant compared to the
cost of the compilation process itself (which already does quite a few
forks to run the preprocessor, the compiler, the assembler, etc.).

So, what would be the conclusion of this ?

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com