[Bug ld/31904] libdep.so plugin registers search path after default paths in bfd linker

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31904

--- Comment #9 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Harmen Stoppels from comment #8)

> I appreciate the patch. Would an additional
> `ld_plugin_remove_extra_library_path(const char *path)` be possible so that
> 
> > This does however present a problem if multiple archives with 
> > @samp{__.LIBDEP} entries are present as they will all be handled by the 
> > libdep plugin and thus they will share library search paths.  This could 
> > result in a library being loaded from an unexpected location.
> 
> can be removed from the documentation?

Yes, but I do not think that it would work.  The problem is that the search
paths and archive filenames are added to lists inside the linker by the plugin
calls to set_extra_library_path() and add_input_library() but these lists are
not scanned until later.  So we would still end up with the potential for
multiple library search paths being recorded by the plugin but not being
actually used until the archives are
loaded later on.


> My only worry with the patch is that if libdep.so proves useful, and it
> would ever be promoted to a builtin flag `ld --resolve-static-deps` or even
> enabled by default, then `enum search_dir_source` may be hard to remove even
> though it's effectively unused.

I think that it is useful/needed.  At least for now.

I am going to go ahead and apply the patch.  If we need to make improvements or
changes we can always do so in the future.

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.