| Summary: | SDKTARGETSYSROOT and the other variables don't automatically get updated when OVERRIDES updates. | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Meta-yocto | Reporter: | Angel Petkov <apetkov86> |
| Component: | meta-yocto | Assignee: | Richard Purdie <richard.purdie> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | poky.bs.watcher, poky.watcher |
| Version: | 2.0.3 | ||
| Target Milestone: | 2.3 | ||
| Hardware: | x86 | ||
| OS: | x86_64 | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
I've spent a while looking at this and as far as I can tell the system is behaving as designed/intended.
We did rework the way the datastore works so that values are always applied dynamically and that there is no longer any need to call update_data() and that likely happened somewhere between fido and jethro.
The code you point at is deliberately avoiding certain kinds of expansion:
localdata.setVar('SDKTARGETSYSROOT', d.getVar('SDKTARGETSYSROOT', True))
This means it takes the value of SDKTARGETSYSROOT and inserts it into the other data store and in the process will clear any overrides queued against the variable, forcing it to this value.
So I do believe the code is behaving as intended.
What you don't say in this bug report is what problem this causes you, or what kind of problem this causes. If you believe there is still a problem, more details about what that problem looks like would be helpful. Our automated SDK tests for example pass just fine, even for multilib SDKs.
I'm sorry that I missed to point out what kind of problem I believe this causes...
After deploying the SDK, there are two environment setup scripts produced:
- environment-setup-aarch64-poky-linux
- environment-setup-armv7ahf-vfp-pokymllib32-linux-gnueabi
The first one should export SDKTARGETSYSROOT variable to:
"<some_path>/sysroots/aarch64-poky-linux"
And the second one (for Multilib) to:
"<some_path>/sysroots/aarch64-pokymllib32-linux"
At least that was the actual result when I used the old poky version (from fido branch) so I think this is the correct behavior.
When I used the new version (from jethro branch), SDKTARGETSYSROOT in both scripts was set to "<some_path>/sysroots/aarch64-poky-linux".
The problem arose then I tried to build a 32-bit application, thus exporting 'environment-setup-armv7ahf-vfp-pokymllib32-linux-gnueabi'. There was maybe some library ( if I remember correctly) that was present in the 32-bit sysroot but not in the 64-bit sysroot. As a result, the build failed. After I manually set the correct value for SDKTARGETSYSROOT ("<some_path>/sysroots/aarch64-pokymllib32-linux"), the building process went on smoothly.
Let me know if you need additional information.
Potentially a multilib SDK environment issue (but not a datastore one) (In reply to comment #2) > I'm sorry that I missed to point out what kind of problem I believe this > causes... > > After deploying the SDK, there are two environment setup scripts produced: > - environment-setup-aarch64-poky-linux > - environment-setup-armv7ahf-vfp-pokymllib32-linux-gnueabi > > The first one should export SDKTARGETSYSROOT variable to: > "<some_path>/sysroots/aarch64-poky-linux" > And the second one (for Multilib) to: > "<some_path>/sysroots/aarch64-pokymllib32-linux" > > At least that was the actual result when I used the old poky version (from > fido branch) so I think this is the correct behavior. > > When I used the new version (from jethro branch), SDKTARGETSYSROOT in both > scripts was set to "<some_path>/sysroots/aarch64-poky-linux". > > The problem arose then I tried to build a 32-bit application, thus exporting > 'environment-setup-armv7ahf-vfp-pokymllib32-linux-gnueabi'. There was maybe > some library ( if I remember correctly) that was present in the 32-bit > sysroot but not in the 64-bit sysroot. As a result, the build failed. After > I manually set the correct value for SDKTARGETSYSROOT > ("<some_path>/sysroots/aarch64-pokymllib32-linux"), the building process > went on smoothly. > > Let me know if you need additional information. Thanks, this was helpful. I tried building a multilib sdk for arm with master and it breaks with overlapping files in the sysroot. The intend of the recent changes in the codebase is that there should be one sysroot in multilib configurations, not two. I've written some patches which fix up arm multilib and allow things to work on master with a single sysroot as designed. Once those are merged, I will likely mark this as resolved as things are working with master. I'm not sure what our options are for the older releases, it depends whether anyone steps up to handle backporting and testing of the fixes I guess. As discussed, multilib arm SDKs now work after http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=6897b33abe7bd0a186db64a1969991b3ec3e387a |
The problem occurred when updating from one Poky version to another: - old-version - branch: fido, version fa55b8e5050c6d7a47ef8e9bc213d0cc9471b43a - new-version - branch: jethro, version 40376446904ae3529be41737fed9a0b650ed167d The actual problem arises when deploying an SDK. The specific file where this happens is: poky/meta/recipes-core/meta/meta-environment.bb Expected result: When OVERRIDES is appended with a valid override for SDKTARGETSYSROOT, the latter variable should be updated with the more specific value (defined with the override) Actual result: OVERRIDES is appended with a valid override for SDKTARGETSYSROOT, but the latter variable does NOT change its value. Additional Information: In the old version, there was the following call that did the job: bb.data.update_data(localdata) From some point between the old and the new version mentioned, this call have been made not operational and the same functionality is somehow handled internally. However, it seems that when the variable (in this case SDKTARGETSYSROOT) is explicitly set by the following statement (in meta-environment.bb) , it is no longer affected by this mechanism: # make sure we only use the SDKTARGETSYSROOT value from 'd' localdata.setVar('SDKTARGETSYSROOT', d.getVar('SDKTARGETSYSROOT', True)) If the same line is commented out, the behavior is as expected (OVERRIDES is updated and so is SDKTARGETSYSROOT). Situation is the same with the other variables manipulated in the file - WORKDIR, libdir. I suppose this is a general issue and is not limited to only this specific file. Tested also with 45df694a9f472ac2f684aadac4d864c3dfdc48a7 version from master branch and issue is still reproducible. Tested on: Virtual machine with Ubuntu 14.04.4 LTS, Trusty Tahr, kernel: Linux 4.2.0-27-generic