Sergei Trofimovich
e1ef521cff
A few potentially disruptive changes:
- binutils does not embed ${binutils-unwrapped}/lib as a default library
search path anymore. This will cause link failures for -lbfd -lopcodes
users that did not declare their dependency on those libraries. They
will need to add `libbfd` and `libopcodes` attributes to build inputs.
- `libbfd` and `libopcodes` attributes now just reference
`binutils-unwrapped.{dev,lib}` pair of attributes without patching
`binutils` build system.
We don't patch build system anymore and use multiple outputs out of
existing `binutils` build. That makes the result more maintainable: no
need to handle ever growing list of dependencied of `libbfd`. This time
new addition was `libsframe`.
To accomodate `out` / `lib` output split I had to remove `lib` -> `bin`
backreference by removing legacy lookup path for plugins.
I also did not enable `zstd` just yet as `nixpkgs` version of `zstd`
package pulls in `cmake` into bootstrap sequence.
Changes: https://lists.gnu.org/archive/html/info-gnu/2023-01/msg00003.html
26 lines
899 B
Diff
26 lines
899 B
Diff
Avoid `lib -> out -> lib` reference. Normally `bfd-plugins` does not
|
|
need to know binutils' BINDIR at all. It's an absolute path where
|
|
libraries are stored.
|
|
--- a/bfd/plugin.c
|
|
+++ b/bfd/plugin.c
|
|
@@ -493,7 +493,7 @@ build_plugin_list (bfd *abfd)
|
|
when configuring binutils using --libdir. Search in the proper
|
|
path first, then the old one for backwards compatibility. */
|
|
static const char *path[]
|
|
- = { LIBDIR "/bfd-plugins", BINDIR "/../lib/bfd-plugins" };
|
|
+ = { LIBDIR "/bfd-plugins", };
|
|
struct stat last_st;
|
|
unsigned int i;
|
|
|
|
@@ -508,9 +508,7 @@ build_plugin_list (bfd *abfd)
|
|
last_st.st_ino = 0;
|
|
for (i = 0; i < sizeof (path) / sizeof (path[0]); i++)
|
|
{
|
|
- char *plugin_dir = make_relative_prefix (plugin_program_name,
|
|
- BINDIR,
|
|
- path[i]);
|
|
+ char *plugin_dir = xstrdup (path[i]);
|
|
if (plugin_dir)
|
|
{
|
|
struct stat st;
|