| Submitter | Denys Dmytriyenko |
|---|---|
| Date | 2010-02-04 01:43:42 |
| Message ID | <1265247822-20734-1-git-send-email-denis@denix.org> |
| Download | mbox | patch |
| Permalink | /patch/1544/ |
| State | Applied, archived |
| Headers | show |
Comments
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
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.
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=.
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. >
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.
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.
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.
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
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
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? :)
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
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...)
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.
Patch
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
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(-)