https://sourceware.org/bugzilla/show_bug.cgi?id=30577
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Nick Clifton from comment #1) > (In reply to Richard Biener from comment #0) > Hi Richard, > > > There is no documented way to disable plugin auto-loading from BFD for tools > > like NM and AR but this also affects LD. > > True... > > > By inspecting the source I can see that for AR at least --plugin="" works > > This should also work for NM, but not for LD. > > > but there is no --no-plugin > > I am tempted to suggest that we document --plugin="" as doing this, > and make sure that LD supports it as well. That would mean the least > disruption to the sources. (Except see below for a different approach...) I guess that's a good idea independently of what we do in addition to that. > > or any way to for example override the > > search directory in the environment. > > Again true. I dislike having a hard-coded directory in the sources, > so having a way to set it dynamically would be good. I am very wary > of using an environment variable to do this however as it makes > debugging plugin problems very hard. Very few bug reports include > a list of environment variables, and it is easy to imagine that a > user unfamiliar with the binutils plugin code would not even realise > that the problem might be due to a plugin being loaded from an > unexpected location because of an environment variable. Yeah - the issue that made me report this is exactly a bugreport about NM giving odd complaints on a specific archive where the issue was some unrelated installed (buggy) plugin in the BFD auto-load directory ... Still having an environment one can set allows central control to have customer scripts "isolated" from stuff installed in the auto-load directory. At the same time it can introduce these issues of course. > So instead I would suggest adding a --plugin-dir=<DIR> option which > could be used to override the builtin default. It could even support > --plugin-dir=NUL to stop any auto-loading and --plugin-dir=DEFAULT > to reset the search directory back to the builtin default. > > What do you think ? --plugin-dir sounds useful (as does the environment), since we implement "first found and matching wins" a --plugin-add-dir is probably less useful (you'd expect a match in the specified dir). I think it would be nice to be able to set the default behavior to --plugin-dir=NUL while still enabling plugin support in general. (not sure about configuring a different non-NUL default) Clearly a documented and consistently working --plugin="" is the most important thing. > Cheers > Nick -- You are receiving this mail because: You are on the CC list for the bug.