[chromium] Use lipo(1) rather than file(1) to list library architectures.
Created attachment 190894 [details] Patch
japhet, You have no idea how sad this build failure made me. I will not, except under duress, tell you how much time I wasted trying to figure this out. WDYT? (of the patch, not my bad attitude)
Comment on attachment 190894 [details] Patch otool also works. nm might too. :)
japhet? seidel? Any chance at a review?
(In reply to comment #4) > japhet? seidel? > > Any chance at a review? Not it. I don't speak .sh well enough to review it.
Thanks for getting back to me japhet. I found you using blame on that file, I guess you'd reformatted it... I am aware of this curse. :D thakis or rsesek, can either of you review this?
Comment on attachment 190894 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=190894&action=review > Source/WebCore/ChangeLog:6 > + Parsing file(1) output can be fragile; this patch replaces a use of file(1) to get Which problem are you seeing?
(In reply to comment #7) > (From update of attachment 190894 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=190894&action=review > > > Source/WebCore/ChangeLog:6 > > + Parsing file(1) output can be fragile; this patch replaces a use of file(1) to get > > Which problem are you seeing? On my mac, I couldn't build Chromium. I have MacPorts, and the file(1) installed with that had incompatible output, which made ARCHS not get loaded correctly. Since the script already uses lipo(1) later, and since it can output the data that's being looked for, that seemed the way to go, rather than coding /usr/bin/file or adding a more flexible parser of file(1)'s output.
Comment on attachment 190894 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=190894&action=review >>> Source/WebCore/ChangeLog:6 >>> + Parsing file(1) output can be fragile; this patch replaces a use of file(1) to get >> >> Which problem are you seeing? > > On my mac, I couldn't build Chromium. I have MacPorts, and the file(1) installed with that had incompatible output, which made ARCHS not get loaded correctly. > > Since the script already uses lipo(1) later, and since it can output the data that's being looked for, that seemed the way to go, rather than coding /usr/bin/file or adding a more flexible parser of file(1)'s output. Hm, ok. MacPorts breaks other stuff too (see e.g. the thread on chromium-dev from yesterday night), but if you're happy with being on the hook if the output of lipo varies over time, I can live with this :-)
Comment on attachment 190894 [details] Patch Thanks Nico. If lipo changes, I assume I will be hearing about it quick fast.
Comment on attachment 190894 [details] Patch Clearing flags on attachment: 190894 Committed r145574: <http://trac.webkit.org/changeset/145574>
All reviewed patches have been landed. Closing bug.