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.
