[Buildroot] On strip and debugging symbols
Peter Korsgaard
jacmet at uclibc.org
Wed Jun 23 09:36:17 UTC 2010
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni at free-electrons.com> writes:
Hi,
Thomas> On Wed, 23 Jun 2010 09:40:48 +0200
Thomas> Peter Korsgaard <jacmet at uclibc.org> wrote:
>> As mentioned before, the problem with this is that people have
>> historically expected that they can just export
>> PATH=path/to/staging/usr/bin:$PATH and use the cross compiler outside
>> buildroot. If you start installing target binaries into
>> staging/usr/bin then this would break horrible.
>>
>> (Yes, I know people should atleast append it to the path (export
>> PATH=$PATH:path/to/staging/usr/bin), but people will forget and it
>> used to work.
Thomas> As mentionned before, adding $(STAGING_DIR)/usr/bin to the path is just
Thomas> 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.
Thomas> * Install the toolchain outside of $(STAGING_DIR) and then re-use what
Thomas> we do for external toolchains, and then tell people to not add
Thomas> $(STAGING_DIR)/usr/bin to their PATH, but rather the location where
Thomas> the toolchain was installed. This has the added benefit that
Thomas> $(STAGING_DIR) would not contain binaries compiled for the host,
Thomas> mixed with binaries compiled for the target.
That means that people have to start passing -sysroot options, otherwise
the compiler cannot find the header files / libraries.
Thomas> * Keep the toolchain binaries in $(STAGING_DIR), but create shell
Thomas> wrappers installed in another directory for the toolchain binaries,
Thomas> and tell people to add the directory where these wrappers are
Thomas> installed to their PATH.
Would these wrappers then set sysroot? That could perhaps work. I wonder
if the shell overhead would be significant.
--
Bye, Peter Korsgaard
More information about the buildroot
mailing list