| Summary: | Cross-compiled binaries shouldn't be installed into staging | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | Gustavo Zacarias <gustavo> |
| Component: | Other | Assignee: | unassigned |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | buildroot |
| Priority: | P5 | ||
| Version: | unspecified | ||
| Target Milestone: | 2010.08 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Host: | i686-linux | Target: | arm-softfloat-linux-uclibcgnueabi |
| Build: | |||
| Attachments: |
Lua: don't install binaries into staging dir
Openssl: don't install openssl bin into staging e2fsprogs: Don't install binaries to staging |
||
Created attachment 1639 [details]
Openssl: don't install openssl bin into staging
Created attachment 1645 [details]
e2fsprogs: Don't install binaries to staging
As discussed on IRC (but I think it's better to raise my comments in Bugzilla or on the list), I don't really agree with such a change. Actually, I think we should do quite the opposite: install all binaries in $(STAGING_DIR)/bin and $(STAGING_DIR)/usr/bin. To me $(STAGING_DIR) should be a *superset* of $(TARGET_DIR). In $(STAGING_DIR), you should have everything: binaries compiled with debugging symbols, documentation, headers, all the mess. $(TARGET_DIR) is simply the result of filtering $(STAGING_DIR). Now, the point that was made on IRC is that this doesn't work if people add $(STAGING_DIR)/usr/bin to their PATH, because then their system would try to run binaries that are compiled for the target. My answer is that people shouldn't add $(STAGING_DIR)/usr/bin to the PATH. So, either : * We install the toolchain outside $(STAGING_DIR), so that we don't mix host binaries and target binaries in $(STAGING_DIR)/usr/bin * People refer to the toolchain inside $(STAGING_DIR)/usr/bin using absolute paths Of course, I'm open to discussion on having a different semantic for $(STAGING_DIR), but that's something that should really be raised on the list, to see how we solve the different problems. Peter, what do we do with this bug ? What are the actions points related to this bug for 2010.08 and post-2010.08 ? In http://buildroot.org/buildroot.html#using_toolchain we're still suggesting users to add $(STAGING_DIR) to their PATH. Possible proposals for 2010.08 : * Change the documentation to tell users to use absolute paths to the tools and to not add $(STAGING_DIR) to their PATH. * Create a new directory with wrappers for the toolchain tools, so that users can put this directory in their PATH. Choice ? Solved in git with the toolchain rework. |
Created attachment 1633 [details] Lua: don't install binaries into staging dir Some packages install cross-compiled binaries into the staging dir. This is wrong since they could predate host tools in the PATH and usually aren't host-executable anyway.