Richard Guenther <rguent...@suse.de> writes:
>> Still doesn't work for me if compiling and linking manually with GNU ld
>> 2.21 on Solaris 11/x86: no .res file is being created, although
>> liblto_plugin.so is used.
>
> "Work" as in, it detects if -fuse-linker-plugin is enabled by default.
> Which it isn't for you?
I'm using gld 2.21, and -flto automatically uses the linker plugin, as
seen with -v. Despite that, -plugin-opt=-fresolution=ldl.res is passed
to collect2/ld, but no ldl.res file is created. In truss, I see a stat
of that file, but nothing more.
>> > Eventually scanning -v output for '-plugin' is better.
>>
>> This can only work if we make sure that -plugin is only passed to
>> linkers that properly handle it.
>
> Sure, but your version check patch part would ensure that, if not
> overridden by -fuse-linker-plugin.
No, -fuse-linker-plugin wouldn't override here: that option is only
accepted if we know that the linker has *some* -plugin support.
>> Why do you say so? The tri-state solution I've outlined only disables it
>> completely for non-GNU linkers. The plugin is used automatically for
>> gld/gold 2.21+ and for gold 2.20* if -fuse-linker-plugin is given.
>>
>> I don't see the `almost everyone' here, on the contrary: the situation
>> is identical to what we have now, with the exception that we don't try
>> to pass -plugin to linkers we don't know they can somehow (even with
>> restrictions) handle it. That's what PR lto/46944 is primarily about.
>
> Can you update your patch with the tri-state solution?
Sure if the solution is deemed acceptable. There isn't much point in
following that route if you see problems up front.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
