On Fri, 11 Mar 2011, Rainer Orth wrote: > 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.
Interesting - it works for me with both GNU ld and gold from binutils 2.21. > >> > 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. Yeah, of course - that's desirable. > >> 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. If that solution avoids 3) then yes, I'm fine with going that route. Both 1) and 2) are very desirable anyway. Thanks, Richard.
