Hi Omar,
On Wed, 2019-07-03 at 13:03 -0700, Omar Sandoval wrote:
> I'm developing an application which uses libdwfl. When I tested it in
> our production environment, the application hit DWARF parsing errors for
> Linux kernel modules. I tracked it down to an issue that ELF relocations
> were sile
On Wed, 2019-07-03 at 20:56 -0400, Frank Ch. Eigler wrote:
> > Some of the binaries use libebl, and although libebl is linked into
> > libdw.so,
> > the libebl symbols are not exported by libdw. So, libebl is linked in
> > statically for the binaries.
> >
> > This is why I suggested exporting tho
On Mon, Jul 08, 2019 at 10:48:52PM +0200, Mark Wielaard wrote:
> On Wed, 2019-07-03 at 20:56 -0400, Frank Ch. Eigler wrote:
> > > Some of the binaries use libebl, and although libebl is linked into
> > > libdw.so,
> > > the libebl symbols are not exported by libdw. So, libebl is linked in
> > > st
Hi,
On Fri, 2019-07-05 at 17:34 -0700, Omar Sandoval wrote:
> The main downside of the previous change to build in all libebl backend
> modules statically is that the total installed size of elfutils
> increased (from 2.1 MB to 3.5 MB in my case). This is because we have to
> statically link libeb
* Omar Sandoval:
> This makes sense. One thing I noted in the patch to export the libebl
> symbols [1] is that exporting them wouldn't necessarily mean supporting
> them as an official API. However, I can see why you'd be concerned with
> developers using them anyways.
You could ship a link-only
