package/binutils+elf2flt: fix for noMMU targets
Get series with b4
b4 am 20180527153510.GB2965@scaerVersions newest first
- v1 Latest0 of 2 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 2 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [Buildroot] [PATCH 0/2] package/binutils+elf2flt: fix for noMMU targets
Arnout, All,
On 2018-05-27 16:34 +0200, Arnout Vandecappelle spake thusly:
Quoted 10 lines · Yann E. MORIN
Quoted 4 lines
Hello All!
TL;DR: gcc gets confused by our symlinks trick that we use to fix the rpath handling. We replace symlinks with script wrappers instead.
So maybe, instead of laying hacks upon hacks, we should go back to the drawing
board on the rpath handling? I would feel a lot more comfortable if we could just fix fix-rpath instead of playing the whack-a-mole game of workarounds in packages.
Well, we're not really playing whack-a-mole, because the isue is only about packages that install hardlinks in two locations, because of the bin/TUPLE-foo and TUPLE/bin/foo "duplication".
The only ones doing such a thing AFAIK are binutils and elf2flt.
gcc installs hardlinks, but in the same directory. The tools it installs in a TUPLE-named directory are not hardlinks.
Quoted 4 lines
I don't see a full solution yet, but basically I think that we should
- detect when an executable has multiple hardlinks;
- detect if it has already been "fixed" in this fix-rpath run;
- if so, clone the file before fixing it proper.
What did you mean by "clone" in this context? Remove the hardlinks and replace them by a copy of the file?
Quoted 2 lines
The weak point is: if we clone, there may be some hardlinks that actually could
still be reused as hardlinks. So you'd have to detect them first.
Sorry, I don't follow you here. If we replaced hardlinks with actual copies, how come we'd still have hardlinks?
Quoted 3 lines
Alternatively we could consider that this is anyway only about the host tree,
which is normally the smallest of the three trees (when you exclude external toolchain). So maybe we should just always clone for the host tree.
I'm afraid that detecting hardlinks will not be cheap, even when we exclude staging/ (which is a sub-dir of host/) from the search...
Quoted 2 lines
I realize we're very close to the release, but I still think that always
cloning is probably the safest way to do it.
Do we envision other impacted packages? I don't think so. Really, binutils and elf2flt really seem to be the only two packages impacted by the problem.
That we missed the noMMU and elf2flt cases previously is just an oversight on our part...
Then. if I am wrong, we're still talking about only two packages for now, and they only break because of the ARC archtecture, for which we use bleeding-edge tools that require we have libfl.so. Two. Single. Packages. We've always refused to add infra when only very few packages were impacted.
Or were you suggesting that we do not add infra, but we replace the current two hacks (Thomas' symlinks or my script wrappers) by an actual copy, still just for binutils and elf2flt? In which case we would not loose time detecting hard-links in a generic way, obviously.
Regards,
Yann E. MORIN.
Quoted 44 lines
Regards,
ArnoutQuoted 33 lines
See the first commit for the whole story.
Fixes #11031.Regards,
Yann E. MORIN.The following changes since commit
2c57dc0469f7e32182932e5937f61f82b01a743acjson: bump to version 1.7.7 (2018-05-25 16:22:11 +0200)
are available in the git repository at:
git://git.buildroot.org/~ymorin/git/buildroot.gitfor you to fetch changes up to
59b3d35d7c805ebee29dc7185ea63e55aca768capackage/elf2flt: replace hard-links with script wrappers to fix rpath (2018-05-25 22:24:32 +0200)
----------------------------------------------------------------
Yann E. MORIN (2):
package/binutils: switch from symlinks to script wrappers package/elf2flt: replace hard-links with script wrappers to fix rpathpackage/binutils/binutils.mk | 9 ++++++--- package/elf2flt/elf2flt.mk | 17 +++++++++++++++++ 2 files changed, 23 insertions(+), 3 deletions(-)Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'