Charles Wilson wrote:
I'd still like to be able to build my convenience library as both pic
and non-pic tho. And I still want to prevent libiberty.a(non-pic) from
getting the --whole-archive treatment when it comes to libbfd.a.
...
Several systems simply don't allow to mix PIC and non-PIC
Ralf Wildenhues wrote:
Here's a review based on the question how such a concept could be
expressed portably. I don't see how something like this would be of
great help if it could not be made to gracefully decay into something
still usable, on at least a useful set of platforms if not all of
Charles Wilson wrote:
I completely understand the motivation for the meat of this, speaking in
the hypothetical sense, but why would you ever want to build libbfd
shared?
I did --enable-shared at the top level, and bfd is the first one that
failed. I'm really more interested in the runtime
Hello Charles,
Here's a review based on the question how such a concept could be
expressed portably. I don't see how something like this would be of
great help if it could not be made to gracefully decay into something
still usable, on at least a useful set of platforms if not all of them.
*
Charles Wilson wrote:
I have a library that I want to build shared (let's call it libbfd).
It depends on a portability library that is currently built as a
non-libtool, static library (let's call it libiberty). g
I completely understand the motivation for the meat of this, speaking in
the
