[PATCH 1/2] toolchain-shar-relocate: don't assume last state of env_setup_script is good

[PATCH 1/2] toolchain-shar-relocate: don't assume last state of env_setup_script is good

[Jean-Francois Dagenais]

From: Jean-Francois Dagenais <jeff.dagenais@gmail.com>

In the case where many environment-setup-* files exist, the incorrect
filename might be lastly set in env_setup_script, which leads to
incorrect behaviour for the initialization of native_sysroot.

The scenario I had was that our custom meta-toolchain-*.bb, which
inherits populate_sdk, defined another environment-setup-* file to dump
variable information for qt-creator. The file is named like so in order
for the sdk shell script to pick it up and fix the SDK paths in the
file. Since it (coincidentally) alphabetically comes after ...-core2, it
was last set in env_setup_script and the grep OECORE_NATIVE_SYSROOT
would simply be blank. The apparent symptom was "...relocate_sdk.py:
Argument list too long" since the find command would not be searching in
the right path.
---
 meta/files/toolchain-shar-relocate.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/files/toolchain-shar-relocate.sh b/meta/files/toolchain-shar-relocate.sh
index dfb8e16..bfcf52e 100644
--- a/meta/files/toolchain-shar-relocate.sh
+++ b/meta/files/toolchain-shar-relocate.sh
@@ -1,3 +1,5 @@
+#reset the env_setup_script value to the proper value
+env_setup_script=$target_sdk_dir/environment-setup-@REAL_MULTIMACH_TARGET_SYS@
 # fix dynamic loader paths in all ELF SDK binaries
 native_sysroot=$($SUDO_EXEC cat $env_setup_script |grep 'OECORE_NATIVE_SYSROOT='|cut -d'=' -f2|tr -d '"')
 dl_path=$($SUDO_EXEC find $native_sysroot/lib -name "ld-linux*")
-- 
2.1.4

[PATCH 2/2] toolchain-shar-extract: don't forget to fix paths in environment-setup.d as well

[Jean-Francois Dagenais]

From: Jean-Philippe Comtois <comtoisj@sonatest.com>

There is a chance that those environment-setup.d/ directories can be
fill with scripts that need to have the environment paths fixed as well.
---
 meta/files/toolchain-shar-extract.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/files/toolchain-shar-extract.sh b/meta/files/toolchain-shar-extract.sh
index 516aa3a..79fbcb4 100644
--- a/meta/files/toolchain-shar-extract.sh
+++ b/meta/files/toolchain-shar-extract.sh
@@ -135,8 +135,8 @@ echo "done"
 
 printf "Setting it up..."
 # fix environment paths
-for env_setup_script in `ls $target_sdk_dir/environment-setup-*`; do
-	$SUDO_EXEC sed -e "s:$DEFAULT_INSTALL_DIR:$target_sdk_dir:g" -i $env_setup_script
+for env_setup_script in `ls $target_sdk_dir/environment-setup-* $target_sdk_dir/sysroots/*/environment-setup.d/*`; do
+    $SUDO_EXEC sed -e "s:$DEFAULT_INSTALL_DIR:$target_sdk_dir:g" -i $env_setup_script
 done
 
 @SDK_POST_INSTALL_COMMAND@
-- 
2.1.4

Re: [PATCH 1/2] toolchain-shar-relocate: don't assume last state of env_setup_script is good

[Paul Eggleton]

On Mon, 16 Nov 2015 14:37:16 Jean-Francois Dagenais wrote:
> From: Jean-Francois Dagenais <jeff.dagenais@gmail.com>
> 
> In the case where many environment-setup-* files exist, the incorrect
> filename might be lastly set in env_setup_script, which leads to
> incorrect behaviour for the initialization of native_sysroot.
> 
> The scenario I had was that our custom meta-toolchain-*.bb, which
> inherits populate_sdk, defined another environment-setup-* file to dump
> variable information for qt-creator. The file is named like so in order
> for the sdk shell script to pick it up and fix the SDK paths in the
> file. Since it (coincidentally) alphabetically comes after ...-core2, it
> was last set in env_setup_script and the grep OECORE_NATIVE_SYSROOT
> would simply be blank. The apparent symptom was "...relocate_sdk.py:
> Argument list too long" since the find command would not be searching in
> the right path.
> ---
>  meta/files/toolchain-shar-relocate.sh | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/files/toolchain-shar-relocate.sh
> b/meta/files/toolchain-shar-relocate.sh index dfb8e16..bfcf52e 100644
> --- a/meta/files/toolchain-shar-relocate.sh
> +++ b/meta/files/toolchain-shar-relocate.sh
> @@ -1,3 +1,5 @@
> +#reset the env_setup_script value to the proper value
> +env_setup_script=$target_sdk_dir/environment-setup-@REAL_MULTIMACH_TARGET_S
> YS@ # fix dynamic loader paths in all ELF SDK binaries
>  native_sysroot=$($SUDO_EXEC cat $env_setup_script |grep
> 'OECORE_NATIVE_SYSROOT='|cut -d'=' -f2|tr -d '"') dl_path=$($SUDO_EXEC find
> $native_sysroot/lib -name "ld-linux*")

This patch was merged to master and has unfortunately broken 
buildtools-tarball which does not use the same environment setup script name.

(Additionally this patch was missing Signed-off-by and was sent to the wrong 
list - it should have gone to the openembedded-core@lists.openembedded.org 
list instead.)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 1/2] toolchain-shar-relocate: don't assume last state of env_setup_script is good

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

On 3 December 2015 at 21:56, Paul Eggleton <paul.eggleton@linux.intel.com>
wrote:

> This patch was merged to master and has unfortunately broken
> buildtools-tarball which does not use the same environment setup script
> name.
>
> (Additionally this patch was missing Signed-off-by and was sent to the
> wrong
> list - it should have gone to the openembedded-core@lists.openembedded.org
> list instead.)
>

Urgh, sorry.  Shall I throw a revert into mut quickly or is this trivial to
fix properly?

Ross

[-- Attachment #2: Type: text/html, Size: 1003 bytes --]

Re: [PATCH 1/2] toolchain-shar-relocate: don't assume last state of env_setup_script is good

[Paul Eggleton]

On Thu, 03 Dec 2015 23:16:07 Burton, Ross wrote:
> On 3 December 2015 at 21:56, Paul Eggleton <paul.eggleton@linux.intel.com>
> 
> wrote:
> > This patch was merged to master and has unfortunately broken
> > buildtools-tarball which does not use the same environment setup script
> > name.
> > 
> > (Additionally this patch was missing Signed-off-by and was sent to the
> > wrong
> > list - it should have gone to the openembedded-core@lists.openembedded.org
> > list instead.)
> 
> Urgh, sorry.  Shall I throw a revert into mut quickly or is this trivial to
> fix properly?

I'm still investigating - don't think it should be too difficult. I'll try to 
have a patch out by the end of the day.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre