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,
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
