bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
diff --git a/bfd/configure.ac b/bfd/configure.ac
|
2021-08-20 20:40:52 +00:00
|
|
|
index fec067b2135..377e1f5443f 100644
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
--- a/bfd/configure.ac
|
|
|
|
|
+++ b/bfd/configure.ac
|
2021-08-20 20:40:52 +00:00
|
|
|
@@ -292,30 +292,16 @@ AC_CACHE_CHECK(linker --as-needed support, bfd_cv_ld_as_needed,
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
|
|
|
|
|
LT_LIB_M
|
|
|
|
|
|
|
|
|
|
-# When building a shared libbfd, link against the pic version of libiberty
|
|
|
|
|
-# so that apps that use libbfd won't need libiberty just to satisfy any
|
|
|
|
|
-# libbfd references.
|
|
|
|
|
-# We can't do that if a pic libiberty is unavailable since including non-pic
|
|
|
|
|
-# code would insert text relocations into libbfd.
|
|
|
|
|
SHARED_LIBADD=
|
|
|
|
|
-SHARED_LDFLAGS=
|
|
|
|
|
+SHARED_LDFLAGS=-liberty
|
|
|
|
|
if test "$enable_shared" = "yes"; then
|
|
|
|
|
-changequote(,)dnl
|
|
|
|
|
- x=`sed -n -e 's/^[ ]*PICFLAG[ ]*=[ ]*//p' < ../libiberty/Makefile | sed -n '$p'`
|
|
|
|
|
-changequote([,])dnl
|
|
|
|
|
- if test -n "$x"; then
|
|
|
|
|
- SHARED_LIBADD="-L`pwd`/../libiberty/pic -liberty"
|
|
|
|
|
- fi
|
2021-08-20 20:40:52 +00:00
|
|
|
-fi
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
-
|
2021-08-20 20:40:52 +00:00
|
|
|
SHARED_LIBADD="$SHARED_LIBADD $LIBINTL"
|
|
|
|
|
|
|
|
|
|
-if test "$enable_shared" = "yes"; then
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
case "${host}" in
|
2020-06-08 21:02:54 +00:00
|
|
|
# More hacks to build DLLs on Windows.
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
*-*-cygwin*)
|
|
|
|
|
SHARED_LDFLAGS="-no-undefined"
|
2021-08-20 20:40:52 +00:00
|
|
|
- SHARED_LIBADD="-L`pwd`/../libiberty -liberty $SHARED_LIBADD -lcygwin -lkernel32"
|
|
|
|
|
+ SHARED_LIBADD="-liberty $SHARED_LIBADD -lcygwin -lkernel32"
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
|
|
|
|
|
diff --git a/opcodes/Makefile.am b/opcodes/Makefile.am
|
2021-08-20 20:40:52 +00:00
|
|
|
index 0e04b4c05c4..848a02662e7 100644
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
--- a/opcodes/Makefile.am
|
|
|
|
|
+++ b/opcodes/Makefile.am
|
2020-06-08 21:02:54 +00:00
|
|
|
@@ -51,7 +51,7 @@ libopcodes_la_LDFLAGS += -rpath $(rpath_bfdlibdir)
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# This is where bfd.h lives.
|
|
|
|
|
-BFD_H = ../bfd/bfd.h
|
|
|
|
|
+BFD_H = $(BFDDIR)/bfd.h
|
|
|
|
|
|
|
|
|
|
BUILD_LIBS = @BUILD_LIBS@
|
|
|
|
|
BUILD_LIB_DEPS = @BUILD_LIB_DEPS@
|
2021-08-20 20:40:52 +00:00
|
|
|
@@ -303,7 +303,7 @@ OFILES = @BFD_MACHINES@
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
# development.sh is used to determine -Werror default.
|
|
|
|
|
CONFIG_STATUS_DEPENDENCIES = $(BFDDIR)/development.sh
|
|
|
|
|
|
|
|
|
|
-AM_CPPFLAGS = -I. -I$(srcdir) -I../bfd -I$(INCDIR) -I$(BFDDIR) @HDEFINES@ @INCINTL@
|
|
|
|
|
+AM_CPPFLAGS = -I. -I$(srcdir) -I$(INCDIR) -I$(BFDDIR) @HDEFINES@ @INCINTL@
|
|
|
|
|
|
|
|
|
|
disassemble.lo: disassemble.c
|
|
|
|
|
if am__fastdepCC
|
2022-02-13 14:15:56 +00:00
|
|
|
@@ -327,9 +327,18 @@ libopcodes_la_SOURCES = dis-buf.c disassemble.c dis-init.c
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
-libopcodes_la_DEPENDENCIES = $(OFILES) @SHARED_DEPENDENCIES@
|
|
|
|
|
+libopcodes_la_DEPENDENCIES = $(OFILES) @SHARED_DEPENDENCIES@ libtool-soversion
|
|
|
|
|
libopcodes_la_LIBADD = $(OFILES) @SHARED_LIBADD@
|
|
|
|
|
-libopcodes_la_LDFLAGS += -release `cat ../bfd/libtool-soversion` @SHARED_LDFLAGS@
|
|
|
|
|
+libopcodes_la_LDFLAGS += -release `cat libtool-soversion` @SHARED_LDFLAGS@
|
|
|
|
|
# Allow dependency tracking to work on all the source files.
|
|
|
|
|
EXTRA_libopcodes_la_SOURCES = $(LIBOPCODES_CFILES)
|
|
|
|
|
|
|
|
|
|
+libtool-soversion:
|
|
|
|
|
+ @echo "creating $@"
|
|
|
|
|
+ bfd_soversion="$(VERSION)" ;\
|
|
|
|
|
+ . $(BFDDIR)/development.sh ;\
|
|
|
|
|
+ if test "$$development" = true ; then \
|
|
|
|
|
+ bfd_soversion="$(VERSION).$${bfd_version_date}" ;\
|
|
|
|
|
+ fi ;\
|
|
|
|
|
+ echo "$${bfd_soversion}" > $@
|
|
|
|
|
+
|
|
|
|
|
# libtool will build .libs/libopcodes.a. We create libopcodes.a in
|
|
|
|
|
# the build directory so that we don't have to convert all the
|
|
|
|
|
# programs that use libopcodes.a simultaneously. This is a hack which
|
|
|
|
|
diff --git a/opcodes/configure.ac b/opcodes/configure.ac
|
2021-08-20 20:40:52 +00:00
|
|
|
index e564f067334..5da62a3d58b 100644
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
--- a/opcodes/configure.ac
|
|
|
|
|
+++ b/opcodes/configure.ac
|
2022-02-13 14:15:56 +00:00
|
|
|
@@ -98,6 +98,8 @@ BFD_64_BIT
|
2021-08-20 20:40:52 +00:00
|
|
|
AC_SUBST(HDEFINES)
|
|
|
|
|
AC_PROG_INSTALL
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
|
|
|
|
|
+GCC_HEADER_STDINT(bfd_stdint.h)
|
2021-08-20 20:40:52 +00:00
|
|
|
+
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
AC_CHECK_DECLS([basename, stpcpy])
|
|
|
|
|
|
2021-08-20 20:40:52 +00:00
|
|
|
# Check if sigsetjmp is available. Using AC_CHECK_FUNCS won't do
|
2022-02-13 14:15:56 +00:00
|
|
|
@@ -148,44 +150,21 @@ AC_CACHE_CHECK(linker --as-needed support, bfd_cv_ld_as_needed,
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
|
|
|
|
|
LT_LIB_M
|
|
|
|
|
|
|
|
|
|
-#Libs for generator progs
|
|
|
|
|
-if test "x$cross_compiling" = "xno"; then
|
|
|
|
|
- BUILD_LIBS=../libiberty/libiberty.a
|
|
|
|
|
- BUILD_LIB_DEPS=$BUILD_LIBS
|
|
|
|
|
-else
|
|
|
|
|
- # if cross-compiling, assume that the system provides -liberty
|
|
|
|
|
- # and that the version is compatible with new headers.
|
|
|
|
|
- BUILD_LIBS=-liberty
|
|
|
|
|
- BUILD_LIB_DEPS=
|
|
|
|
|
-fi
|
|
|
|
|
-BUILD_LIBS="$BUILD_LIBS $LIBINTL"
|
|
|
|
|
-BUILD_LIB_DEPS="$BUILD_LIB_DEPS $LIBINTL_DEP"
|
|
|
|
|
+BUILD_LIBS="-liberty $LIBINTL"
|
|
|
|
|
+BUILD_LIB_DEPS="$LIBINTL_DEP"
|
|
|
|
|
|
|
|
|
|
AC_SUBST(BUILD_LIBS)
|
|
|
|
|
AC_SUBST(BUILD_LIB_DEPS)
|
|
|
|
|
|
|
|
|
|
# Horrible hacks to build DLLs on Windows and a shared library elsewhere.
|
|
|
|
|
SHARED_LDFLAGS=
|
|
|
|
|
-SHARED_LIBADD=
|
|
|
|
|
+SHARED_LIBADD=-liberty
|
|
|
|
|
SHARED_DEPENDENCIES=
|
2021-08-20 20:40:52 +00:00
|
|
|
-if test "$enable_shared" = "yes"; then
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
-# When building a shared libopcodes, link against the pic version of libiberty
|
|
|
|
|
-# so that apps that use libopcodes won't need libiberty just to satisfy any
|
|
|
|
|
-# libopcodes references.
|
|
|
|
|
-# We can't do that if a pic libiberty is unavailable since including non-pic
|
|
|
|
|
-# code would insert text relocations into libopcodes.
|
|
|
|
|
# Note that linking against libbfd as we do here, which is itself linked
|
|
|
|
|
# against libiberty, may not satisfy all the libopcodes libiberty references
|
|
|
|
|
# since libbfd may not pull in the entirety of libiberty.
|
2021-08-20 20:40:52 +00:00
|
|
|
# Also, jam libintl into the right place in all of this: after libiberty,
|
|
|
|
|
# which uses it, but before -lcygwin, which it uses.
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
-changequote(,)dnl
|
|
|
|
|
- x=`sed -n -e 's/^[ ]*PICFLAG[ ]*=[ ]*//p' < ../libiberty/Makefile | sed -n '$p'`
|
|
|
|
|
-changequote([,])dnl
|
|
|
|
|
- if test -n "$x"; then
|
|
|
|
|
- SHARED_LIBADD="-L`pwd`/../libiberty/pic -liberty"
|
|
|
|
|
- fi
|
2021-08-20 20:40:52 +00:00
|
|
|
-fi
|
2022-02-13 14:15:56 +00:00
|
|
|
|
2021-08-20 20:40:52 +00:00
|
|
|
SHARED_LIBADD="$SHARED_LIBADD $LIBINTL"
|
|
|
|
|
|
2022-02-13 14:15:56 +00:00
|
|
|
@@ -193,11 +172,10 @@ if test "$enable_shared" = "yes"; then
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
case "${host}" in
|
|
|
|
|
*-*-cygwin*)
|
|
|
|
|
SHARED_LDFLAGS="-no-undefined"
|
2021-08-20 20:40:52 +00:00
|
|
|
- SHARED_LIBADD="-L`pwd`/../bfd -lbfd -L`pwd`/../libiberty -liberty $SHARED_LIBADD"
|
|
|
|
|
+ SHARED_LIBADD="-lbfd -liberty $SHARED_LIBADD"
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
;;
|
|
|
|
|
*)
|
2022-02-13 14:15:56 +00:00
|
|
|
- SHARED_LIBADD="../bfd/libbfd.la ${SHARED_LIBADD}"
|
bfd, opcodes: Init separate derivations for binutils libraries
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
2017-10-10 22:48:42 +00:00
|
|
|
- SHARED_DEPENDENCIES="../bfd/libbfd.la"
|
|
|
|
|
+ SHARED_LIBADD="-lbfd ${SHARED_LIBADD}"
|
|
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
|