On 06/07/15 16:56, Jack Mitchell wrote:
On 06/07/15 13:30, Jack Mitchell wrote:
On 06/07/15 12:35, Jack Mitchell wrote:
On 03/07/15 15:56, Jack Mitchell wrote:
Built an SDK today on 7eb0abc5f4d971d9a511c93cfb2eb52b72e6f228 and
when I tried to install it I got the following error:
Setting it up...ls: cannot access
/home/jack/Work/build/openembedded/sdk/1/x86_64/environment-setup-*: No
such file or directory
I have been messing about with the SDK install path and at one
point it did spew out a load of files installed vs shipped warnings
I assume due to a change of path and it getting upset about it, but
since then I deleted the tmp directory and rebuilt a new SDK
without warnings. However, both acted in the same way.
The SDK then sits without installing, seemingly stuck on: grep
OECORE_NATIVE_SYSROOT, which I assume means it's looking for the
(non-existant) nvironment file.
Any clues? Is this broken for anyone else?
Cheers,
Jack.
Ok, I figured out how I broke it; I used a relative path in SDKPATH.
i.e.
SDKPATH=/path/to/sdk/../rel-sdk
So, first off; should this be supported? Secondly, the use-case I
was trying to get at was to position an SDK relative to the build
dir, i.e.
SDKPATH=${TOPDIR}/../sdk
Is there a better way to do this. I guess this problem could be
solved somewhere in an SDK class by changing the relative path to an
absolute path. Ideas?
Cheers,
Jack.
I found an ugly work-around but it would be nice for this to be
supported in the future, or at least error on a relative path.
SDKPATH := "${@os.path.abspath(d.getVar('TOPDIR',
True)+"/../sdk/"+d.getVar('SDK_VERSION',
True)+"/"+d.getVar('SDK_ARCH', True))}"
Cheers,
The saga continues... so, using a relative path is what causes bitbake
to spew the 'installed vs shipped' warnings; which I thought were the
root cause of the SDK failing to install, but apparently not. I'm
appending a custom recipe like this:
TOOLCHAIN_HOST_TASK += "nativesdk-fastboot"
Which seems to be the root cause of the SDK failing to install. I have
grepped the output of bitbake -e image -c populate_sdk and I get:
TOOLCHAIN_HOST_TASK="nativesdk-packagegroup-sdk-host
packagegroup-cross-canadian-diffusion nativesdk-fastboot"
Which looks perfectly reasonable to me; the fastboot recipe also
builds without issue and the resulting package looks sane. So, why is
this breaking the SDK and causing other packages not to be installed,
it looks specifically like it nullifies the
packagegroup-cross-canadian-diffusion as that is what brings in
meta-environment and as such environment-setup-* which is what is
claimed to be missing on SDK extract.
I'm totally out of my depth now as on the surface everything looks OK.
Any input would be much appreciated.
Cheers,
Turns out it's one of the magic variables that requires an _append
rather than just a +=.
The example above turns out to be from my tests using _append and I
didn't realise it was different with just a plain +=.
To conclude, TOOLCHAIN_HOST_TASK += "nativesdk-package" will overwrite
TOOLCHAIN_HOST_TASK to just hold nativesdk-package, as such
nativesdk-packagegroup-sdk-host and
packagegroup-cross-canadian-diffusion won't be present anymore which
makes a whole lot of sense now. Using append, like so:
TOOLCHAIN_HOST_TASK_append += "nativesdk-fastboot"
Will give you the whole list and result in:
TOOLCHAIN_HOST_TASK="nativesdk-packagegroup-sdk-host
packagegroup-cross-canadian-diffusion nativesdk-fastboot"
Which is correct. Sorry for the noise; but just a heads up that I now
feel strongly that this should be in the Yocto Docs somewhere, there is
no mention of extending the SDK at all from what I could see and current
examples found online specify just a plain += is fine to use, which it
isn't.
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
