omjavaid added inline comments. ================ Comment at: packages/Python/lldbsuite/test/make/Makefile.rules:304 @@ +303,3 @@ + $(subst $(3),$(1),$(2)), \ + $(if $(findstring ar,$(1)), \ + $(if $(findstring gcc,$(3)), \ ---------------- labath wrote: > I think like we should replace ar with gcc-ar always, and not just when we > don't have a version suffix present. When I have a gcc installed to a custom > prefix, I get `$prefix/gcc-ar`, but not `$prefix/ar`. (Previously we would > just use `ar` unconditionally, which was probably a bug.) > > Next, when you specify a clang compiler as `clang-3.5`, you will produce > `ar-3.5`, which almost certainly does not exist. I think that in case of > clang we should just strip the version suffix (produce `XXX-ar`) and hope for > the best (should work for all our current use cases). > > Finally, I don't think objcopy is ever versioned with gcc (correct me if I am > wrong), so I think that in case of objcopy we should strip the version suffix > unconditionally `XXX-objcopy`. > > So, to summarize, these are the transformations I think are wrong: > `foo/gcc` -> `foo/ar` (should be `foo/gcc-ar`) > `clang-3.5` -> `ar-3.5` (should be `ar`) > `gcc-4.8` -> `objcopy-4.8` (should be `objcopy`) > > Let me know if these are compatible with your requirements. If we can't find > a set of rules that work everywhere, we will have to abandon the magic (or > maybe just leave a simple one), and require the user to specify the paths > manually... I checked with gcc people in my team and here is what they have to say. omjavaid, gcc-ar is a version of ar with LTO support omjavaid, ar is just ar omjavaid, likewise with gcc-nm and gcc-ranlib omjavaid, ar comes from binutils, gcc-ar comes from gcc
I agree with all other points you raised except for using gcc-ar in all cases. We should decide between ar (binutils) or gcc-ar (LTO support gcc packaged). Also present code doesnt generate obcopy-4.8 for me when i specify gcc-4.8. If it does for you let me know. https://reviews.llvm.org/D20386 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
