[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

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at sourceware dot org   |nickc at redhat dot com
   Last reconfirmed|                            |2024-06-24

--- Comment #3 from Nick Clifton <nickc at redhat dot com> ---
Hi Harmen,

> That is the real problem: object local search paths for dependencies are
> transformed into global search paths in the bfd linker.

Agreed.  This is definitely the problem.

> Finally, consider the motivating example in the documentation
> https://sourceware.org/binutils/docs/ld/libdep-Plugin.html:
> 
> > For example, given a library libssl.a that depends on another library 
> > libcrypto.a which may be found in /usr/local/lib, the ‘__.LIBDEP’ member of 
> > libssl.a would contain
> >   -L/usr/local/lib -lcrypto
> 
> It is incredibly likely that `libssl.a` is in a default/system search path
> like /usr/lib. The wrong libssl.a will be linked and nobody will notice
> (unless it causes a linking failure, which is unlikely). It's highly
> unexpected from a user's perspective that the dependency is resolved to a
> path different from that specified in the archive, don't you agree?

I do.  And short of fixing the bfd linker's not-having-local-search-paths
issue, which I think might be hard to do, the only other idea I have is to add
a linker option to generate warning messages whenever a library can be found in
multiple locations, and to enable this option by default when a plugin uses the
set_extra_library_path() function.

Cheers
  Nick

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