[Buildroot] sdl demo app install problem

[Buildroot] sdl demo app install problem

[H Hartley Sweeten]

Hello all,

I'm trying to create package for one of the SDL demo apps in order to
verify that sdl is working on my i.MX35 system.  Here is my *.mk for it:


#############################################################
#
# fire
#
#############################################################

FIRE_VERSION:=1.0
FIRE_SOURCE:=fire-$(FIRE_VERSION).tar.gz
FIRE_SITE:=http://www.libsdl.org/projects/fire/src
FIRE_INSTALL_TARGET:=YES
FIRE_CONF_OPT:=--with-sdl-prefix=$(STAGING_DIR)/usr \
		--with-sdl-exec-prefix=$(STAGING_DIR)/usr

FIRE_DEPENDENCIES:=sdl

$(eval $(call AUTOTARGETS,package/customize,fire))


BTW, I hijacked the package/customize directory to use for my non
buildroot packages.  This has been working for other stuff so I don't
think it's the problem.

The package gets all the way thru the build stage but it dies
during the install.  Following is the log of the install stage:


>>> fire 1.0 Installing to target
/usr/bin/make -j2 DESTDIR=/home/bigguiness/extratech/buildroot/output/target  install-strip -C /home/bigguiness/extratech/buildroot/output/build/fire-1.0/
make[1]: Entering directory `/home/bigguiness/extratech/buildroot/output/build/fire-1.0'
/usr/bin/make  AM_INSTALL_PROGRAM_FLAGS=-s install
make[2]: Entering directory `/home/bigguiness/extratech/buildroot/output/build/fire-1.0'
make[3]: Entering directory `/home/bigguiness/extratech/buildroot/output/build/fire-1.0'
/bin/sh ./mkinstalldirs /home/bigguiness/extratech/buildroot/output/target/usr/bin
make[3]: Nothing to be done for `install-data-am'.
  /usr/bin/install -c -s fire /home/bigguiness/extratech/buildroot/output/target/usr/bin/fire
strip: Unable to recognise the format of the input file `/home/bigguiness/extratech/buildroot/output/target/usr/bin/fire'
/usr/bin/install: strip process terminated abnormally
make[3]: *** [install-binPROGRAMS] Error 1
make[3]: Leaving directory `/home/bigguiness/extratech/buildroot/output/build/fire-1.0'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/home/bigguiness/extratech/buildroot/output/build/fire-1.0'
make[1]: *** [install-strip] Error 2
make[1]: Leaving directory `/home/bigguiness/extratech/buildroot/output/build/fire-1.0'
make: *** [/home/bigguiness/extratech/buildroot/output/build/fire-1.0/.stamp_target_installed] Error 2


Does anyone have an idea why the install is failing?

Thanks,
Hartley

[Buildroot] sdl demo app install problem

[Peter Hüwe]

Am Dienstag 22 Juni 2010 01:25:24 schrieb H Hartley Sweeten:
>  /home/bigguiness/extratech/buildroot/output/target/usr/bin/fire strip:
>  Unable to recognise the format of the input file
>  `/home/bigguiness/extratech/buildroot/output/target/usr/bin/fire'
>  /usr/bin/install: strip process terminated abnormally

Hi Hartley,

what's the output of
$ file /home/bigguiness/extratech/buildroot/output/target/usr/bin/fire

strip seems to have a problem with it - maybe its not an executable but a 
shell script - I used to have this problem with a package I created myself 
some while ago.

Peter

[Buildroot] sdl demo app install problem

[H Hartley Sweeten]

On Monday, June 21, 2010 4:33 PM, Peter H?we wrote:
> Am Dienstag 22 Juni 2010 01:25:24 schrieb H Hartley Sweeten:
>>  /home/bigguiness/extratech/buildroot/output/target/usr/bin/fire strip:
>>  Unable to recognise the format of the input file
>>  `/home/bigguiness/extratech/buildroot/output/target/usr/bin/fire'
>>  /usr/bin/install: strip process terminated abnormally
>
> Hi Hartley,
>
> what's the output of
> $ file /home/bigguiness/extratech/buildroot/output/target/usr/bin/fire

$ file /home/bigguiness/extratech/buildroot/output/target/usr/bin/fire
/home/bigguiness/extratech/buildroot/output/target/usr/bin/fire: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped

For a comparison busybox has this output:

$ file /home/bigguiness/extratech/buildroot/output/target/bin/busybox 
/home/bigguiness/extratech/buildroot/output/target/bin/busybox: setuid ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), stripped

> strip seems to have a problem with it - maybe its not an executable but a 
> shell script - I used to have this problem with a package I created myself 
> some while ago.

This is the first time I've seen it.  But, this is with the latest git of
buildroot from this morning so I wasn't sure if it's something new.

Hartley

[Buildroot] sdl demo app install problem

[Peter Hüwe]

> Am Dienstag 22 Juni 2010 01:25:24 schrieb H Hartley Sweeten:
>>  /home/bigguiness/extratech/buildroot/output/target/usr/bin/fire strip:
>>  Unable to recognise the format of the input file
>>  `/home/bigguiness/extratech/buildroot/output/target/usr/bin/fire'
>>  /usr/bin/install: strip process terminated abnormally

I've checked it here and got this result:

$ strip /avr/buildroot-2010.02/output/target/usr/bin/fire                   
strip: Unable to recognise the format of the input file `/avr/buildroot-2010.02/output/target/usr/bin/fire'    

$ ./output/staging/usr/avr32-linux-uclibc/bin/strip /avr/buildroot-2010.02/output/target/usr/bin/fire
$

It seems to use the wrong strip command - not the one from the buildroot toolchain, but rather the host one -- 
so maybe you have to patch one of the files (configure/install) from fire - nevertheless I'll have a look at it too

Peter

[Buildroot] sdl demo app install problem

[H Hartley Sweeten]

On Monday, June 21, 2010 4:47 PM, Peter H?we wrote:
>> Am Dienstag 22 Juni 2010 01:25:24 schrieb H Hartley Sweeten:
>>>  /home/bigguiness/extratech/buildroot/output/target/usr/bin/fire strip:
>>>  Unable to recognise the format of the input file
>>>  `/home/bigguiness/extratech/buildroot/output/target/usr/bin/fire'
>>>  /usr/bin/install: strip process terminated abnormally
>
> I've checked it here and got this result:
>
> $ strip /avr/buildroot-2010.02/output/target/usr/bin/fire                   
> strip: Unable to recognise the format of the input file `/avr/buildroot-2010.02/output/target/usr/bin/fire'    
>
> $ ./output/staging/usr/avr32-linux-uclibc/bin/strip /avr/buildroot-2010.02/output/target/usr/bin/fire
> $
>
> It seems to use the wrong strip command - not the one from the buildroot
> toolchain, but rather the host one -- so maybe you have to patch one of
> the files (configure/install) from fire - nevertheless I'll have a look at it too

I'm actually using an external toolchain but I get the same results as you.  Using the
host 'strip' gives me an error but my toolchain 'strip' works.

The install stage for sdl_image is very different.

>>> sdl_image 1.2.6 Installing to target
/usr/bin/make -j2 DESTDIR=/home/bigguiness/extratech/buildroot/output/target  install-strip -C /home/bigguiness/extratech/buildroot/output/build/sdl_image-1.2.6/
make[1]: Entering directory `/home/bigguiness/extratech/buildroot/output/build/sdl_image-1.2.6'
/usr/bin/make  INSTALL_PROGRAM="/bin/sh /home/bigguiness/extratech/buildroot/output/build/sdl_image-1.2.6/install-sh -c -s" \
	  install_sh_PROGRAM="/bin/sh /home/bigguiness/extratech/buildroot/output/build/sdl_image-1.2.6/install-sh -c -s" INSTALL_STRIP_FLAG=-s \
	  `test -z '/home/bigguiness/extratech/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-strip' || \
	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='/home/bigguiness/extratech/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-strip'"` install
make[2]: Entering directory `/home/bigguiness/extratech/buildroot/output/build/sdl_image-1.2.6'
make[3]: Entering directory `/home/bigguiness/extratech/buildroot/output/build/sdl_image-1.2.6'
test -z "/usr/lib" || mkdir -p -- "/home/bigguiness/extratech/buildroot/output/target/usr/lib"
test -z "/usr/include/SDL" || mkdir -p -- "/home/bigguiness/extratech/buildroot/output/target/usr/include/SDL"
 /bin/sh ./libtool --mode=install /usr/bin/install -c -s 'libSDL_image.la' '/home/bigguiness/extratech/buildroot/output/target/usr/lib/libSDL_image.la'
 /usr/bin/install -c -m 644 'SDL_image.h' '/home/bigguiness/extratech/buildroot/output/target/usr/include/SDL/SDL_image.h'
/usr/bin/install -c .libs/libSDL_image-1.2.so.0.1.5 /home/bigguiness/extratech/buildroot/output/target/usr/lib/libSDL_image-1.2.so.0.1.5
/home/bigguiness/extratech/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-strip --strip-unneeded /home/bigguiness/extratech/buildroot/output/target/usr/lib/libSDL_image-1.2.so.0.1.5
(cd /home/bigguiness/extratech/buildroot/output/target/usr/lib && { ln -s -f libSDL_image-1.2.so.0.1.5 libSDL_image-1.2.so.0 || { rm -f libSDL_image-1.2.so.0 && ln -s libSDL_image-1.2.so.0.1.5 libSDL_image-1.2.so.0; }; })
(cd /home/bigguiness/extratech/buildroot/output/target/usr/lib && { ln -s -f libSDL_image-1.2.so.0.1.5 libSDL_image.so || { rm -f libSDL_image.so && ln -s libSDL_image-1.2.so.0.1.5 libSDL_image.so; }; })
/usr/bin/install -c .libs/libSDL_image.lai /home/bigguiness/extratech/buildroot/output/target/usr/lib/libSDL_image.la
libtool: install: warning: remember to run `libtool --finish /usr/lib'
make[3]: Leaving directory `/home/bigguiness/extratech/buildroot/output/build/sdl_image-1.2.6'
make[2]: Leaving directory `/home/bigguiness/extratech/buildroot/output/build/sdl_image-1.2.6'
make[1]: Leaving directory `/home/bigguiness/extratech/buildroot/output/build/sdl_image-1.2.6'

But the *.mk file is basically the same.

Regards,
Hartley

[Buildroot] sdl demo app install problem

[H Hartley Sweeten]

On Monday, June 21, 2010 4:47 PM, Peter H?we wrote:
>> Am Dienstag 22 Juni 2010 01:25:24 schrieb H Hartley Sweeten:
>>>  /home/bigguiness/extratech/buildroot/output/target/usr/bin/fire strip:
>>>  Unable to recognise the format of the input file
>>>  `/home/bigguiness/extratech/buildroot/output/target/usr/bin/fire'
>>>  /usr/bin/install: strip process terminated abnormally
>
> I've checked it here and got this result:
>
> $ strip /avr/buildroot-2010.02/output/target/usr/bin/fire                   
> strip: Unable to recognise the format of the input file `/avr/buildroot-2010.02/output/target/usr/bin/fire'    
>
> $ ./output/staging/usr/avr32-linux-uclibc/bin/strip /avr/buildroot-2010.02/output/target/usr/bin/fire
> $
>
> It seems to use the wrong strip command - not the one from the buildroot
> toolchain, but rather the host one -- so maybe you have to patch one of
> the files (configure/install) from fire - nevertheless I'll have a look
> at it too

Well, I got it to install.  But, I'm not sure if this was the right way to
do it.  I added the following to the *.mk file:


FIRE_INSTALL_TARGET_OPT:=DESTDIR=$(TARGET_DIR) install


I had to export SDL_NOMOUSE=1 on the board (I can't find a USB mouse and a
hub right at the moment) but the 'fire' app does run on the i.MX35.  Now
on to my actuall app....

Thanks,
Hartley

[Buildroot] sdl demo app install problem

[Peter Hüwe]

Am Dienstag 22 Juni 2010 03:05:38 schrieb H Hartley Sweeten:
> 
> Well, I got it to install.  But, I'm not sure if this was the right way to
> do it.  I added the following to the *.mk file:
> 
> 
> FIRE_INSTALL_TARGET_OPT:=DESTDIR=$(TARGET_DIR) install
>

Great :) - atleast it works - thanks for figuring it out.

I tried to rewrite the whole autoconf stuff meanwhile with (partial) success - 
but your solution seems far more elegant - but unfortunately I can't tell you 
whether this is the "correct" solution.


However I noticed that ncftp suffers from the same issue, but simply ignores 
it - but maybe we should fix it there too - but on the other hand these 
binaries aren't copied to the target fs, and ncftp gets stripped afterwards.

strip: Unable to recognise the format of the input file `../bin/ncftp'                                         
strip: Unable to recognise the format of the input file `../bin/ncftpbatch'  
strip: Unable to recognise the format of the input file `../bin/ncftpls'                                       
strip: Unable to recognise the format of the input file 
`../bin/ncftpbookmarks'                                
make[2]: [../bin/ncftpbookmarks] errors 1 (ignoriert)  


Peter

[Buildroot] sdl demo app install problem

[Thomas Petazzoni]

On Mon, 21 Jun 2010 18:25:24 -0500
H Hartley Sweeten <hartleys@visionengravers.com> wrote:

> strip: Unable to recognise the format of the input file `/home/bigguiness/extratech/buildroot/output/target/usr/bin/fire'

Using the host strip on target binaries cannot work, as you guessed in
this thread.

It's because the Makefile.in shipped by the package doesn't obey to the
$(STRIP) variable. So, you have several options :

 * Use <pkg>_INSTALL_TARGET_OPT as suggested later in the thread to not
   use the install-strip target but the install target instead. This is
   ok, as all binaries are stripped by the main Buildroot Makefile at
   the end of the build process anyway.

 * Add <pkg>_AUTORECONF=YES to your .mk file, which should re-generate
   a Makefile.in that will likely do the right thing with $(STRIP)

Regards,

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

[Buildroot] sdl demo app install problem

[Peter Korsgaard]

>>>>> "H" == H Hartley Sweeten <hartleys@visionengravers.com> writes:

 H> Hello all,
 H> I'm trying to create package for one of the SDL demo apps in order to
 H> verify that sdl is working on my i.MX35 system.  Here is my *.mk for it:


 H> #############################################################
 H> #
 H> # fire
 H> #
 H> #############################################################

 H> FIRE_VERSION:=1.0
 H> FIRE_SOURCE:=fire-$(FIRE_VERSION).tar.gz
 H> FIRE_SITE:=http://www.libsdl.org/projects/fire/src
 H> FIRE_INSTALL_TARGET:=YES
 H> FIRE_CONF_OPT:=--with-sdl-prefix=$(STAGING_DIR)/usr \
 H> 		--with-sdl-exec-prefix=$(STAGING_DIR)/usr

 H> FIRE_DEPENDENCIES:=sdl

 H> $(eval $(call AUTOTARGETS,package/customize,fire))


 H> BTW, I hijacked the package/customize directory to use for my non
 H> buildroot packages.  This has been working for other stuff so I don't
 H> think it's the problem.

 H> The package gets all the way thru the build stage but it dies
 H> during the install.  Following is the log of the install stage:


 >>>> fire 1.0 Installing to target
 H> /usr/bin/make -j2 DESTDIR=/home/bigguiness/extratech/buildroot/output/target  install-strip -C /home/bigguiness/extratech/buildroot/output/build/fire-1.0/
 H> make[1]: Entering directory `/home/bigguiness/extratech/buildroot/output/build/fire-1.0'
 H> /usr/bin/make  AM_INSTALL_PROGRAM_FLAGS=-s install
 H> make[2]: Entering directory `/home/bigguiness/extratech/buildroot/output/build/fire-1.0'
 H> make[3]: Entering directory `/home/bigguiness/extratech/buildroot/output/build/fire-1.0'
 H> /bin/sh ./mkinstalldirs /home/bigguiness/extratech/buildroot/output/target/usr/bin
 H> make[3]: Nothing to be done for `install-data-am'.
 H>   /usr/bin/install -c -s fire /home/bigguiness/extratech/buildroot/output/target/usr/bin/fire
 H> strip: Unable to recognise the format of the input file `/home/bigguiness/extratech/buildroot/output/target/usr/bin/fire'

install -s calls strip, and it most likely end up using your host strip
rather than your cross-strip.

-- 
Bye, Peter Korsgaard

[Buildroot] sdl demo app install problem

[H Hartley Sweeten]

On Tuesday, June 22, 2010 7:42 AM, Peter Korsgaard wrote:
>>>>>> "H" == H Hartley Sweeten <hartleys@visionengravers.com> writes:
>
>H> Hello all,
>H> I'm trying to create package for one of the SDL demo apps in order to
>H> verify that sdl is working on my i.MX35 system.  Here is my *.mk for it:
>
>
>H> #############################################################
>H> #
>H> # fire
>H> #
>H> #############################################################
>
>H> FIRE_VERSION:=1.0
>H> FIRE_SOURCE:=fire-$(FIRE_VERSION).tar.gz
>H> FIRE_SITE:=http://www.libsdl.org/projects/fire/src
>H> FIRE_INSTALL_TARGET:=YES
>H> FIRE_CONF_OPT:=--with-sdl-prefix=$(STAGING_DIR)/usr \
>H> 		--with-sdl-exec-prefix=$(STAGING_DIR)/usr
>
>H> FIRE_DEPENDENCIES:=sdl
>
>H> $(eval $(call AUTOTARGETS,package/customize,fire))
>
>
>H> BTW, I hijacked the package/customize directory to use for my none
>H> buildroot packages.  This has been working for other stuff so I don't
>H> think it's the problem.
>
>H> The package gets all the way thru the build stage but it dies
>H> during the install.  Following is the log of the install stage:
>
>
>>>>> fire 1.0 Installing to target
>H> /usr/bin/make -j2 DESTDIR=/home/bigguiness/extratech/buildroot/output/target  install-strip -C /home/bigguiness/extratech/buildroot/output/build/fire-1.0/
>H> make[1]: Entering directory `/home/bigguiness/extratech/buildroot/output/build/fire-1.0'
>H> /usr/bin/make  AM_INSTALL_PROGRAM_FLAGS=-s install
>H> make[2]: Entering directory `/home/bigguiness/extratech/buildroot/output/build/fire-1.0'
>H> make[3]: Entering directory `/home/bigguiness/extratech/buildroot/output/build/fire-1.0'
>H> /bin/sh ./mkinstalldirs /home/bigguiness/extratech/buildroot/output/target/usr/bin
>H> make[3]: Nothing to be done for `install-data-am'.
>H>   /usr/bin/install -c -s fire /home/bigguiness/extratech/buildroot/output/target/usr/bin/fire
>H> strip: Unable to recognise the format of the input file `/home/bigguiness/extratech/buildroot/output/target/usr/bin/fire'
>
> install -s calls strip, and it most likely end up using your host strip
> rather than your cross-strip.

Hello Peter,

I added this to the *.mk and it worked:

FIRE_INSTALL_TARGET_OPT:=DESTDIR=$(TARGET_DIR) install

Is that the correct way to handle this?

Thanks,
Hartley

[Buildroot] sdl demo app install problem

[Peter Korsgaard]

>>>>> "H" == H Hartley Sweeten <hartleys@visionengravers.com> writes:

Hi,

 H> Hello Peter,

 H> I added this to the *.mk and it worked:

 H> FIRE_INSTALL_TARGET_OPT:=DESTDIR=$(TARGET_DIR) install

 H> Is that the correct way to handle this?

Well, it certainly works around the problem about the buildsystem
calling install -s, but the real issue is that the install program is
hardcoded to run "strip" and not whatever we have set $STRIP or
$STRIP_FOR_TARGET to.

Anyway, this is what coreutils' install does, so we probably don't have
much chance for changing it. I have been pondering always doing make
install instead of install-strip as we always strip at the end anyway.

-- 
Bye, Peter Korsgaard

[Buildroot] On strip and debugging symbols

[Thomas Petazzoni]

On Tue, 22 Jun 2010 22:32:29 +0200
Peter Korsgaard <jacmet@uclibc.org> wrote:

> Anyway, this is what coreutils' install does, so we probably don't
> have much chance for changing it. I have been pondering always doing
> make install instead of install-strip as we always strip at the end
> anyway.

In the notes I have from our Buildroot Developer Day after FOSDEM in
February :

 * Figure out if we can always build the packages in $(STAGING) *with*
   debugging symbols. If so, make it the default. If not, make it an
   option (location to be decided ?)

Therefore, I'd propose to add two options (which would replace the
existing ENABLE_DEBUG knob) :

 * ENABLE_DEBUG_IN_STAGING, which is enabled by default, and has the
   effect of building all packages with '-g', and installing them
   unstripped in $(STAGING_DIR). All *packages* would be installed in
   STAGING, be there libraries or end-user applications, so we could
   get rid of the <pkg>_INSTALL_STAGING and <pkg>_INSTALL_TARGET knobs.
   Having the debugging symbols in $(STAGING_DIR) allows to use remote
   debugging correctly. All packages are installed with
   "DESTDIR=$(STAGING_DIR) install" and "DESTDIR=$(TARGET_DIR)
   install", and only the stripping in $(TARGET_DIR) is done at a
   global level. So we don't try to use install-strip anymore.

 * ENABLE_DEBUG_IN_TARGET, which depends on ENABLE_DEBUG_IN_STAGING,
   and is disabled by default. This would disable the stripping of
   binaries on the target, so as to keep debugging symbols on the
   target, in case someone wants to run/use gdb on the target.

With this, we would have three cases :

 * (ENABLE_DEBUG_IN_STAGING=y, ENABLE_DEBUG_IN_TARGET=n) which is the
   default behaviour. Packages are built with debugging symbols, they
   are kept in $(STAGING_DIR), removed in $(TARGET_DIR). Remote
   debugging is possible. Target debugging is not.

 * (ENABLE_DEBUG_IN_STAGING=n, ENABLE_DEBUG_IN_TARGET=n). In that case
   packages are built without debugging symbols. Binaries are kept
   unstripped in $(STAGING_DIR) and stripped in $(TARGET_DIR). Remote
   and target debugging are not possible.

 * (ENABLE_DEBUG_IN_STAGING=y, ENABLE_DEBUG_IN_TARGET=y). Packages are
   built with debugging symbols, they are kept in $(STAGING_DIR) *and*
   $(TARGET_DIR). Remote *and* target debugging are possible.

Are there other cases not handled here that would be useful ?

Regards,

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

[Buildroot] On strip and debugging symbols

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 Thomas> Therefore, I'd propose to add two options (which would replace the
 Thomas> existing ENABLE_DEBUG knob) :

 Thomas>  * ENABLE_DEBUG_IN_STAGING, which is enabled by default, and has the
 Thomas>    effect of building all packages with '-g', and installing them
 Thomas>    unstripped in $(STAGING_DIR). All *packages* would be installed in
 Thomas>    STAGING, be there libraries or end-user applications, so we could
 Thomas>    get rid of the <pkg>_INSTALL_STAGING and <pkg>_INSTALL_TARGET knobs.
 Thomas>    Having the debugging symbols in $(STAGING_DIR) allows to use remote
 Thomas>    debugging correctly.

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.

-- 
Bye, Peter Korsgaard

[Buildroot] On strip and debugging symbols

[Thomas Petazzoni]

On Wed, 23 Jun 2010 09:40:48 +0200
Peter Korsgaard <jacmet@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.

As mentionned before, adding $(STAGING_DIR)/usr/bin to the path is just
wrong. The possible solutions to this are :

 * Install the toolchain outside of $(STAGING_DIR) and then re-use what
   we do for external toolchains, and then tell people to not add
   $(STAGING_DIR)/usr/bin to their PATH, but rather the location where
   the toolchain was installed. This has the added benefit that
   $(STAGING_DIR) would not contain binaries compiled for the host,
   mixed with binaries compiled for the target.

 * Keep the toolchain binaries in $(STAGING_DIR), but create shell
   wrappers installed in another directory for the toolchain binaries,
   and tell people to add the directory where these wrappers are
   installed to their PATH.

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

[Buildroot] On strip and debugging symbols

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 Thomas> On Wed, 23 Jun 2010 09:40:48 +0200
 Thomas> Peter Korsgaard <jacmet@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

[Buildroot] On strip and debugging symbols

[Thomas Petazzoni]

On Wed, 23 Jun 2010 11:36:17 +0200
Peter Korsgaard <jacmet@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

[Buildroot] On strip and debugging symbols

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

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

 Thomas> Yes, these wrappers would set sysroot.

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

 Thomas> So, what would be the conclusion of this ?

Give the wrappers a try, I would say.

-- 
Bye, Peter Korsgaard

[Buildroot] On strip and debugging symbols

[Thomas Petazzoni]

On Wed, 23 Jun 2010 12:02:24 +0200
Peter Korsgaard <jacmet@uclibc.org> wrote:

>  Thomas> So, what would be the conclusion of this ?
> 
> Give the wrappers a try, I would say.

Toolchain utilities in a separate directory + wrappers, or just
wrappers ?

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

[Buildroot] On strip and debugging symbols

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> On Wed, 23 Jun 2010 12:02:24 +0200
 Thomas> Peter Korsgaard <jacmet@uclibc.org> wrote:

 Thomas> So, what would be the conclusion of this ?
 >> 
 >> Give the wrappers a try, I would say.

 Thomas> Toolchain utilities in a separate directory + wrappers, or just
 Thomas> wrappers ?

Both, then you cannot use it "wrongly", and we get to test the external
toolchain (E.G. -sysroot) stuff more.

-- 
Bye, Peter Korsgaard

[Buildroot] On strip and debugging symbols

[William Wagner]

  On 23/06/2010 09:46, Thomas Petazzoni wrote:
>
> As mentionned before, adding $(STAGING_DIR)/usr/bin to the path is just
> wrong. The possible solutions to this are :
>
>   * Install the toolchain outside of $(STAGING_DIR) and then re-use what
>     we do for external toolchains, and then tell people to not add
>     $(STAGING_DIR)/usr/bin to their PATH, but rather the location where
>     the toolchain was installed. This has the added benefit that
>     $(STAGING_DIR) would not contain binaries compiled for the host,
>     mixed with binaries compiled for the target.
>
>
I think that long term making sure that target and host binaries do not 
end up in the same folder is a good idea. Creating a new folder for host 
tools and putting toolchain in there seems like quite a clear way of 
doing things, but would obviously cause a lot of disruption as people 
learnt the new way of doing things.

Will