[PATCH] D32721: Accept archive files with no symbol table instad of warning on them.

[Davide Italiano via llvm-commits]

On Thu, May 4, 2017 at 4:12 PM, Sean Silva via llvm-commits
<llvm-commits at lists.llvm.org> wrote:
>
>
> On Thu, May 4, 2017 at 3:58 PM, Mehdi AMINI <joker.eph at gmail.com> wrote:
>>
>>
>>
>> 2017-05-04 15:50 GMT-07:00 Sean Silva <chisophugis at gmail.com>:
>>>
>>>
>>>
>>> On Wed, May 3, 2017 at 6:28 PM, Rui Ueyama via llvm-commits
>>> <llvm-commits at lists.llvm.org> wrote:
>>>>
>>>> On Wed, May 3, 2017 at 6:12 PM, Mehdi AMINI <joker.eph at gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> 2017-05-03 18:07 GMT-07:00 Rui Ueyama <ruiu at google.com>:
>>>>>>
>>>>>> On Wed, May 3, 2017 at 5:58 PM, Mehdi AMINI <joker.eph at gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Wed, May 3, 2017 at 5:51 PM Rui Ueyama <ruiu at google.com> wrote:
>>>>>>>>
>>>>>>>> On Wed, May 3, 2017 at 5:48 PM, Mehdi AMINI <joker.eph at gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, May 3, 2017 at 5:44 PM Rui Ueyama <ruiu at google.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On Wed, May 3, 2017 at 5:40 PM, Mehdi AMINI <joker.eph at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, May 3, 2017 at 5:26 PM Rui Ueyama <ruiu at google.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, May 3, 2017 at 5:13 PM, Mehdi AMINI
>>>>>>>>>>>> <joker.eph at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Clang is incrementally linking in a matter of a few seconds, so
>>>>>>>>>>>>> 0.5s to read the symbols is a double digit percentage of that.
>>>>>>>>>>>>> And there are over 50 binaries in LLVM, not just one.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> We do not support incremental linking,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm talking about ThinLTO incremental linking, which we support.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> How can that be faster than the regular build?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not sure what you mean: on my mac ld64 links clang in less than 2s.
>>>>>>>>
>>>>>>>>
>>>>>>>> But that is ld64. We are talking about LLD, no?
>>>>>>>
>>>>>>>
>>>>>>> I don't see where you're going: lld is supposed to be fast, isn't it?
>>>>>>> I assume it has to be able to outspeed ld64.
>>>>>>> So I'm giving you a reference of what is "a regular" build time and
>>>>>>> that should explain why you .5s overhead is not trivial.
>>>>>>
>>>>>>
>>>>>> That is hypothetical. If LLD is already able to link Clang with
>>>>>> ThinLTO in 2 seconds, it may make sense to warn on 0.5 second loss, but
>>>>>> that's in reality not the case, so I'm not convinced that we should warn on
>>>>>> it right now.
>>>>>
>>>>>
>>>>> I disagree: we should define what is a *correct* build setting, and
>>>>> warn if it is not honored.
>>>>> Your changing this definition here, and I doubt it'll be easy to revert
>>>>> in the future, which is why I don't like this.
>>>>
>>>>
>>>> That's a valid concern, and this change certainly relaxes the definition
>>>> what is correct (or at least what is not incorrect). But I still think that
>>>> that's beneficial for users overall. You are extremely familiar with LLVM
>>>> LTO, but ordinary developers don't know much about LLVM or build systems
>>>> compared to you. Attempting to use llvm-ar took a fair amount of time even
>>>> to me (which I hope better than the average Unix user). If we print out a
>>>> warning on every linker invocation, we'd probably be teaching users to
>>>> ignore warnings rather than let them change the build configuration, as it
>>>> just works with a marginal performance difference.
>>>
>>>
>>>
>>> In my experience (and mentioned in this thread too), changing the
>>> archiver is very difficult. One necessary requirement for emitting a warning
>>> is that it has to be actionable.
>>>
>>> For example, in CMake, I only know how to do it after looking at Rafael's
>>> https://github.com/espindola/llvm-scripts (and I have no idea how Rafael
>>> figured it out).
>>
>>
>> As a side note: this is suboptimal I believe, cmake has -DCMAKE_AR /
>> -DCMAKE_RANLIB options (just like -DCMAKE_C_COMPILER).
>
>
> IIRC, I've tried to use those and they didn't work. My memory is vague, but
> I think the issue was that CMAKE_AR and CMAKE_RANLIB were not propagated to
> all configuration checks, so that some of them spuriously failed because the
> CFLAGS had -flto but the CMAKE_AR/CMAKE_RANLIB was not being respected.
>

hmm, my memory is very fuzzy too but I remember self-hosting LLVM with
-DCMAKE_AR=myar -DCMAKE_RANLIB=/bin/true (and maybe setting -DCMAKE_NM
as well, but I'm not 100% sure). Everything went smoothly, but it's
been a while so things may have changed.

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare