All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS
@ 2010-04-21 12:21 Koen Kooi
  2010-04-23 11:07 ` Koen Kooi
  0 siblings, 1 reply; 14+ messages in thread
From: Koen Kooi @ 2010-04-21 12:21 UTC (permalink / raw)
  To: openembedded-devel; +Cc: Koen Kooi

From: Koen Kooi <koen@openembedded.org>

This is the first step to be able to mix multiple arm archs (and ABIs) when installing multiple SDKs on one buildhost (e.g. armv4 and armv7a).

---
 recipes/meta/meta-toolchain.bb |   50 ++++++++++++++++++++--------------------
 1 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/recipes/meta/meta-toolchain.bb b/recipes/meta/meta-toolchain.bb
index adc057a..2e2196a 100644
--- a/recipes/meta/meta-toolchain.bb
+++ b/recipes/meta/meta-toolchain.bb
@@ -10,7 +10,7 @@ SDK_OUTPUT2 = "${SDK_DIR}/image-extras"
 SDK_DEPLOY = "${DEPLOY_DIR}/sdk"
 
 IPKG_HOST = "opkg-cl -f ${IPKGCONF_SDK} -o ${SDK_OUTPUT}"
-IPKG_TARGET = "opkg-cl -f ${IPKGCONF_TARGET} -o ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}"
+IPKG_TARGET = "opkg-cl -f ${IPKGCONF_TARGET} -o ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}"
 
 TOOLCHAIN_HOST_TASK ?= "task-sdk-host"
 TOOLCHAIN_TARGET_TASK ?= "task-sdk-bare"
@@ -26,14 +26,14 @@ RDEPENDS = "${DISTRO_FEED_CONFIGS} ${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TAS
 TOOLCHAIN_FEED_URI ?= "${DISTRO_FEED_URI}"
 
 modify_opkg_conf () {
-        OUTPUT_OPKGCONF_TARGET="${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}/opkg.conf"
-        OUTPUT_OPKGCONF_HOST="${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}/opkg-sdk.conf"
+        OUTPUT_OPKGCONF_TARGET="${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}/opkg.conf"
+        OUTPUT_OPKGCONF_HOST="${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}/opkg-sdk.conf"
         OUTPUT_OPKGCONF_SDK="${SDK_OUTPUT}/${sysconfdir}/opkg-sdk.conf"
         rm -f ${OUTPUT_OPKGCONF_TARGET}
         rm -f ${OUTPUT_OPKGCONF_HOST}
         rm -f ${OUTPUT_OPKGCONF_SDK}
 
-        if [ -e ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}/opkg/arch.conf ] ; then
+        if [ -e ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}/opkg/arch.conf ] ; then
             echo "Creating empty opkg.conf since arch.conf is already present"
             echo > ${OUTPUT_OPKGCONF_TARGET} 
         else
@@ -53,7 +53,7 @@ do_populate_sdk() {
 	rm -rf ${SDK_OUTPUT}
 	mkdir -p ${SDK_OUTPUT}
 	mkdir -p ${SDK_OUTPUT}${libdir}/opkg/
-	mkdir -p ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}${libdir}/opkg/
+	mkdir -p ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}${libdir}/opkg/
 
 	package_generate_ipkg_conf
 
@@ -79,17 +79,17 @@ do_populate_sdk() {
 	# Clean up empty directories from excluded packages
 	find ${SDK_OUTPUT} -depth -type d -empty -print0 | xargs -r0 /bin/rmdir
 
-	install -d ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}
-	install -m 0644 ${IPKGCONF_TARGET} ${IPKGCONF_SDK} ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}/
+	install -d ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}
+	install -m 0644 ${IPKGCONF_TARGET} ${IPKGCONF_SDK} ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}/
 
 	install -d ${SDK_OUTPUT}/${SDKPATH}/${sysconfdir}
 	install -m 0644 ${IPKGCONF_SDK} ${SDK_OUTPUT}/${SDKPATH}/${sysconfdir}/
 
 	# extract and store ipks, pkgdata and shlibs data
-	target_pkgs=`cat ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/usr/lib/opkg/status | grep Package: | cut -f 2 -d ' '`
+	target_pkgs=`cat ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/usr/lib/opkg/status | grep Package: | cut -f 2 -d ' '`
 	mkdir -p ${SDK_OUTPUT2}/${SDKPATH}/ipk/
 	mkdir -p ${SDK_OUTPUT2}/${SDKPATH}/pkgdata/runtime/
-	mkdir -p ${SDK_OUTPUT2}/${SDKPATH}/${TARGET_SYS}/shlibs/
+	mkdir -p ${SDK_OUTPUT2}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/shlibs/
 	for pkg in $target_pkgs ; do
 		for arch in $revipkgarchs; do
 			pkgnames=${DEPLOY_DIR_IPK}/$arch/${pkg}_*_$arch.ipk
@@ -107,7 +107,7 @@ do_populate_sdk() {
 						cp ${TMPDIR}/pkgdata/$pkg_subdir/runtime/$subpkg.packaged ${SDK_OUTPUT2}/${SDKPATH}/pkgdata/$pkg_subdir/runtime/
 					fi
 					if [ -e ${STAGING_DIR_TARGET}/shlibs/$subpkg.list ]; then
-						cp ${STAGING_DIR_TARGET}/shlibs/$subpkg.* ${SDK_OUTPUT2}/${SDKPATH}/${TARGET_SYS}/shlibs/
+						cp ${STAGING_DIR_TARGET}/shlibs/$subpkg.* ${SDK_OUTPUT2}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/shlibs/
 					fi
 				done
 				break
@@ -119,20 +119,20 @@ do_populate_sdk() {
 	# libgcc-dev should be responsible for that, but it's not getting built
 	# RP: it gets smashed up depending on the order that gcc, gcc-cross and 
 	# gcc-cross-sdk get built :( (30/11/07)
-	ln -sf libgcc_s.so.1 ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/lib/libgcc_s.so
+	ln -sf libgcc_s.so.1 ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/lib/libgcc_s.so
 
 	# With sysroot support, gcc expects the default C++ headers to be
 	# in a specific place.
-	install -d ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/include
-	mv ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/usr/include/c++ \
-		${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/include/
+	install -d ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/include
+	mv ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/usr/include/c++ \
+		${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/include/
 
 	# 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\$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" \
+	for i in `find ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS} -name \*.la`; do
+		sed -i 	-e "/^dependency_libs=/s,\([[:space:]']\)${base_libdir},\1\$SDK_PATH/\$MULTIMACH_TARGET_SYS${base_libdir},g" \
+			-e "/^dependency_libs=/s,\([[:space:]']\)${libdir},\1\$SDK_PATH/\$MULTIMACH_TARGET_SYS${libdir},g" \
+			-e "/^dependency_libs=/s,\-\([LR]\)${base_libdir},-\1\$SDK_PATH/\$MULTIMACH_TARGET_SYS${base_libdir},g" \
+			-e "/^dependency_libs=/s,\-\([LR]\)${libdir},-\1\$SDK_PATH/\$MULTIMACH_TARGET_SYS${libdir},g" \
 			-e 's/^installed=yes$/installed=no/' $i
 	done
 	rm -f ${SDK_OUTPUT}/${SDKPATH}/lib/*.la
@@ -148,15 +148,15 @@ do_populate_sdk() {
 	script=${SDK_OUTPUT}/${SDKPATH}/environment-setup
 	touch $script
 	echo 'export SDK_PATH=${SDKPATH}' >> $script
-	echo 'export TARGET_SYS=${TARGET_SYS}' >> $script
+	echo 'export MULTIMACH_TARGET_SYS=${MULTIMACH_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 CPATH=$SDK_PATH/$MULTIMACH_TARGET_SYS/usr/include:$CPATH' >> $script
+	echo 'export LIBTOOL_SYSROOT_PATH=$SDK_PATH/$MULTIMACH_TARGET_SYS' >> $script
+	echo 'export PKG_CONFIG_SYSROOT_DIR=$SDK_PATH/$MULTIMACH_TARGET_SYS' >> $script
+	echo 'export PKG_CONFIG_PATH=$SDK_PATH/$MULTIMACH_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
+	echo 'alias opkg-target="LD_LIBRARY_PATH=$SDK_PATH/lib $SDK_PATH/bin/opkg-cl -f $SDK_PATH/$MULTIMACH_TARGET_SYS${sysconfdir}/opkg.conf -o $SDK_PATH/$MULTIMACH_TARGET_SYS"' >> $script
 
 	# Add version information
 	versionfile=${SDK_OUTPUT}/${SDKPATH}/version
-- 
1.6.6.1




^ permalink raw reply related	[flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS
  2010-04-21 12:21 [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS Koen Kooi
@ 2010-04-23 11:07 ` Koen Kooi
  2010-04-23 18:07   ` Tom Rini
  0 siblings, 1 reply; 14+ messages in thread
From: Koen Kooi @ 2010-04-23 11:07 UTC (permalink / raw)
  To: openembedded-devel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ping

On 21-04-10 14:21, Koen Kooi wrote:
> From: Koen Kooi <koen@openembedded.org>
> 
> This is the first step to be able to mix multiple arm archs (and ABIs) when installing multiple SDKs on one buildhost (e.g. armv4 and armv7a).
> 
> ---
>  recipes/meta/meta-toolchain.bb |   50 ++++++++++++++++++++--------------------
>  1 files changed, 25 insertions(+), 25 deletions(-)
> 
> diff --git a/recipes/meta/meta-toolchain.bb b/recipes/meta/meta-toolchain.bb
> index adc057a..2e2196a 100644
> --- a/recipes/meta/meta-toolchain.bb
> +++ b/recipes/meta/meta-toolchain.bb
> @@ -10,7 +10,7 @@ SDK_OUTPUT2 = "${SDK_DIR}/image-extras"
>  SDK_DEPLOY = "${DEPLOY_DIR}/sdk"
>  
>  IPKG_HOST = "opkg-cl -f ${IPKGCONF_SDK} -o ${SDK_OUTPUT}"
> -IPKG_TARGET = "opkg-cl -f ${IPKGCONF_TARGET} -o ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}"
> +IPKG_TARGET = "opkg-cl -f ${IPKGCONF_TARGET} -o ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}"
>  
>  TOOLCHAIN_HOST_TASK ?= "task-sdk-host"
>  TOOLCHAIN_TARGET_TASK ?= "task-sdk-bare"
> @@ -26,14 +26,14 @@ RDEPENDS = "${DISTRO_FEED_CONFIGS} ${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TAS
>  TOOLCHAIN_FEED_URI ?= "${DISTRO_FEED_URI}"
>  
>  modify_opkg_conf () {
> -        OUTPUT_OPKGCONF_TARGET="${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}/opkg.conf"
> -        OUTPUT_OPKGCONF_HOST="${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}/opkg-sdk.conf"
> +        OUTPUT_OPKGCONF_TARGET="${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}/opkg.conf"
> +        OUTPUT_OPKGCONF_HOST="${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}/opkg-sdk.conf"
>          OUTPUT_OPKGCONF_SDK="${SDK_OUTPUT}/${sysconfdir}/opkg-sdk.conf"
>          rm -f ${OUTPUT_OPKGCONF_TARGET}
>          rm -f ${OUTPUT_OPKGCONF_HOST}
>          rm -f ${OUTPUT_OPKGCONF_SDK}
>  
> -        if [ -e ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}/opkg/arch.conf ] ; then
> +        if [ -e ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}/opkg/arch.conf ] ; then
>              echo "Creating empty opkg.conf since arch.conf is already present"
>              echo > ${OUTPUT_OPKGCONF_TARGET} 
>          else
> @@ -53,7 +53,7 @@ do_populate_sdk() {
>  	rm -rf ${SDK_OUTPUT}
>  	mkdir -p ${SDK_OUTPUT}
>  	mkdir -p ${SDK_OUTPUT}${libdir}/opkg/
> -	mkdir -p ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}${libdir}/opkg/
> +	mkdir -p ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}${libdir}/opkg/
>  
>  	package_generate_ipkg_conf
>  
> @@ -79,17 +79,17 @@ do_populate_sdk() {
>  	# Clean up empty directories from excluded packages
>  	find ${SDK_OUTPUT} -depth -type d -empty -print0 | xargs -r0 /bin/rmdir
>  
> -	install -d ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}
> -	install -m 0644 ${IPKGCONF_TARGET} ${IPKGCONF_SDK} ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}/
> +	install -d ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}
> +	install -m 0644 ${IPKGCONF_TARGET} ${IPKGCONF_SDK} ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}/
>  
>  	install -d ${SDK_OUTPUT}/${SDKPATH}/${sysconfdir}
>  	install -m 0644 ${IPKGCONF_SDK} ${SDK_OUTPUT}/${SDKPATH}/${sysconfdir}/
>  
>  	# extract and store ipks, pkgdata and shlibs data
> -	target_pkgs=`cat ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/usr/lib/opkg/status | grep Package: | cut -f 2 -d ' '`
> +	target_pkgs=`cat ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/usr/lib/opkg/status | grep Package: | cut -f 2 -d ' '`
>  	mkdir -p ${SDK_OUTPUT2}/${SDKPATH}/ipk/
>  	mkdir -p ${SDK_OUTPUT2}/${SDKPATH}/pkgdata/runtime/
> -	mkdir -p ${SDK_OUTPUT2}/${SDKPATH}/${TARGET_SYS}/shlibs/
> +	mkdir -p ${SDK_OUTPUT2}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/shlibs/
>  	for pkg in $target_pkgs ; do
>  		for arch in $revipkgarchs; do
>  			pkgnames=${DEPLOY_DIR_IPK}/$arch/${pkg}_*_$arch.ipk
> @@ -107,7 +107,7 @@ do_populate_sdk() {
>  						cp ${TMPDIR}/pkgdata/$pkg_subdir/runtime/$subpkg.packaged ${SDK_OUTPUT2}/${SDKPATH}/pkgdata/$pkg_subdir/runtime/
>  					fi
>  					if [ -e ${STAGING_DIR_TARGET}/shlibs/$subpkg.list ]; then
> -						cp ${STAGING_DIR_TARGET}/shlibs/$subpkg.* ${SDK_OUTPUT2}/${SDKPATH}/${TARGET_SYS}/shlibs/
> +						cp ${STAGING_DIR_TARGET}/shlibs/$subpkg.* ${SDK_OUTPUT2}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/shlibs/
>  					fi
>  				done
>  				break
> @@ -119,20 +119,20 @@ do_populate_sdk() {
>  	# libgcc-dev should be responsible for that, but it's not getting built
>  	# RP: it gets smashed up depending on the order that gcc, gcc-cross and 
>  	# gcc-cross-sdk get built :( (30/11/07)
> -	ln -sf libgcc_s.so.1 ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/lib/libgcc_s.so
> +	ln -sf libgcc_s.so.1 ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/lib/libgcc_s.so
>  
>  	# With sysroot support, gcc expects the default C++ headers to be
>  	# in a specific place.
> -	install -d ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/include
> -	mv ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/usr/include/c++ \
> -		${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/include/
> +	install -d ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/include
> +	mv ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/usr/include/c++ \
> +		${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/include/
>  
>  	# 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\$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" \
> +	for i in `find ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS} -name \*.la`; do
> +		sed -i 	-e "/^dependency_libs=/s,\([[:space:]']\)${base_libdir},\1\$SDK_PATH/\$MULTIMACH_TARGET_SYS${base_libdir},g" \
> +			-e "/^dependency_libs=/s,\([[:space:]']\)${libdir},\1\$SDK_PATH/\$MULTIMACH_TARGET_SYS${libdir},g" \
> +			-e "/^dependency_libs=/s,\-\([LR]\)${base_libdir},-\1\$SDK_PATH/\$MULTIMACH_TARGET_SYS${base_libdir},g" \
> +			-e "/^dependency_libs=/s,\-\([LR]\)${libdir},-\1\$SDK_PATH/\$MULTIMACH_TARGET_SYS${libdir},g" \
>  			-e 's/^installed=yes$/installed=no/' $i
>  	done
>  	rm -f ${SDK_OUTPUT}/${SDKPATH}/lib/*.la
> @@ -148,15 +148,15 @@ do_populate_sdk() {
>  	script=${SDK_OUTPUT}/${SDKPATH}/environment-setup
>  	touch $script
>  	echo 'export SDK_PATH=${SDKPATH}' >> $script
> -	echo 'export TARGET_SYS=${TARGET_SYS}' >> $script
> +	echo 'export MULTIMACH_TARGET_SYS=${MULTIMACH_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 CPATH=$SDK_PATH/$MULTIMACH_TARGET_SYS/usr/include:$CPATH' >> $script
> +	echo 'export LIBTOOL_SYSROOT_PATH=$SDK_PATH/$MULTIMACH_TARGET_SYS' >> $script
> +	echo 'export PKG_CONFIG_SYSROOT_DIR=$SDK_PATH/$MULTIMACH_TARGET_SYS' >> $script
> +	echo 'export PKG_CONFIG_PATH=$SDK_PATH/$MULTIMACH_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
> +	echo 'alias opkg-target="LD_LIBRARY_PATH=$SDK_PATH/lib $SDK_PATH/bin/opkg-cl -f $SDK_PATH/$MULTIMACH_TARGET_SYS${sysconfdir}/opkg.conf -o $SDK_PATH/$MULTIMACH_TARGET_SYS"' >> $script
>  
>  	# Add version information
>  	versionfile=${SDK_OUTPUT}/${SDKPATH}/version

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFL0X+LMkyGM64RGpERAjk7AJ44eTjMVw7SD+Qapa1LdwJO5tiEXQCcCw2S
EHftzrdtZOChyR9eIKhJ0aw=
=AHEQ
-----END PGP SIGNATURE-----




^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS
  2010-04-23 11:07 ` Koen Kooi
@ 2010-04-23 18:07   ` Tom Rini
  2010-04-23 18:22     ` Denys Dmytriyenko
  0 siblings, 1 reply; 14+ messages in thread
From: Tom Rini @ 2010-04-23 18:07 UTC (permalink / raw)
  To: openembedded-devel

On Fri, 2010-04-23 at 13:07 +0200, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ping

It's better than what we have today, true.  And SDKPATH already contains
DISTRO, which is the likely changer of TOOLCHAIN_*_TASK.  So...

Acked-by: Tom Rini <tom_rini@mentor.com>

> 
> On 21-04-10 14:21, Koen Kooi wrote:
> > From: Koen Kooi <koen@openembedded.org>
> > 
> > This is the first step to be able to mix multiple arm archs (and ABIs) when installing multiple SDKs on one buildhost (e.g. armv4 and armv7a).
> > 
> > ---
> >  recipes/meta/meta-toolchain.bb |   50 ++++++++++++++++++++--------------------
> >  1 files changed, 25 insertions(+), 25 deletions(-)
> > 
> > diff --git a/recipes/meta/meta-toolchain.bb b/recipes/meta/meta-toolchain.bb
> > index adc057a..2e2196a 100644
> > --- a/recipes/meta/meta-toolchain.bb
> > +++ b/recipes/meta/meta-toolchain.bb
> > @@ -10,7 +10,7 @@ SDK_OUTPUT2 = "${SDK_DIR}/image-extras"
> >  SDK_DEPLOY = "${DEPLOY_DIR}/sdk"
> >  
> >  IPKG_HOST = "opkg-cl -f ${IPKGCONF_SDK} -o ${SDK_OUTPUT}"
> > -IPKG_TARGET = "opkg-cl -f ${IPKGCONF_TARGET} -o ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}"
> > +IPKG_TARGET = "opkg-cl -f ${IPKGCONF_TARGET} -o ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}"
> >  
> >  TOOLCHAIN_HOST_TASK ?= "task-sdk-host"
> >  TOOLCHAIN_TARGET_TASK ?= "task-sdk-bare"
> > @@ -26,14 +26,14 @@ RDEPENDS = "${DISTRO_FEED_CONFIGS} ${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TAS
> >  TOOLCHAIN_FEED_URI ?= "${DISTRO_FEED_URI}"
> >  
> >  modify_opkg_conf () {
> > -        OUTPUT_OPKGCONF_TARGET="${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}/opkg.conf"
> > -        OUTPUT_OPKGCONF_HOST="${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}/opkg-sdk.conf"
> > +        OUTPUT_OPKGCONF_TARGET="${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}/opkg.conf"
> > +        OUTPUT_OPKGCONF_HOST="${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}/opkg-sdk.conf"
> >          OUTPUT_OPKGCONF_SDK="${SDK_OUTPUT}/${sysconfdir}/opkg-sdk.conf"
> >          rm -f ${OUTPUT_OPKGCONF_TARGET}
> >          rm -f ${OUTPUT_OPKGCONF_HOST}
> >          rm -f ${OUTPUT_OPKGCONF_SDK}
> >  
> > -        if [ -e ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}/opkg/arch.conf ] ; then
> > +        if [ -e ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}/opkg/arch.conf ] ; then
> >              echo "Creating empty opkg.conf since arch.conf is already present"
> >              echo > ${OUTPUT_OPKGCONF_TARGET} 
> >          else
> > @@ -53,7 +53,7 @@ do_populate_sdk() {
> >  	rm -rf ${SDK_OUTPUT}
> >  	mkdir -p ${SDK_OUTPUT}
> >  	mkdir -p ${SDK_OUTPUT}${libdir}/opkg/
> > -	mkdir -p ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}${libdir}/opkg/
> > +	mkdir -p ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}${libdir}/opkg/
> >  
> >  	package_generate_ipkg_conf
> >  
> > @@ -79,17 +79,17 @@ do_populate_sdk() {
> >  	# Clean up empty directories from excluded packages
> >  	find ${SDK_OUTPUT} -depth -type d -empty -print0 | xargs -r0 /bin/rmdir
> >  
> > -	install -d ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}
> > -	install -m 0644 ${IPKGCONF_TARGET} ${IPKGCONF_SDK} ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}/
> > +	install -d ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}
> > +	install -m 0644 ${IPKGCONF_TARGET} ${IPKGCONF_SDK} ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}/
> >  
> >  	install -d ${SDK_OUTPUT}/${SDKPATH}/${sysconfdir}
> >  	install -m 0644 ${IPKGCONF_SDK} ${SDK_OUTPUT}/${SDKPATH}/${sysconfdir}/
> >  
> >  	# extract and store ipks, pkgdata and shlibs data
> > -	target_pkgs=`cat ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/usr/lib/opkg/status | grep Package: | cut -f 2 -d ' '`
> > +	target_pkgs=`cat ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/usr/lib/opkg/status | grep Package: | cut -f 2 -d ' '`
> >  	mkdir -p ${SDK_OUTPUT2}/${SDKPATH}/ipk/
> >  	mkdir -p ${SDK_OUTPUT2}/${SDKPATH}/pkgdata/runtime/
> > -	mkdir -p ${SDK_OUTPUT2}/${SDKPATH}/${TARGET_SYS}/shlibs/
> > +	mkdir -p ${SDK_OUTPUT2}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/shlibs/
> >  	for pkg in $target_pkgs ; do
> >  		for arch in $revipkgarchs; do
> >  			pkgnames=${DEPLOY_DIR_IPK}/$arch/${pkg}_*_$arch.ipk
> > @@ -107,7 +107,7 @@ do_populate_sdk() {
> >  						cp ${TMPDIR}/pkgdata/$pkg_subdir/runtime/$subpkg.packaged ${SDK_OUTPUT2}/${SDKPATH}/pkgdata/$pkg_subdir/runtime/
> >  					fi
> >  					if [ -e ${STAGING_DIR_TARGET}/shlibs/$subpkg.list ]; then
> > -						cp ${STAGING_DIR_TARGET}/shlibs/$subpkg.* ${SDK_OUTPUT2}/${SDKPATH}/${TARGET_SYS}/shlibs/
> > +						cp ${STAGING_DIR_TARGET}/shlibs/$subpkg.* ${SDK_OUTPUT2}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/shlibs/
> >  					fi
> >  				done
> >  				break
> > @@ -119,20 +119,20 @@ do_populate_sdk() {
> >  	# libgcc-dev should be responsible for that, but it's not getting built
> >  	# RP: it gets smashed up depending on the order that gcc, gcc-cross and 
> >  	# gcc-cross-sdk get built :( (30/11/07)
> > -	ln -sf libgcc_s.so.1 ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/lib/libgcc_s.so
> > +	ln -sf libgcc_s.so.1 ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/lib/libgcc_s.so
> >  
> >  	# With sysroot support, gcc expects the default C++ headers to be
> >  	# in a specific place.
> > -	install -d ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/include
> > -	mv ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/usr/include/c++ \
> > -		${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/include/
> > +	install -d ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/include
> > +	mv ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/usr/include/c++ \
> > +		${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/include/
> >  
> >  	# 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\$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" \
> > +	for i in `find ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS} -name \*.la`; do
> > +		sed -i 	-e "/^dependency_libs=/s,\([[:space:]']\)${base_libdir},\1\$SDK_PATH/\$MULTIMACH_TARGET_SYS${base_libdir},g" \
> > +			-e "/^dependency_libs=/s,\([[:space:]']\)${libdir},\1\$SDK_PATH/\$MULTIMACH_TARGET_SYS${libdir},g" \
> > +			-e "/^dependency_libs=/s,\-\([LR]\)${base_libdir},-\1\$SDK_PATH/\$MULTIMACH_TARGET_SYS${base_libdir},g" \
> > +			-e "/^dependency_libs=/s,\-\([LR]\)${libdir},-\1\$SDK_PATH/\$MULTIMACH_TARGET_SYS${libdir},g" \
> >  			-e 's/^installed=yes$/installed=no/' $i
> >  	done
> >  	rm -f ${SDK_OUTPUT}/${SDKPATH}/lib/*.la
> > @@ -148,15 +148,15 @@ do_populate_sdk() {
> >  	script=${SDK_OUTPUT}/${SDKPATH}/environment-setup
> >  	touch $script
> >  	echo 'export SDK_PATH=${SDKPATH}' >> $script
> > -	echo 'export TARGET_SYS=${TARGET_SYS}' >> $script
> > +	echo 'export MULTIMACH_TARGET_SYS=${MULTIMACH_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 CPATH=$SDK_PATH/$MULTIMACH_TARGET_SYS/usr/include:$CPATH' >> $script
> > +	echo 'export LIBTOOL_SYSROOT_PATH=$SDK_PATH/$MULTIMACH_TARGET_SYS' >> $script
> > +	echo 'export PKG_CONFIG_SYSROOT_DIR=$SDK_PATH/$MULTIMACH_TARGET_SYS' >> $script
> > +	echo 'export PKG_CONFIG_PATH=$SDK_PATH/$MULTIMACH_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
> > +	echo 'alias opkg-target="LD_LIBRARY_PATH=$SDK_PATH/lib $SDK_PATH/bin/opkg-cl -f $SDK_PATH/$MULTIMACH_TARGET_SYS${sysconfdir}/opkg.conf -o $SDK_PATH/$MULTIMACH_TARGET_SYS"' >> $script
> >  
> >  	# Add version information
> >  	versionfile=${SDK_OUTPUT}/${SDKPATH}/version
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
> 
> iD8DBQFL0X+LMkyGM64RGpERAjk7AJ44eTjMVw7SD+Qapa1LdwJO5tiEXQCcCw2S
> EHftzrdtZOChyR9eIKhJ0aw=
> =AHEQ
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel


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



^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS
  2010-04-23 18:07   ` Tom Rini
@ 2010-04-23 18:22     ` Denys Dmytriyenko
  2010-04-23 18:45       ` Koen Kooi
  0 siblings, 1 reply; 14+ messages in thread
From: Denys Dmytriyenko @ 2010-04-23 18:22 UTC (permalink / raw)
  To: openembedded-devel

On Fri, Apr 23, 2010 at 11:07:33AM -0700, Tom Rini wrote:
> On Fri, 2010-04-23 at 13:07 +0200, Koen Kooi wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Ping
> 
> It's better than what we have today, true.  And SDKPATH already contains
> DISTRO, which is the likely changer of TOOLCHAIN_*_TASK.  So...
> 
> Acked-by: Tom Rini <tom_rini@mentor.com>

In general:

Acked-by: Denys Dmytriyenko <denis@denix.org>

But, should we then create an arch-specific environment-setup scripts (e.g. 
one for armv4 and another for armv7a, as per your example below)?

> > On 21-04-10 14:21, Koen Kooi wrote:
> > > From: Koen Kooi <koen@openembedded.org>
> > > 
> > > This is the first step to be able to mix multiple arm archs (and ABIs) 
> > > when installing multiple SDKs on one buildhost (e.g. armv4 and armv7a).
> > > 
> > > ---
> > >  recipes/meta/meta-toolchain.bb |   50 ++++++++++++++++++++--------------------
> > >  1 files changed, 25 insertions(+), 25 deletions(-)
> > > 
> > > diff --git a/recipes/meta/meta-toolchain.bb b/recipes/meta/meta-toolchain.bb
> > > index adc057a..2e2196a 100644
> > > --- a/recipes/meta/meta-toolchain.bb
> > > +++ b/recipes/meta/meta-toolchain.bb
> > > @@ -10,7 +10,7 @@ SDK_OUTPUT2 = "${SDK_DIR}/image-extras"
> > >  SDK_DEPLOY = "${DEPLOY_DIR}/sdk"
> > >  
> > >  IPKG_HOST = "opkg-cl -f ${IPKGCONF_SDK} -o ${SDK_OUTPUT}"
> > > -IPKG_TARGET = "opkg-cl -f ${IPKGCONF_TARGET} -o ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}"
> > > +IPKG_TARGET = "opkg-cl -f ${IPKGCONF_TARGET} -o ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}"
> > >  
> > >  TOOLCHAIN_HOST_TASK ?= "task-sdk-host"
> > >  TOOLCHAIN_TARGET_TASK ?= "task-sdk-bare"
> > > @@ -26,14 +26,14 @@ RDEPENDS = "${DISTRO_FEED_CONFIGS} ${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TAS
> > >  TOOLCHAIN_FEED_URI ?= "${DISTRO_FEED_URI}"
> > >  
> > >  modify_opkg_conf () {
> > > -        OUTPUT_OPKGCONF_TARGET="${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}/opkg.conf"
> > > -        OUTPUT_OPKGCONF_HOST="${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}/opkg-sdk.conf"
> > > +        OUTPUT_OPKGCONF_TARGET="${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}/opkg.conf"
> > > +        OUTPUT_OPKGCONF_HOST="${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}/opkg-sdk.conf"
> > >          OUTPUT_OPKGCONF_SDK="${SDK_OUTPUT}/${sysconfdir}/opkg-sdk.conf"
> > >          rm -f ${OUTPUT_OPKGCONF_TARGET}
> > >          rm -f ${OUTPUT_OPKGCONF_HOST}
> > >          rm -f ${OUTPUT_OPKGCONF_SDK}
> > >  
> > > -        if [ -e ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}/opkg/arch.conf ] ; then
> > > +        if [ -e ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}/opkg/arch.conf ] ; then
> > >              echo "Creating empty opkg.conf since arch.conf is already present"
> > >              echo > ${OUTPUT_OPKGCONF_TARGET} 
> > >          else
> > > @@ -53,7 +53,7 @@ do_populate_sdk() {
> > >  	rm -rf ${SDK_OUTPUT}
> > >  	mkdir -p ${SDK_OUTPUT}
> > >  	mkdir -p ${SDK_OUTPUT}${libdir}/opkg/
> > > -	mkdir -p ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}${libdir}/opkg/
> > > +	mkdir -p ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}${libdir}/opkg/
> > >  
> > >  	package_generate_ipkg_conf
> > >  
> > > @@ -79,17 +79,17 @@ do_populate_sdk() {
> > >  	# Clean up empty directories from excluded packages
> > >  	find ${SDK_OUTPUT} -depth -type d -empty -print0 | xargs -r0 /bin/rmdir
> > >  
> > > -	install -d ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}
> > > -	install -m 0644 ${IPKGCONF_TARGET} ${IPKGCONF_SDK} ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/${sysconfdir}/
> > > +	install -d ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}
> > > +	install -m 0644 ${IPKGCONF_TARGET} ${IPKGCONF_SDK} ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/${sysconfdir}/
> > >  
> > >  	install -d ${SDK_OUTPUT}/${SDKPATH}/${sysconfdir}
> > >  	install -m 0644 ${IPKGCONF_SDK} ${SDK_OUTPUT}/${SDKPATH}/${sysconfdir}/
> > >  
> > >  	# extract and store ipks, pkgdata and shlibs data
> > > -	target_pkgs=`cat ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/usr/lib/opkg/status | grep Package: | cut -f 2 -d ' '`
> > > +	target_pkgs=`cat ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/usr/lib/opkg/status | grep Package: | cut -f 2 -d ' '`
> > >  	mkdir -p ${SDK_OUTPUT2}/${SDKPATH}/ipk/
> > >  	mkdir -p ${SDK_OUTPUT2}/${SDKPATH}/pkgdata/runtime/
> > > -	mkdir -p ${SDK_OUTPUT2}/${SDKPATH}/${TARGET_SYS}/shlibs/
> > > +	mkdir -p ${SDK_OUTPUT2}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/shlibs/
> > >  	for pkg in $target_pkgs ; do
> > >  		for arch in $revipkgarchs; do
> > >  			pkgnames=${DEPLOY_DIR_IPK}/$arch/${pkg}_*_$arch.ipk
> > > @@ -107,7 +107,7 @@ do_populate_sdk() {
> > >  						cp ${TMPDIR}/pkgdata/$pkg_subdir/runtime/$subpkg.packaged ${SDK_OUTPUT2}/${SDKPATH}/pkgdata/$pkg_subdir/runtime/
> > >  					fi
> > >  					if [ -e ${STAGING_DIR_TARGET}/shlibs/$subpkg.list ]; then
> > > -						cp ${STAGING_DIR_TARGET}/shlibs/$subpkg.* ${SDK_OUTPUT2}/${SDKPATH}/${TARGET_SYS}/shlibs/
> > > +						cp ${STAGING_DIR_TARGET}/shlibs/$subpkg.* ${SDK_OUTPUT2}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/shlibs/
> > >  					fi
> > >  				done
> > >  				break
> > > @@ -119,20 +119,20 @@ do_populate_sdk() {
> > >  	# libgcc-dev should be responsible for that, but it's not getting built
> > >  	# RP: it gets smashed up depending on the order that gcc, gcc-cross and 
> > >  	# gcc-cross-sdk get built :( (30/11/07)
> > > -	ln -sf libgcc_s.so.1 ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/lib/libgcc_s.so
> > > +	ln -sf libgcc_s.so.1 ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/lib/libgcc_s.so
> > >  
> > >  	# With sysroot support, gcc expects the default C++ headers to be
> > >  	# in a specific place.
> > > -	install -d ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/include
> > > -	mv ${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/usr/include/c++ \
> > > -		${SDK_OUTPUT}/${SDKPATH}/${TARGET_SYS}/include/
> > > +	install -d ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/include
> > > +	mv ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/usr/include/c++ \
> > > +		${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS}/include/
> > >  
> > >  	# 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\$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" \
> > > +	for i in `find ${SDK_OUTPUT}/${SDKPATH}/${MULTIMACH_TARGET_SYS} -name \*.la`; do
> > > +		sed -i 	-e "/^dependency_libs=/s,\([[:space:]']\)${base_libdir},\1\$SDK_PATH/\$MULTIMACH_TARGET_SYS${base_libdir},g" \
> > > +			-e "/^dependency_libs=/s,\([[:space:]']\)${libdir},\1\$SDK_PATH/\$MULTIMACH_TARGET_SYS${libdir},g" \
> > > +			-e "/^dependency_libs=/s,\-\([LR]\)${base_libdir},-\1\$SDK_PATH/\$MULTIMACH_TARGET_SYS${base_libdir},g" \
> > > +			-e "/^dependency_libs=/s,\-\([LR]\)${libdir},-\1\$SDK_PATH/\$MULTIMACH_TARGET_SYS${libdir},g" \
> > >  			-e 's/^installed=yes$/installed=no/' $i
> > >  	done
> > >  	rm -f ${SDK_OUTPUT}/${SDKPATH}/lib/*.la
> > > @@ -148,15 +148,15 @@ do_populate_sdk() {
> > >  	script=${SDK_OUTPUT}/${SDKPATH}/environment-setup
> > >  	touch $script
> > >  	echo 'export SDK_PATH=${SDKPATH}' >> $script
> > > -	echo 'export TARGET_SYS=${TARGET_SYS}' >> $script
> > > +	echo 'export MULTIMACH_TARGET_SYS=${MULTIMACH_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 CPATH=$SDK_PATH/$MULTIMACH_TARGET_SYS/usr/include:$CPATH' >> $script
> > > +	echo 'export LIBTOOL_SYSROOT_PATH=$SDK_PATH/$MULTIMACH_TARGET_SYS' >> $script
> > > +	echo 'export PKG_CONFIG_SYSROOT_DIR=$SDK_PATH/$MULTIMACH_TARGET_SYS' >> $script
> > > +	echo 'export PKG_CONFIG_PATH=$SDK_PATH/$MULTIMACH_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
> > > +	echo 'alias opkg-target="LD_LIBRARY_PATH=$SDK_PATH/lib $SDK_PATH/bin/opkg-cl -f $SDK_PATH/$MULTIMACH_TARGET_SYS${sysconfdir}/opkg.conf -o $SDK_PATH/$MULTIMACH_TARGET_SYS"' >> $script
> > >  
> > >  	# Add version information
> > >  	versionfile=${SDK_OUTPUT}/${SDKPATH}/version
> > 
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.5 (Darwin)
> > 
> > iD8DBQFL0X+LMkyGM64RGpERAjk7AJ44eTjMVw7SD+Qapa1LdwJO5tiEXQCcCw2S
> > EHftzrdtZOChyR9eIKhJ0aw=
> > =AHEQ
> > -----END PGP SIGNATURE-----
> > 
> > 
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 
> 
> -- 
> 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



^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS
  2010-04-23 18:22     ` Denys Dmytriyenko
@ 2010-04-23 18:45       ` Koen Kooi
  2010-04-23 18:55         ` Tom Rini
  0 siblings, 1 reply; 14+ messages in thread
From: Koen Kooi @ 2010-04-23 18:45 UTC (permalink / raw)
  To: openembedded-devel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23-04-10 20:22, Denys Dmytriyenko wrote:
> On Fri, Apr 23, 2010 at 11:07:33AM -0700, Tom Rini wrote:
>> On Fri, 2010-04-23 at 13:07 +0200, Koen Kooi wrote:
> Ping
>>>
>>> It's better than what we have today, true.  And SDKPATH already contains
>>> DISTRO, which is the likely changer of TOOLCHAIN_*_TASK.  So...
>>>
>>> Acked-by: Tom Rini <tom_rini@mentor.com>
> 
>> In general:
> 
>> Acked-by: Denys Dmytriyenko <denis@denix.org>
> 
>> But, should we then create an arch-specific environment-setup scripts (e.g. 
>> one for armv4 and another for armv7a, as per your example below)?

Yes, that needs to be done, as well as seperating the cross tools in
case different archs need different versions (as is the case with
angstrom, v5te and v7a need different binutils). This change largely to
to cosmetically highlight that the toolchain is not really "universal"
(yet).

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFL0eqsMkyGM64RGpERAlyIAJwPerUHqUl3hWoaGGKXT4yFR24DRgCfR9r4
Y/qi89JGvuo93albm+jv1nc=
=bP/Y
-----END PGP SIGNATURE-----




^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS
  2010-04-23 18:45       ` Koen Kooi
@ 2010-04-23 18:55         ` Tom Rini
  2010-04-23 20:29           ` Koen Kooi
  0 siblings, 1 reply; 14+ messages in thread
From: Tom Rini @ 2010-04-23 18:55 UTC (permalink / raw)
  To: openembedded-devel

On Fri, 2010-04-23 at 20:45 +0200, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 23-04-10 20:22, Denys Dmytriyenko wrote:
> > On Fri, Apr 23, 2010 at 11:07:33AM -0700, Tom Rini wrote:
> >> On Fri, 2010-04-23 at 13:07 +0200, Koen Kooi wrote:
> > Ping
> >>>
> >>> It's better than what we have today, true.  And SDKPATH already contains
> >>> DISTRO, which is the likely changer of TOOLCHAIN_*_TASK.  So...
> >>>
> >>> Acked-by: Tom Rini <tom_rini@mentor.com>
> > 
> >> In general:
> > 
> >> Acked-by: Denys Dmytriyenko <denis@denix.org>
> > 
> >> But, should we then create an arch-specific environment-setup scripts (e.g. 
> >> one for armv4 and another for armv7a, as per your example below)?
> 
> Yes, that needs to be done, as well as seperating the cross tools in
> case different archs need different versions (as is the case with
> angstrom, v5te and v7a need different binutils). This change largely to
> to cosmetically highlight that the toolchain is not really "universal"
> (yet).

And we can talk about if "universal" is really a good goal either.
Taking a bit of a guess in the dark, an SDK with support for all the fun
stuff found on Beagleboard might not be done easily with also having
support for all the fun stuff found on some other ref board too.

I tend to think of these exports as being very board specific, but that
doesn't quite flow with how others think of this stuff, today.

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



^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS
  2010-04-23 18:55         ` Tom Rini
@ 2010-04-23 20:29           ` Koen Kooi
  2010-04-23 20:54             ` Denys Dmytriyenko
  0 siblings, 1 reply; 14+ messages in thread
From: Koen Kooi @ 2010-04-23 20:29 UTC (permalink / raw)
  To: openembedded-devel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23-04-10 20:55, Tom Rini wrote:
> On Fri, 2010-04-23 at 20:45 +0200, Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 23-04-10 20:22, Denys Dmytriyenko wrote:
>>> On Fri, Apr 23, 2010 at 11:07:33AM -0700, Tom Rini wrote:
>>>> On Fri, 2010-04-23 at 13:07 +0200, Koen Kooi wrote:
>>> Ping
>>>>>
>>>>> It's better than what we have today, true.  And SDKPATH already contains
>>>>> DISTRO, which is the likely changer of TOOLCHAIN_*_TASK.  So...
>>>>>
>>>>> Acked-by: Tom Rini <tom_rini@mentor.com>
>>>
>>>> In general:
>>>
>>>> Acked-by: Denys Dmytriyenko <denis@denix.org>
>>>
>>>> But, should we then create an arch-specific environment-setup scripts (e.g. 
>>>> one for armv4 and another for armv7a, as per your example below)?
>>
>> Yes, that needs to be done, as well as seperating the cross tools in
>> case different archs need different versions (as is the case with
>> angstrom, v5te and v7a need different binutils). This change largely to
>> to cosmetically highlight that the toolchain is not really "universal"
>> (yet).
> 
> And we can talk about if "universal" is really a good goal either.

I don't think we can make it "universal" without sacrificing key benefits.

> Taking a bit of a guess in the dark, an SDK with support for all the fun
> stuff found on Beagleboard might not be done easily with also having
> support for all the fun stuff found on some other ref board too.

The immediate problem I'm trying to address now is that having both an
armv5te and armv7a toolchain installed is breaking horribly. Ideally
they would coexist peacefully, but I don't know if we can manage that,
without impacting the ease of use.

> I tend to think of these exports as being very board specific, but that
> doesn't quite flow with how others think of this stuff, today.

The current output is highly machine specific, since it will include
MACHINE_ARCH in the opkg configuration. For gcc/libc/binutils that is
usually OK (except when using an ep93xx sdk to target e.g. om-gta01),
but for things like clutter or mesa where the machine directly impacts
the shared lib it gets ugly real fast.
Luckily at work I currently have a fairly nice situation: all arm9
targets are arm926 without any form of VFP/FPA and no 3d accell and all
cortex-a8 targets have the same VFP and NEON blocks and the 3D accel is
the same. Of course with my angstrom hat on, the situation is different...

I'm eagerly awaiting Richards branch to get merged so I can work on the
nicer areas of meta-toolchain-qte :)

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFL0gNCMkyGM64RGpERAiVuAJ4jIidQWTLhphBZl1sK5gxdZ6gM1gCguxNG
kEfwpxZtU3TJg6cC/XCSSeI=
=HXKJ
-----END PGP SIGNATURE-----




^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS
  2010-04-23 20:29           ` Koen Kooi
@ 2010-04-23 20:54             ` Denys Dmytriyenko
  2010-04-23 21:43               ` Tom Rini
  0 siblings, 1 reply; 14+ messages in thread
From: Denys Dmytriyenko @ 2010-04-23 20:54 UTC (permalink / raw)
  To: openembedded-devel

On Fri, Apr 23, 2010 at 10:29:54PM +0200, Koen Kooi wrote:
> >> Yes, that needs to be done, as well as seperating the cross tools in
> >> case different archs need different versions (as is the case with
> >> angstrom, v5te and v7a need different binutils). This change largely to
> >> to cosmetically highlight that the toolchain is not really "universal"
> >> (yet).
> > 
> > And we can talk about if "universal" is really a good goal either.
> 
> I don't think we can make it "universal" without sacrificing key benefits.
> 
> > Taking a bit of a guess in the dark, an SDK with support for all the fun
> > stuff found on Beagleboard might not be done easily with also having
> > support for all the fun stuff found on some other ref board too.
> 
> The immediate problem I'm trying to address now is that having both an
> armv5te and armv7a toolchain installed is breaking horribly. Ideally
> they would coexist peacefully, but I don't know if we can manage that,
> without impacting the ease of use.

I know it's not what you are looking for, but easier workaround would be to 
install different toolchains in different paths... :)

-- 
Denys



^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS
  2010-04-23 20:54             ` Denys Dmytriyenko
@ 2010-04-23 21:43               ` Tom Rini
  2010-04-24 17:07                 ` Denys Dmytriyenko
  0 siblings, 1 reply; 14+ messages in thread
From: Tom Rini @ 2010-04-23 21:43 UTC (permalink / raw)
  To: openembedded-devel

On Fri, 2010-04-23 at 16:54 -0400, Denys Dmytriyenko wrote:
> On Fri, Apr 23, 2010 at 10:29:54PM +0200, Koen Kooi wrote:
> > >> Yes, that needs to be done, as well as seperating the cross tools in
> > >> case different archs need different versions (as is the case with
> > >> angstrom, v5te and v7a need different binutils). This change largely to
> > >> to cosmetically highlight that the toolchain is not really "universal"
> > >> (yet).
> > > 
> > > And we can talk about if "universal" is really a good goal either.
> > 
> > I don't think we can make it "universal" without sacrificing key benefits.
> > 
> > > Taking a bit of a guess in the dark, an SDK with support for all the fun
> > > stuff found on Beagleboard might not be done easily with also having
> > > support for all the fun stuff found on some other ref board too.
> > 
> > The immediate problem I'm trying to address now is that having both an
> > armv5te and armv7a toolchain installed is breaking horribly. Ideally
> > they would coexist peacefully, but I don't know if we can manage that,
> > without impacting the ease of use.
> 
> I know it's not what you are looking for, but easier workaround would be to 
> install different toolchains in different paths... :)

Or, noting all of the very machine specific stuff Koen mentions
elsewhere, we don't pretend it's an SDK for armv7a but just call it an
SDK for ${MACHINE} and encode that into the PATH.

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



^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS
  2010-04-23 21:43               ` Tom Rini
@ 2010-04-24 17:07                 ` Denys Dmytriyenko
  2010-04-24 18:51                   ` Tom Rini
  0 siblings, 1 reply; 14+ messages in thread
From: Denys Dmytriyenko @ 2010-04-24 17:07 UTC (permalink / raw)
  To: openembedded-devel

On Fri, Apr 23, 2010 at 02:43:13PM -0700, Tom Rini wrote:
> On Fri, 2010-04-23 at 16:54 -0400, Denys Dmytriyenko wrote:
> > On Fri, Apr 23, 2010 at 10:29:54PM +0200, Koen Kooi wrote:
> > > >> Yes, that needs to be done, as well as seperating the cross tools in
> > > >> case different archs need different versions (as is the case with
> > > >> angstrom, v5te and v7a need different binutils). This change largely to
> > > >> to cosmetically highlight that the toolchain is not really "universal"
> > > >> (yet).
> > > > 
> > > > And we can talk about if "universal" is really a good goal either.
> > > 
> > > I don't think we can make it "universal" without sacrificing key benefits.
> > > 
> > > > Taking a bit of a guess in the dark, an SDK with support for all the fun
> > > > stuff found on Beagleboard might not be done easily with also having
> > > > support for all the fun stuff found on some other ref board too.
> > > 
> > > The immediate problem I'm trying to address now is that having both an
> > > armv5te and armv7a toolchain installed is breaking horribly. Ideally
> > > they would coexist peacefully, but I don't know if we can manage that,
> > > without impacting the ease of use.
> > 
> > I know it's not what you are looking for, but easier workaround would be to 
> > install different toolchains in different paths... :)
> 
> Or, noting all of the very machine specific stuff Koen mentions
> elsewhere, we don't pretend it's an SDK for armv7a but just call it an
> SDK for ${MACHINE} and encode that into the PATH.

The thing is, while SDKPATH is the same by default for both of the 
incompatile toolchains (e.g. for Angstrom it is /usr/local/angstrom), the 
resulting tarballs are named with the specific architecture in the name taken 
from the FEED_ARCH:

TOOLCHAIN_OUTPUTNAME ?= "${DISTRO}-${DISTRO_VERSION}-${SDK_SYS}-${FEED_ARCH}-${TARGET_OS}-${SDK_SUFFIX}"

While not machine-specific, when installed in separate locations, can safely 
separate armv5te from armv7a. That way even the host cross tools are separated.

-- 
Denys



^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS
  2010-04-24 17:07                 ` Denys Dmytriyenko
@ 2010-04-24 18:51                   ` Tom Rini
  2010-04-26 18:03                     ` Denys Dmytriyenko
  0 siblings, 1 reply; 14+ messages in thread
From: Tom Rini @ 2010-04-24 18:51 UTC (permalink / raw)
  To: openembedded-devel

On Sat, 2010-04-24 at 13:07 -0400, Denys Dmytriyenko wrote:
> On Fri, Apr 23, 2010 at 02:43:13PM -0700, Tom Rini wrote:
> > On Fri, 2010-04-23 at 16:54 -0400, Denys Dmytriyenko wrote:
> > > On Fri, Apr 23, 2010 at 10:29:54PM +0200, Koen Kooi wrote:
> > > > >> Yes, that needs to be done, as well as seperating the cross tools in
> > > > >> case different archs need different versions (as is the case with
> > > > >> angstrom, v5te and v7a need different binutils). This change largely to
> > > > >> to cosmetically highlight that the toolchain is not really "universal"
> > > > >> (yet).
> > > > > 
> > > > > And we can talk about if "universal" is really a good goal either.
> > > > 
> > > > I don't think we can make it "universal" without sacrificing key benefits.
> > > > 
> > > > > Taking a bit of a guess in the dark, an SDK with support for all the fun
> > > > > stuff found on Beagleboard might not be done easily with also having
> > > > > support for all the fun stuff found on some other ref board too.
> > > > 
> > > > The immediate problem I'm trying to address now is that having both an
> > > > armv5te and armv7a toolchain installed is breaking horribly. Ideally
> > > > they would coexist peacefully, but I don't know if we can manage that,
> > > > without impacting the ease of use.
> > > 
> > > I know it's not what you are looking for, but easier workaround would be to 
> > > install different toolchains in different paths... :)
> > 
> > Or, noting all of the very machine specific stuff Koen mentions
> > elsewhere, we don't pretend it's an SDK for armv7a but just call it an
> > SDK for ${MACHINE} and encode that into the PATH.
> 
> The thing is, while SDKPATH is the same by default for both of the 
> incompatile toolchains (e.g. for Angstrom it is /usr/local/angstrom), the 
> resulting tarballs are named with the specific architecture in the name taken 
> from the FEED_ARCH:
> 
> TOOLCHAIN_OUTPUTNAME ?= "${DISTRO}-${DISTRO_VERSION}-${SDK_SYS}-${FEED_ARCH}-${TARGET_OS}-${SDK_SUFFIX}"
> 
> While not machine-specific, when installed in separate locations, can safely 
> separate armv5te from armv7a. That way even the host cross tools are separated.

Right.  I'm saying that SDKPATH should be more than /usr/local/${DISTRO}
but /usr/local/${DISTRO}/${MACHINE} by default, toss a comment above
about why (output is very MACHINE specific in certain cases) and maybe
update the default TOOLCHAIN_OUTPUTNAME too.


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



^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS
  2010-04-24 18:51                   ` Tom Rini
@ 2010-04-26 18:03                     ` Denys Dmytriyenko
  2010-04-27 18:18                       ` Tom Rini
  0 siblings, 1 reply; 14+ messages in thread
From: Denys Dmytriyenko @ 2010-04-26 18:03 UTC (permalink / raw)
  To: openembedded-devel

On Sat, Apr 24, 2010 at 11:51:09AM -0700, Tom Rini wrote:
> On Sat, 2010-04-24 at 13:07 -0400, Denys Dmytriyenko wrote:
> > On Fri, Apr 23, 2010 at 02:43:13PM -0700, Tom Rini wrote:
> > > On Fri, 2010-04-23 at 16:54 -0400, Denys Dmytriyenko wrote:
> > > > On Fri, Apr 23, 2010 at 10:29:54PM +0200, Koen Kooi wrote:
> > > > > >> Yes, that needs to be done, as well as seperating the cross tools in
> > > > > >> case different archs need different versions (as is the case with
> > > > > >> angstrom, v5te and v7a need different binutils). This change largely to
> > > > > >> to cosmetically highlight that the toolchain is not really "universal"
> > > > > >> (yet).
> > > > > > 
> > > > > > And we can talk about if "universal" is really a good goal either.
> > > > > 
> > > > > I don't think we can make it "universal" without sacrificing key benefits.
> > > > > 
> > > > > > Taking a bit of a guess in the dark, an SDK with support for all the fun
> > > > > > stuff found on Beagleboard might not be done easily with also having
> > > > > > support for all the fun stuff found on some other ref board too.
> > > > > 
> > > > > The immediate problem I'm trying to address now is that having both an
> > > > > armv5te and armv7a toolchain installed is breaking horribly. Ideally
> > > > > they would coexist peacefully, but I don't know if we can manage that,
> > > > > without impacting the ease of use.
> > > > 
> > > > I know it's not what you are looking for, but easier workaround would be to 
> > > > install different toolchains in different paths... :)
> > > 
> > > Or, noting all of the very machine specific stuff Koen mentions
> > > elsewhere, we don't pretend it's an SDK for armv7a but just call it an
> > > SDK for ${MACHINE} and encode that into the PATH.
> > 
> > The thing is, while SDKPATH is the same by default for both of the 
> > incompatile toolchains (e.g. for Angstrom it is /usr/local/angstrom), the 
> > resulting tarballs are named with the specific architecture in the name taken 
> > from the FEED_ARCH:
> > 
> > TOOLCHAIN_OUTPUTNAME ?= "${DISTRO}-${DISTRO_VERSION}-${SDK_SYS}-${FEED_ARCH}-${TARGET_OS}-${SDK_SUFFIX}"
> > 
> > While not machine-specific, when installed in separate locations, can safely 
> > separate armv5te from armv7a. That way even the host cross tools are separated.
> 
> Right.  I'm saying that SDKPATH should be more than /usr/local/${DISTRO}
> but /usr/local/${DISTRO}/${MACHINE} by default, toss a comment above
> about why (output is very MACHINE specific in certain cases) and maybe
> update the default TOOLCHAIN_OUTPUTNAME too.

Ok, you asked for a comment, I'll give you two :)

1. In Arago I have a way to overwrite SDKPATH from the command line when 
building a specific SDK/toolchain. So, I can do what you suggest, but...

2. My SDKs are currently not machine-specific, moreover, they don't have the 
cross-compile tools in them (i.e. no toolchain part), as Arago uses external 
CodeSourcery toolchain for that. The only cross-tools I have in my SDKs are 
those, which are missing from CS - i.e. libtool, pkgconfig, opkg, qt4e-tools 
etc. But I still build 2 versions of SDK - armv5te and armv7a.

-- 
Denys



^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS
  2010-04-26 18:03                     ` Denys Dmytriyenko
@ 2010-04-27 18:18                       ` Tom Rini
  2010-04-30 19:35                         ` Denys Dmytriyenko
  0 siblings, 1 reply; 14+ messages in thread
From: Tom Rini @ 2010-04-27 18:18 UTC (permalink / raw)
  To: openembedded-devel

On Mon, 2010-04-26 at 14:03 -0400, Denys Dmytriyenko wrote:
> On Sat, Apr 24, 2010 at 11:51:09AM -0700, Tom Rini wrote:
[snip] 
> > Right.  I'm saying that SDKPATH should be more than /usr/local/${DISTRO}
> > but /usr/local/${DISTRO}/${MACHINE} by default, toss a comment above
> > about why (output is very MACHINE specific in certain cases) and maybe
> > update the default TOOLCHAIN_OUTPUTNAME too.
> 
> Ok, you asked for a comment, I'll give you two :)
> 
> 1. In Arago I have a way to overwrite SDKPATH from the command line when 
> building a specific SDK/toolchain. So, I can do what you suggest, but...
> 
> 2. My SDKs are currently not machine-specific, moreover, they don't have the 
> cross-compile tools in them (i.e. no toolchain part), as Arago uses external 
> CodeSourcery toolchain for that. The only cross-tools I have in my SDKs are 
> those, which are missing from CS - i.e. libtool, pkgconfig, opkg, qt4e-tools 
> etc. But I still build 2 versions of SDK - armv5te and armv7a.

I'd make a very small wager that you're unknowningly wrong about #2 or a
someone adding an RRECOMMENDS/RDEPENDS_mach somewhere (or using another
machine you haven't tried yet) from machine specific stuff leaking in
and being wrong :)

It's not the gcc & co that you get from CodeSourcery or our -sdk recipes
or whatever that makes this machine-specific but the conditional
inclusion of some userland bits (be it "small" "regular" Linux stuff or
"small" stuff for FPGAs or whatever on a particular ref board).  Or even
PACKAGE_ARCH=MACHINE stuff already being in there, again without you
knowning (some of which can be rather easily pulled out with that
removal hook you added).

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



^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS
  2010-04-27 18:18                       ` Tom Rini
@ 2010-04-30 19:35                         ` Denys Dmytriyenko
  0 siblings, 0 replies; 14+ messages in thread
From: Denys Dmytriyenko @ 2010-04-30 19:35 UTC (permalink / raw)
  To: openembedded-devel

On Tue, Apr 27, 2010 at 11:18:14AM -0700, Tom Rini wrote:
> On Mon, 2010-04-26 at 14:03 -0400, Denys Dmytriyenko wrote:
> > On Sat, Apr 24, 2010 at 11:51:09AM -0700, Tom Rini wrote:
> [snip] 
> > > Right.  I'm saying that SDKPATH should be more than /usr/local/${DISTRO}
> > > but /usr/local/${DISTRO}/${MACHINE} by default, toss a comment above
> > > about why (output is very MACHINE specific in certain cases) and maybe
> > > update the default TOOLCHAIN_OUTPUTNAME too.
> > 
> > Ok, you asked for a comment, I'll give you two :)
> > 
> > 1. In Arago I have a way to overwrite SDKPATH from the command line when 
> > building a specific SDK/toolchain. So, I can do what you suggest, but...
> > 
> > 2. My SDKs are currently not machine-specific, moreover, they don't have the 
> > cross-compile tools in them (i.e. no toolchain part), as Arago uses external 
> > CodeSourcery toolchain for that. The only cross-tools I have in my SDKs are 
> > those, which are missing from CS - i.e. libtool, pkgconfig, opkg, qt4e-tools 
> > etc. But I still build 2 versions of SDK - armv5te and armv7a.
> 
> I'd make a very small wager that you're unknowningly wrong about #2 or a
> someone adding an RRECOMMENDS/RDEPENDS_mach somewhere (or using another
> machine you haven't tried yet) from machine specific stuff leaking in
> and being wrong :)
> 
> It's not the gcc & co that you get from CodeSourcery or our -sdk recipes
> or whatever that makes this machine-specific but the conditional
> inclusion of some userland bits (be it "small" "regular" Linux stuff or
> "small" stuff for FPGAs or whatever on a particular ref board).  Or even
> PACKAGE_ARCH=MACHINE stuff already being in there, again without you
> knowning (some of which can be rather easily pulled out with that
> removal hook you added).

In general, you are correct, but:

$ grep 'Architecture:' $SDK_PATH/$TARGET_SYS/usr/lib/opkg/status | uniq
armv7a

So, I'm being carefull and use the EXCLUDE removal hook extensively :)

-- 
Denys



^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~2010-04-30 19:40 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-21 12:21 [RFC][PATCH] meta-toolchain: use MULTIMACH_TARGET_SYS instead of TARGET_SYS Koen Kooi
2010-04-23 11:07 ` Koen Kooi
2010-04-23 18:07   ` Tom Rini
2010-04-23 18:22     ` Denys Dmytriyenko
2010-04-23 18:45       ` Koen Kooi
2010-04-23 18:55         ` Tom Rini
2010-04-23 20:29           ` Koen Kooi
2010-04-23 20:54             ` Denys Dmytriyenko
2010-04-23 21:43               ` Tom Rini
2010-04-24 17:07                 ` Denys Dmytriyenko
2010-04-24 18:51                   ` Tom Rini
2010-04-26 18:03                     ` Denys Dmytriyenko
2010-04-27 18:18                       ` Tom Rini
2010-04-30 19:35                         ` Denys Dmytriyenko

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.