[RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script

[RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script

[Denys Dmytriyenko]

Do not hard-code SDK location into all the libtool's .la files and other
libtool, pkg-config and opkg service variables and aliases. Use $SDK_PATH
environment variable instead, which is set once in the main environment-setup
script, allowing easy SDK relocation by adjusting a single variable.

Signed-off-by: Denys Dmytriyenko <denis@denix.org>
---
 recipes/meta/meta-toolchain.bb |   25 ++++++++++++++-----------
 1 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/recipes/meta/meta-toolchain.bb b/recipes/meta/meta-toolchain.bb
index a8c27ec..2855fde 100644
--- a/recipes/meta/meta-toolchain.bb
+++ b/recipes/meta/meta-toolchain.bb
@@ -119,10 +119,10 @@ do_populate_sdk() {
 
 	# Fix or remove broken .la files
 	for i in `find ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS} -name \*.la`; do
-		sed -i 	-e "/^dependency_libs=/s,\([[:space:]']\)${base_libdir},\1${SDKPATH}/${TARGET_SYS}${base_libdir},g" \
-			-e "/^dependency_libs=/s,\([[:space:]']\)${libdir},\1${SDKPATH}/${TARGET_SYS}${libdir},g" \
-			-e "/^dependency_libs=/s,\-\([LR]\)${base_libdir},-\1${SDKPATH}/${TARGET_SYS}${base_libdir},g" \
-			-e "/^dependency_libs=/s,\-\([LR]\)${libdir},-\1${SDKPATH}/${TARGET_SYS}${libdir},g" \
+		sed -i 	-e "/^dependency_libs=/s,\([[:space:]']\)${base_libdir},\1\$SDK_PATH/\$TARGET_SYS${base_libdir},g" \
+			-e "/^dependency_libs=/s,\([[:space:]']\)${libdir},\1\$SDK_PATH/\$TARGET_SYS${libdir},g" \
+			-e "/^dependency_libs=/s,\-\([LR]\)${base_libdir},-\1\$SDK_PATH/\$TARGET_SYS${base_libdir},g" \
+			-e "/^dependency_libs=/s,\-\([LR]\)${libdir},-\1\$SDK_PATH/\$TARGET_SYS${libdir},g" \
 			-e 's/^installed=yes$/installed=no/' $i
 	done
 	rm -f ${SDK_OUTPUT}/${SDKPATH}/lib/*.la
@@ -137,13 +137,16 @@ do_populate_sdk() {
 	# Create environment setup script
 	script=${SDK_OUTPUT}/${SDKPATH}/environment-setup
 	touch $script
-	echo 'export PATH=${SDKPATH}/bin:$PATH' >> $script
-	echo 'export LIBTOOL_SYSROOT_PATH=${prefix}/${TARGET_SYS}' >> $script
-	echo 'export PKG_CONFIG_SYSROOT_DIR=${SDKPATH}/${TARGET_SYS}' >> $script
-	echo 'export PKG_CONFIG_PATH=${SDKPATH}/${TARGET_SYS}${libdir}/pkgconfig' >> $script
-	echo 'export CONFIG_SITE=${SDKPATH}/site-config' >> $script
-	echo "alias opkg='LD_LIBRARY_PATH=${SDKPATH}/lib ${SDKPATH}/bin/opkg-cl -f ${SDKPATH}/${sysconfdir}/opkg-sdk.conf -o ${SDKPATH}'" >> $script
-	echo "alias opkg-target='LD_LIBRARY_PATH=${SDKPATH}/lib ${SDKPATH}/bin/opkg-cl -f ${SDKPATH}/${TARGET_SYS}${sysconfdir}/opkg.conf -o ${SDKPATH}/${TARGET_SYS}'" >> $script
+	echo 'export SDK_PATH=${SDKPATH}' >> $script
+	echo 'export TARGET_SYS=${TARGET_SYS}' >> $script
+	echo 'export PATH=$SDK_PATH/bin:$PATH' >> $script
+	echo 'export CPATH=$SDK_PATH/$TARGET_SYS/usr/include:$CPATH' >> $script
+	echo 'export LIBTOOL_SYSROOT_PATH=$SDK_PATH/$TARGET_SYS' >> $script
+	echo 'export PKG_CONFIG_SYSROOT_DIR=$SDK_PATH/$TARGET_SYS' >> $script
+	echo 'export PKG_CONFIG_PATH=$SDK_PATH/$TARGET_SYS${libdir}/pkgconfig' >> $script
+	echo 'export CONFIG_SITE=$SDK_PATH/site-config' >> $script
+	echo "alias opkg='LD_LIBRARY_PATH=$SDK_PATH/lib $SDK_PATH/bin/opkg-cl -f $SDK_PATH/${sysconfdir}/opkg-sdk.conf -o $SDK_PATH'" >> $script
+	echo "alias opkg-target='LD_LIBRARY_PATH=$SDK_PATH/lib $SDK_PATH/bin/opkg-cl -f $SDK_PATH/$TARGET_SYS${sysconfdir}/opkg.conf -o $SDK_PATH/$TARGET_SYS'" >> $script
 
 	# Add version information
 	versionfile=${SDK_OUTPUT}/${SDKPATH}/version
-- 
1.6.3.3

Re: [RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script

[Chris Conroy]

On Wed, 2010-02-03 at 20:43 -0500, Denys Dmytriyenko wrote:
> Do not hard-code SDK location into all the libtool's .la files and other
> libtool, pkg-config and opkg service variables and aliases. Use $SDK_PATH
> environment variable instead, which is set once in the main environment-setup
> script, allowing easy SDK relocation by adjusting a single variable.
> 
> Signed-off-by: Denys Dmytriyenko <denis@denix.org>
> ---
>  recipes/meta/meta-toolchain.bb |   25 ++++++++++++++-----------
>  1 files changed, 14 insertions(+), 11 deletions(-)
> 
> diff --git a/recipes/meta/meta-toolchain.bb b/recipes/meta/meta-toolchain.bb
> index a8c27ec..2855fde 100644
> --- a/recipes/meta/meta-toolchain.bb
> +++ b/recipes/meta/meta-toolchain.bb
> @@ -119,10 +119,10 @@ do_populate_sdk() {
>  
>  	# Fix or remove broken .la files
>  	for i in `find ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS} -name \*.la`; do
> -		sed -i 	-e "/^dependency_libs=/s,\([[:space:]']\)${base_libdir},\1${SDKPATH}/${TARGET_SYS}${base_libdir},g" \
> -			-e "/^dependency_libs=/s,\([[:space:]']\)${libdir},\1${SDKPATH}/${TARGET_SYS}${libdir},g" \
> -			-e "/^dependency_libs=/s,\-\([LR]\)${base_libdir},-\1${SDKPATH}/${TARGET_SYS}${base_libdir},g" \
> -			-e "/^dependency_libs=/s,\-\([LR]\)${libdir},-\1${SDKPATH}/${TARGET_SYS}${libdir},g" \
> +		sed -i 	-e "/^dependency_libs=/s,\([[:space:]']\)${base_libdir},\1\$SDK_PATH/\$TARGET_SYS${base_libdir},g" \
> +			-e "/^dependency_libs=/s,\([[:space:]']\)${libdir},\1\$SDK_PATH/\$TARGET_SYS${libdir},g" \
> +			-e "/^dependency_libs=/s,\-\([LR]\)${base_libdir},-\1\$SDK_PATH/\$TARGET_SYS${base_libdir},g" \
> +			-e "/^dependency_libs=/s,\-\([LR]\)${libdir},-\1\$SDK_PATH/\$TARGET_SYS${libdir},g" \
>  			-e 's/^installed=yes$/installed=no/' $i
>  	done
>  	rm -f ${SDK_OUTPUT}/${SDKPATH}/lib/*.la
> @@ -137,13 +137,16 @@ do_populate_sdk() {
>  	# Create environment setup script
>  	script=${SDK_OUTPUT}/${SDKPATH}/environment-setup
>  	touch $script
> -	echo 'export PATH=${SDKPATH}/bin:$PATH' >> $script
> -	echo 'export LIBTOOL_SYSROOT_PATH=${prefix}/${TARGET_SYS}' >> $script
> -	echo 'export PKG_CONFIG_SYSROOT_DIR=${SDKPATH}/${TARGET_SYS}' >> $script
> -	echo 'export PKG_CONFIG_PATH=${SDKPATH}/${TARGET_SYS}${libdir}/pkgconfig' >> $script
> -	echo 'export CONFIG_SITE=${SDKPATH}/site-config' >> $script
> -	echo "alias opkg='LD_LIBRARY_PATH=${SDKPATH}/lib ${SDKPATH}/bin/opkg-cl -f ${SDKPATH}/${sysconfdir}/opkg-sdk.conf -o ${SDKPATH}'" >> $script
> -	echo "alias opkg-target='LD_LIBRARY_PATH=${SDKPATH}/lib ${SDKPATH}/bin/opkg-cl -f ${SDKPATH}/${TARGET_SYS}${sysconfdir}/opkg.conf -o ${SDKPATH}/${TARGET_SYS}'" >> $script
> +	echo 'export SDK_PATH=${SDKPATH}' >> $script
> +	echo 'export TARGET_SYS=${TARGET_SYS}' >> $script
> +	echo 'export PATH=$SDK_PATH/bin:$PATH' >> $script
> +	echo 'export CPATH=$SDK_PATH/$TARGET_SYS/usr/include:$CPATH' >> $script
> +	echo 'export LIBTOOL_SYSROOT_PATH=$SDK_PATH/$TARGET_SYS' >> $script
> +	echo 'export PKG_CONFIG_SYSROOT_DIR=$SDK_PATH/$TARGET_SYS' >> $script
> +	echo 'export PKG_CONFIG_PATH=$SDK_PATH/$TARGET_SYS${libdir}/pkgconfig' >> $script
> +	echo 'export CONFIG_SITE=$SDK_PATH/site-config' >> $script
> +	echo "alias opkg='LD_LIBRARY_PATH=$SDK_PATH/lib $SDK_PATH/bin/opkg-cl -f $SDK_PATH/${sysconfdir}/opkg-sdk.conf -o $SDK_PATH'" >> $script
> +	echo "alias opkg-target='LD_LIBRARY_PATH=$SDK_PATH/lib $SDK_PATH/bin/opkg-cl -f $SDK_PATH/$TARGET_SYS${sysconfdir}/opkg.conf -o $SDK_PATH/$TARGET_SYS'" >> $script
>  
>  	# Add version information
>  	versionfile=${SDK_OUTPUT}/${SDKPATH}/version

The fact that both SDK_PATH and SDKPATH exist and apparently mean
different things seems very wrong to me. IMHO one should be removed or
renamed since having them both will be a source of confusion.

It should probably be ${SDK_PATH} instead of $SDK_PATH in your changes.

Does this really make the SDK relocatable? I thought there were still
major issues with relocating GCC.


--Chris

Re: [RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script

[Denys Dmytriyenko]

On Thu, Feb 04, 2010 at 11:57:51AM -0500, Chris Conroy wrote:
> On Wed, 2010-02-03 at 20:43 -0500, Denys Dmytriyenko wrote:
> > Do not hard-code SDK location into all the libtool's .la files and other
> > libtool, pkg-config and opkg service variables and aliases. Use $SDK_PATH
> > environment variable instead, which is set once in the main environment-setup
> > script, allowing easy SDK relocation by adjusting a single variable.
> > 
> > Signed-off-by: Denys Dmytriyenko <denis@denix.org>
> > ---
> >  recipes/meta/meta-toolchain.bb |   25 ++++++++++++++-----------
> >  1 files changed, 14 insertions(+), 11 deletions(-)
> > 
> > diff --git a/recipes/meta/meta-toolchain.bb b/recipes/meta/meta-toolchain.bb
> > index a8c27ec..2855fde 100644
> > --- a/recipes/meta/meta-toolchain.bb
> > +++ b/recipes/meta/meta-toolchain.bb
> > @@ -119,10 +119,10 @@ do_populate_sdk() {
> >  
> >  	# Fix or remove broken .la files
> >  	for i in `find ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS} -name \*.la`; do
> > -		sed -i 	-e "/^dependency_libs=/s,\([[:space:]']\)${base_libdir},\1${SDKPATH}/${TARGET_SYS}${base_libdir},g" \
> > -			-e "/^dependency_libs=/s,\([[:space:]']\)${libdir},\1${SDKPATH}/${TARGET_SYS}${libdir},g" \
> > -			-e "/^dependency_libs=/s,\-\([LR]\)${base_libdir},-\1${SDKPATH}/${TARGET_SYS}${base_libdir},g" \
> > -			-e "/^dependency_libs=/s,\-\([LR]\)${libdir},-\1${SDKPATH}/${TARGET_SYS}${libdir},g" \
> > +		sed -i 	-e "/^dependency_libs=/s,\([[:space:]']\)${base_libdir},\1\$SDK_PATH/\$TARGET_SYS${base_libdir},g" \
> > +			-e "/^dependency_libs=/s,\([[:space:]']\)${libdir},\1\$SDK_PATH/\$TARGET_SYS${libdir},g" \
> > +			-e "/^dependency_libs=/s,\-\([LR]\)${base_libdir},-\1\$SDK_PATH/\$TARGET_SYS${base_libdir},g" \
> > +			-e "/^dependency_libs=/s,\-\([LR]\)${libdir},-\1\$SDK_PATH/\$TARGET_SYS${libdir},g" \
> >  			-e 's/^installed=yes$/installed=no/' $i
> >  	done
> >  	rm -f ${SDK_OUTPUT}/${SDKPATH}/lib/*.la
> > @@ -137,13 +137,16 @@ do_populate_sdk() {
> >  	# Create environment setup script
> >  	script=${SDK_OUTPUT}/${SDKPATH}/environment-setup
> >  	touch $script
> > -	echo 'export PATH=${SDKPATH}/bin:$PATH' >> $script
> > -	echo 'export LIBTOOL_SYSROOT_PATH=${prefix}/${TARGET_SYS}' >> $script
> > -	echo 'export PKG_CONFIG_SYSROOT_DIR=${SDKPATH}/${TARGET_SYS}' >> $script
> > -	echo 'export PKG_CONFIG_PATH=${SDKPATH}/${TARGET_SYS}${libdir}/pkgconfig' >> $script
> > -	echo 'export CONFIG_SITE=${SDKPATH}/site-config' >> $script
> > -	echo "alias opkg='LD_LIBRARY_PATH=${SDKPATH}/lib ${SDKPATH}/bin/opkg-cl -f ${SDKPATH}/${sysconfdir}/opkg-sdk.conf -o ${SDKPATH}'" >> $script
> > -	echo "alias opkg-target='LD_LIBRARY_PATH=${SDKPATH}/lib ${SDKPATH}/bin/opkg-cl -f ${SDKPATH}/${TARGET_SYS}${sysconfdir}/opkg.conf -o ${SDKPATH}/${TARGET_SYS}'" >> $script
> > +	echo 'export SDK_PATH=${SDKPATH}' >> $script
> > +	echo 'export TARGET_SYS=${TARGET_SYS}' >> $script
> > +	echo 'export PATH=$SDK_PATH/bin:$PATH' >> $script
> > +	echo 'export CPATH=$SDK_PATH/$TARGET_SYS/usr/include:$CPATH' >> $script
> > +	echo 'export LIBTOOL_SYSROOT_PATH=$SDK_PATH/$TARGET_SYS' >> $script
> > +	echo 'export PKG_CONFIG_SYSROOT_DIR=$SDK_PATH/$TARGET_SYS' >> $script
> > +	echo 'export PKG_CONFIG_PATH=$SDK_PATH/$TARGET_SYS${libdir}/pkgconfig' >> $script
> > +	echo 'export CONFIG_SITE=$SDK_PATH/site-config' >> $script
> > +	echo "alias opkg='LD_LIBRARY_PATH=$SDK_PATH/lib $SDK_PATH/bin/opkg-cl -f $SDK_PATH/${sysconfdir}/opkg-sdk.conf -o $SDK_PATH'" >> $script
> > +	echo "alias opkg-target='LD_LIBRARY_PATH=$SDK_PATH/lib $SDK_PATH/bin/opkg-cl -f $SDK_PATH/$TARGET_SYS${sysconfdir}/opkg.conf -o $SDK_PATH/$TARGET_SYS'" >> $script
> >  
> >  	# Add version information
> >  	versionfile=${SDK_OUTPUT}/${SDKPATH}/version
> 
> The fact that both SDK_PATH and SDKPATH exist and apparently mean
> different things seems very wrong to me. IMHO one should be removed or

First of all, they are the same. Check conf/bitbake.conf:

SDKPATH = "${SDK_PATH}"

Second, ask RP why he introduced SDKPATH, when we had SDK_PATH for years (my 
guess - that's what is used in Poky, so makes porting changes easier):

7c2bd627 (Richard Purdie  2009-11-12 11:51:18 +0000 342) SDKPATH = "${SDK_PATH}"

> renamed since having them both will be a source of confusion.
> 
> It should probably be ${SDK_PATH} instead of $SDK_PATH in your changes.

You missed the whole point of the patch. It really should be $SDK_PATH

> Does this really make the SDK relocatable? I thought there were still
> major issues with relocating GCC.

GCC built from OE may still have relocation problems - haven't checked lately.
But it doesn't mean that's the only use case scenario... There is also 
external toolchain option, as well as building SDK without the toolchain.
Both of those cases were tested with the above change for several months now.

-- 
Denys

Re: [RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script

[Tom Rini]

On Thu, 2010-02-04 at 12:22 -0500, Denys Dmytriyenko wrote:
> On Thu, Feb 04, 2010 at 11:57:51AM -0500, Chris Conroy wrote:
> > Does this really make the SDK relocatable? I thought there were still
> > major issues with relocating GCC.
> 
> GCC built from OE may still have relocation problems - haven't checked lately.
> But it doesn't mean that's the only use case scenario... There is also 
> external toolchain option, as well as building SDK without the toolchain.
> Both of those cases were tested with the above change for several months now.

The hard part is that in some distributions you will have libmpfr.so &
co if you have a host gcc, and on some you won't.  That in turn makes
gcc relocatable or not.  Everything else is handleable via --sysroot=.

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: [RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script

[Phil Blundell]

On Thu, 2010-02-04 at 11:57 -0600, Tom Rini wrote:
> On Thu, 2010-02-04 at 12:22 -0500, Denys Dmytriyenko wrote:
> > On Thu, Feb 04, 2010 at 11:57:51AM -0500, Chris Conroy wrote:
> > > Does this really make the SDK relocatable? I thought there were still
> > > major issues with relocating GCC.
> > 
> > GCC built from OE may still have relocation problems - haven't checked lately.
> > But it doesn't mean that's the only use case scenario... There is also 
> > external toolchain option, as well as building SDK without the toolchain.
> > Both of those cases were tested with the above change for several months now.
> 
> The hard part is that in some distributions you will have libmpfr.so &
> co if you have a host gcc, and on some you won't.  That in turn makes
> gcc relocatable or not.  Everything else is handleable via --sysroot=.

What exactly is the problem with libmpfr?  I would have thought you
could just ship libmpfr.so.6 inside the sysroot and link gcc against
that local copy (via -rpath $ORIGIN...), without using the system
library at all.

p.

Re: [RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script

[Tom Rini]

On Sat, 2010-02-06 at 13:04 +0000, Phil Blundell wrote:
> On Thu, 2010-02-04 at 11:57 -0600, Tom Rini wrote:
> > On Thu, 2010-02-04 at 12:22 -0500, Denys Dmytriyenko wrote:
> > > On Thu, Feb 04, 2010 at 11:57:51AM -0500, Chris Conroy wrote:
> > > > Does this really make the SDK relocatable? I thought there were still
> > > > major issues with relocating GCC.
> > > 
> > > GCC built from OE may still have relocation problems - haven't checked lately.
> > > But it doesn't mean that's the only use case scenario... There is also 
> > > external toolchain option, as well as building SDK without the toolchain.
> > > Both of those cases were tested with the above change for several months now.
> > 
> > The hard part is that in some distributions you will have libmpfr.so &
> > co if you have a host gcc, and on some you won't.  That in turn makes
> > gcc relocatable or not.  Everything else is handleable via --sysroot=.
> 
> What exactly is the problem with libmpfr?  I would have thought you
> could just ship libmpfr.so.6 inside the sysroot and link gcc against
> that local copy (via -rpath $ORIGIN...), without using the system
> library at all.

I hesitate to say this, since I haven't fully poked the other side of
the equation, but..  With $ORIGIN, you need I think 3 levels of
checking-back since cc1 (& others) need libmpfr.  That, mixed with just
how ugly the $ORIGIN stuff gets for gcc, is the problem.  Why you don't
always see the problem is that Ubuntu uses libmpfr.so for its gcc,
RHEL4Usomething (half I haven't checked into personally and so hesitate)
seems to not.

For gcc-cross-sdk, this isn't so much of an issue.  For gcc-cross and
$ORIGIN it gets ugly, but solvable.

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: [RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script

[Khem Raj]

On (08/02/10 12:00), Tom Rini wrote:
> On Sat, 2010-02-06 at 13:04 +0000, Phil Blundell wrote:
> > On Thu, 2010-02-04 at 11:57 -0600, Tom Rini wrote:
> > > On Thu, 2010-02-04 at 12:22 -0500, Denys Dmytriyenko wrote:
> > > > On Thu, Feb 04, 2010 at 11:57:51AM -0500, Chris Conroy wrote:
> > > > > Does this really make the SDK relocatable? I thought there were still
> > > > > major issues with relocating GCC.
> > > > 
> > > > GCC built from OE may still have relocation problems - haven't checked lately.
> > > > But it doesn't mean that's the only use case scenario... There is also 
> > > > external toolchain option, as well as building SDK without the toolchain.
> > > > Both of those cases were tested with the above change for several months now.
> > > 
> > > The hard part is that in some distributions you will have libmpfr.so &
> > > co if you have a host gcc, and on some you won't.  That in turn makes
> > > gcc relocatable or not.  Everything else is handleable via --sysroot=.
> > 
> > What exactly is the problem with libmpfr?  I would have thought you
> > could just ship libmpfr.so.6 inside the sysroot and link gcc against
> > that local copy (via -rpath $ORIGIN...), without using the system
> > library at all.
> 
> I hesitate to say this, since I haven't fully poked the other side of
> the equation, but..  With $ORIGIN, you need I think 3 levels of
> checking-back since cc1 (& others) need libmpfr.  That, mixed with just
> how ugly the $ORIGIN stuff gets for gcc, is the problem.  Why you don't
> always see the problem is that Ubuntu uses libmpfr.so for its gcc,
> RHEL4Usomething (half I haven't checked into personally and so hesitate)
> seems to not.
> 
> For gcc-cross-sdk, this isn't so much of an issue.  For gcc-cross and
> $ORIGIN it gets ugly, but solvable.

I think the prerequisites of gcc libmpfr, libgmp and libmpc from 4.5
onwards are probably not used by 
any other tools we stage for host so it would be safer to build them inside
gcc tree and link in statically and only create runtime deps on the
libraries that always exist like libc. This will have better chance of
relocation. We just need to untar these libraries in top of gcc src tree
and it will use cofigure and use it. But this only solves gcc issue 
for other host/cross packages which depend upon libs from staging we still
need a solution. 

-Khem


> 
> -- 
> Tom Rini <tom_rini@mentor.com>
> Mentor Graphics Corporation
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script

[Tom Rini]

On Tue, 2010-02-09 at 12:08 -0800, Khem Raj wrote:
> On (08/02/10 12:00), Tom Rini wrote:
> > On Sat, 2010-02-06 at 13:04 +0000, Phil Blundell wrote:
> > > On Thu, 2010-02-04 at 11:57 -0600, Tom Rini wrote:
> > > > On Thu, 2010-02-04 at 12:22 -0500, Denys Dmytriyenko wrote:
> > > > > On Thu, Feb 04, 2010 at 11:57:51AM -0500, Chris Conroy wrote:
> > > > > > Does this really make the SDK relocatable? I thought there were still
> > > > > > major issues with relocating GCC.
> > > > > 
> > > > > GCC built from OE may still have relocation problems - haven't checked lately.
> > > > > But it doesn't mean that's the only use case scenario... There is also 
> > > > > external toolchain option, as well as building SDK without the toolchain.
> > > > > Both of those cases were tested with the above change for several months now.
> > > > 
> > > > The hard part is that in some distributions you will have libmpfr.so &
> > > > co if you have a host gcc, and on some you won't.  That in turn makes
> > > > gcc relocatable or not.  Everything else is handleable via --sysroot=.
> > > 
> > > What exactly is the problem with libmpfr?  I would have thought you
> > > could just ship libmpfr.so.6 inside the sysroot and link gcc against
> > > that local copy (via -rpath $ORIGIN...), without using the system
> > > library at all.
> > 
> > I hesitate to say this, since I haven't fully poked the other side of
> > the equation, but..  With $ORIGIN, you need I think 3 levels of
> > checking-back since cc1 (& others) need libmpfr.  That, mixed with just
> > how ugly the $ORIGIN stuff gets for gcc, is the problem.  Why you don't
> > always see the problem is that Ubuntu uses libmpfr.so for its gcc,
> > RHEL4Usomething (half I haven't checked into personally and so hesitate)
> > seems to not.
> > 
> > For gcc-cross-sdk, this isn't so much of an issue.  For gcc-cross and
> > $ORIGIN it gets ugly, but solvable.
> 
> I think the prerequisites of gcc libmpfr, libgmp and libmpc from 4.5
> onwards are probably not used by 
> any other tools we stage for host so it would be safer to build them inside
> gcc tree and link in statically and only create runtime deps on the
> libraries that always exist like libc. This will have better chance of
> relocation. We just need to untar these libraries in top of gcc src tree
> and it will use cofigure and use it. But this only solves gcc issue 
> for other host/cross packages which depend upon libs from staging we still
> need a solution. 

I was thinking that too.  Phil, can you try on your toolchain branch to
do this? :)

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: [RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script

[Richard Purdie]

On Tue, 2010-02-09 at 14:36 -0700, Tom Rini wrote:
> On Tue, 2010-02-09 at 12:08 -0800, Khem Raj wrote:
> > On (08/02/10 12:00), Tom Rini wrote:
> > I think the prerequisites of gcc libmpfr, libgmp and libmpc from 4.5
> > onwards are probably not used by 
> > any other tools we stage for host so it would be safer to build them inside
> > gcc tree and link in statically and only create runtime deps on the
> > libraries that always exist like libc. This will have better chance of
> > relocation. We just need to untar these libraries in top of gcc src tree
> > and it will use cofigure and use it. But this only solves gcc issue 
> > for other host/cross packages which depend upon libs from staging we still
> > need a solution. 
> 
> I was thinking that too.  Phil, can you try on your toolchain branch to
> do this? :)

Another generic solution I'm wondering about is postprocessing the
cross/native binaries with chrpath. This has the benefits of no horrible
shell quoting and its generic.

I might even be tempted to try this soon...

Cheers,

Richard

Re: [RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script

[Tom Rini]

On Wed, 2010-02-10 at 15:50 +0000, Richard Purdie wrote:
> On Tue, 2010-02-09 at 14:36 -0700, Tom Rini wrote:
> > On Tue, 2010-02-09 at 12:08 -0800, Khem Raj wrote:
> > > On (08/02/10 12:00), Tom Rini wrote:
> > > I think the prerequisites of gcc libmpfr, libgmp and libmpc from 4.5
> > > onwards are probably not used by 
> > > any other tools we stage for host so it would be safer to build them inside
> > > gcc tree and link in statically and only create runtime deps on the
> > > libraries that always exist like libc. This will have better chance of
> > > relocation. We just need to untar these libraries in top of gcc src tree
> > > and it will use cofigure and use it. But this only solves gcc issue 
> > > for other host/cross packages which depend upon libs from staging we still
> > > need a solution. 
> > 
> > I was thinking that too.  Phil, can you try on your toolchain branch to
> > do this? :)
> 
> Another generic solution I'm wondering about is postprocessing the
> cross/native binaries with chrpath. This has the benefits of no horrible
> shell quoting and its generic.

This might be nice for relocating packaged staging, more-so than SDK
(depending on what you need / want your SDK to be able to do without
OE...)

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: [RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script

[Phil Blundell]

On Wed, 2010-02-10 at 15:50 +0000, Richard Purdie wrote:
> On Tue, 2010-02-09 at 14:36 -0700, Tom Rini wrote:
> > On Tue, 2010-02-09 at 12:08 -0800, Khem Raj wrote:
> > > On (08/02/10 12:00), Tom Rini wrote:
> > > I think the prerequisites of gcc libmpfr, libgmp and libmpc from 4.5
> > > onwards are probably not used by 
> > > any other tools we stage for host so it would be safer to build them inside
> > > gcc tree and link in statically and only create runtime deps on the
> > > libraries that always exist like libc. This will have better chance of
> > > relocation. We just need to untar these libraries in top of gcc src tree
> > > and it will use cofigure and use it. But this only solves gcc issue 
> > > for other host/cross packages which depend upon libs from staging we still
> > > need a solution. 
> > 
> > I was thinking that too.  Phil, can you try on your toolchain branch to
> > do this? :)
> 
> Another generic solution I'm wondering about is postprocessing the
> cross/native binaries with chrpath. This has the benefits of no horrible
> shell quoting and its generic.

Yeah, either that or wrapping the binaries in something (either a binayr
or just a shell script) which invokes the dynamic linker with an
appropriate library path.  That would also handle your situation where
you have a custom ld.so as well.

p.

Re: [RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script

[Chris Conroy]

On Thu, 2010-02-04 at 12:22 -0500, Denys Dmytriyenko wrote:
> First of all, they are the same. Check conf/bitbake.conf:
> 
> SDKPATH = "${SDK_PATH}"
> 
> Second, ask RP why he introduced SDKPATH, when we had SDK_PATH for years (my 
> guess - that's what is used in Poky, so makes porting changes easier):
Fair enough, but saying 'ask RP' doesn't justify away the fact that
having these two variables is confusing. If they really are the same,
then one should be removed. If one shouldn't be removed, then there is
some difference that should probably be documented. It's just a matter
of consistency/readability.

> 7c2bd627 (Richard Purdie  2009-11-12 11:51:18 +0000 342) SDKPATH = "${SDK_PATH}"
> 
> > renamed since having them both will be a source of confusion.
> > 
> > It should probably be ${SDK_PATH} instead of $SDK_PATH in your changes.
> 
> You missed the whole point of the patch. It really should be $SDK_PATH
My bad there. I got hung up on the SDK_PATH/SDKPATH thing.

> 
> > Does this really make the SDK relocatable? I thought there were still
> > major issues with relocating GCC.
> 
> GCC built from OE may still have relocation problems - haven't checked lately.
> But it doesn't mean that's the only use case scenario... There is also 
> external toolchain option, as well as building SDK without the toolchain.
> Both of those cases were tested with the above change for several months now.
> 

Re: [RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script

[Denys Dmytriyenko]

On Thu, Feb 04, 2010 at 01:42:50PM -0500, Chris Conroy wrote:
> On Thu, 2010-02-04 at 12:22 -0500, Denys Dmytriyenko wrote:
> > First of all, they are the same. Check conf/bitbake.conf:
> > 
> > SDKPATH = "${SDK_PATH}"
> > 
> > Second, ask RP why he introduced SDKPATH, when we had SDK_PATH for years (my 
> > guess - that's what is used in Poky, so makes porting changes easier):
> Fair enough, but saying 'ask RP' doesn't justify away the fact that
> having these two variables is confusing. If they really are the same,
> then one should be removed. If one shouldn't be removed, then there is
> some difference that should probably be documented. It's just a matter
> of consistency/readability.

All I was trying to say is that, while it's a valid question, it is out of 
scope of this patch. I don't want to mix 2 things in one patch (if we decide 
to remove one of SDKPATH/SDK_PATH). And it would still be good to hear RP's 
rationale.

-- 
Denys

Re: [RFC][PATCH] meta-toolchain: make SDK relocatable by using $SDK_PATH var in env setup script

[Richard Purdie]

On Thu, 2010-02-04 at 14:07 -0500, Denys Dmytriyenko wrote:
> On Thu, Feb 04, 2010 at 01:42:50PM -0500, Chris Conroy wrote:
> > On Thu, 2010-02-04 at 12:22 -0500, Denys Dmytriyenko wrote:
> > > First of all, they are the same. Check conf/bitbake.conf:
> > > 
> > > SDKPATH = "${SDK_PATH}"
> > > 
> > > Second, ask RP why he introduced SDKPATH, when we had SDK_PATH for years (my 
> > > guess - that's what is used in Poky, so makes porting changes easier):
> > Fair enough, but saying 'ask RP' doesn't justify away the fact that
> > having these two variables is confusing. If they really are the same,
> > then one should be removed. If one shouldn't be removed, then there is
> > some difference that should probably be documented. It's just a matter
> > of consistency/readability.
> 
> All I was trying to say is that, while it's a valid question, it is out of 
> scope of this patch. I don't want to mix 2 things in one patch (if we decide 
> to remove one of SDKPATH/SDK_PATH). And it would still be good to hear RP's 
> rationale.

As best I remember, historically, there was SDK_PREFIX. When we created
the SDK_ variables, this conflicted with things like TARGET_PREFIX,
HOST_PREFIX and BUILD_PREFIX so it had to be renamed. OE went with
SDK_PATH, Poky went with SDKPATH. When I merged a load of toolchain
stuff between the two, I think I realised halfway through a merge there
was a problem and inserted that variable to make sure everything worked.
I'm sure I intended to clean it up at some point but never got around to
it.

In summary, one needs to go. 

I have a preference for not having an underscore in the name as SDKPATH
does something different to the other SDK_*, TARGET_*, HOST_* and
BUILD_* variables and does not have a counterpart.

Cheers,

Richard