-
- Downloads
keg_relocate: work around `file` bug
There's an old bug in `file` which means it can't read certain files under a non-C locale. This has been fixed upstream for some time, but Apple hasn't picked that fix up & even on OS X El Capitan the `file` is ancient. This is currently causing a lot of false positives in our bottle code around relocating things like manpages translated into non-English languages, because currently the test does: ``` pn = "/usr/local/Cellar/vim/7.4.2109/share/man/fr/man1/vim.1" Utils.popen_read("/usr/bin/file", "--brief", pn).include?("text") ``` Which returns `false`. But it isn't returning `false` because the actual result is false, but because `file` panics & fails, which for us equals a `false`. The actual output when accessed is: ``` pn = "/usr/local/Cellar/vim/7.4.2109/share/man/fr/man1/vim.1" Utils.popen_read("/usr/bin/file", "--brief", pn) "ERROR: line 22: regexec error 17, (illegal byte sequence)\n" ``` Forcing this check to be done under a "C" locale eliminates this particular false positive for strings we can't relocate & consequently things such as NLS may prove to be more portable in some formulae than is currently the case. Using `vim` again for the example: ``` pn = "/usr/local/Cellar/vim/7.4.2109/share/man/fr/man1/vim.1" Utils.popen_read("/usr/bin/file", "--brief", pn).include?("text") true ``` This reduces the flagged strings from `vim` from 4 issues to 2, the remaining two with the `vim` executable itself which "remembers" the full path to perl, python, ruby, etc during build & vomits that information out when requested by the user. Both the manpages flagged before this change are no longer flagged as unrelocatable. This won't entirely resolve the NLS problem because some things hardcode in a locale path, which will be stored in the executable, but at the very least it should reduce the number of false positives & may enable relocation where that locale path hasn't been burnt in.
Please register or sign in to comment