| Submitter | Fabien Proriol |
|---|---|
| Date | Oct. 16, 2012, 1:37 p.m. |
| Message ID | <1350394502-7745-1-git-send-email-fabien.proriol@jdsu.com> |
| Download | mbox | patch |
| Permalink | /patch/38185/ |
| State | Not Applicable |
| Headers | show |
Comments
On Tue, Oct 16, 2012 at 01:37:17PM +0000, Fabien Proriol wrote: > In the previous version, tar extraction use the --strip-component > option with "4" hard coded value. > If we set another SDKPATH, with a different depth, the sdk installation > fails. > > This patch computes the level from the SDKPATH value. Thanks! That's part of the problem I was having lately. Although, I think this patch should go to OE-Core list instead... Do you also see the problem building gcc-cross-initial/intermediate complaining about missing headers from sysroot (it loses -nativesdk suffix for some reason, when looking for the system headers), when building with the new SDKPATH/SDK_NAME? I believe there's some path hardcoded somewhere in the gcc/cross recipes, but I wasn't able to debug it yet...
>> In the previous version, tar extraction use the --strip-component >> option with "4" hard coded value. >> If we set another SDKPATH, with a different depth, the sdk installation >> fails. >> >> This patch computes the level from the SDKPATH value. > Thanks! That's part of the problem I was having lately. Although, I think this > patch should go to OE-Core list instead... OK, I re-sent this patch to OE-Core. > Do you also see the problem building gcc-cross-initial/intermediate > complaining about missing headers from sysroot (it loses -nativesdk suffix > for some reason, when looking for the system headers), when building with the > new SDKPATH/SDK_NAME? I believe there's some path hardcoded somewhere in the > gcc/cross recipes, but I wasn't able to debug it yet... > No, I haven't seen this type of problem. I will look if I see somethings wrong in recipe. But now, with Yocto 1.2-RC4, I built for PowerPC, a toolchain, a target image with my applications, my own kernel, without any problem except the one this patch solved. Fabien
Patch
diff --git a/meta/classes/populate_sdk_base.bbclass b/meta/classes/populate_sdk_base.bbclass index 6eb6726..971adfc 100644 --- a/meta/classes/populate_sdk_base.bbclass +++ b/meta/classes/populate_sdk_base.bbclass @@ -117,6 +117,7 @@ fakeroot create_shar() { #!/bin/bash DEFAULT_INSTALL_DIR="${SDKPATH}" +COMPONENTS_LEN=$(echo ".${SDKPATH}" | sed "s/\// /g" | wc -w) printf "Enter target directory for SDK (default: $DEFAULT_INSTALL_DIR): " read target_sdk_dir @@ -153,7 +154,7 @@ fi payload_offset=$(($(grep -na -m1 "^MARKER:$" $0|cut -d':' -f1) + 1)) printf "Extracting SDK..." -tail -n +$payload_offset $0| tar xj --strip-components=4 -C $target_sdk_dir +tail -n +$payload_offset $0| tar xj --strip-components=$COMPONENTS_LEN -C $target_sdk_dir echo "done" printf "Setting it up..."
In the previous version, tar extraction use the --strip-component option with "4" hard coded value. If we set another SDKPATH, with a different depth, the sdk installation fails. This patch computes the level from the SDKPATH value. Signed-off-by: Fabien Proriol <fabien.proriol@jdsu.com> --- meta/classes/populate_sdk_base.bbclass | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)