On demand static/shared libs and binary linkage

On demand static/shared libs and binary linkage

[Laurent Stacul]

Hello,

I am quite new on elfutils library. I know their were discussions in
the past about the question I will ask but let me introduce my use
case.

I am working on a project which aims at building some kind of
"standalone" toolchain (binutils, gcc, clang + tools like gdb,
valgrind). This toolchain could be shipped easily on any linux
machines by copying files on the targeted machine.

To ease this, the tools binaries are statically linked to avoid any
interferences with user local LD_LIBRARY_PATH environment variable.

I am planning to add elfutils to this toolchain. The provided binaries
are useful and the delivered libs are a prerequisite for libabigail
(which I plan to also add).

I can see there is no flag to chose between static and shared.

From my investigations in the code and the build system:

- the delivered libs cannot be 100% static archives. Depending on the
machine the libelf is used, some backend code are dlopen'd. So at
least, the backends code must be delivered as shared lib (in the by
default EBL directory)

- the delivered binaries are by default dynamically linked except if
the gcov or gprof support is enabled.

I was wondering if it would be a good idea (or even possible) to have
two options in the configure script, for instance, --enable-static and
--enable-shared, which would be set to "yes" by default.

In the case --enable-shared=no, no dso is generated (except the
backends) and the binaries are statically linked.
In the case --enable-static=no, only the dso are generated and
binaries are dynamically linked.
The combination --enable-shared=no and --enable-dynamic=no is impossible.

Finally if the gcov or gprof support is required, we force the current
behaviour (ie. --enable-shared=yes and --enable-static=yes).

Can you give me your feed back on such a proposal ? If it is worth
working on this, I can try to provide a patch.

Regarding the project I am working on, I have a workaround which does
not satisfy me:
- build zlib shared lib
- build elfutils with gcov support

Thanks in advance,
Laurent Stacul

Re: On demand static/shared libs and binary linkage

[Ulf Hermann]

Hi,

> - the delivered libs cannot be 100% static archives. Depending on the
> machine the libelf is used, some backend code are dlopen'd. So at
> least, the backends code must be delivered as shared lib (in the by
> default EBL directory)

The backends are for libdw, not libelf, and they are not about the 
machine you are _running_ this on, but about the machine the binaries 
you are looking at were compiled for. The dlopen is not technically 
necessary. We could just compile all the backends into libdw. The 
backend interface is private API and therefore you shouldn't use 
"external" backends anyway. The downside would be that libdw gets 
bigger, but the upside of not having to deal with dlopen and rpath would 
be easily worth it, at least for my use case.

This has been on my wish list for a while, but I haven't gotten around 
to do it, yet.

Ulf

Re: On demand static/shared libs and binary linkage

[Laurent Stacul]

Understood.

In this case, there are 2 solutions:

- we completely remove the call to dlopen
- we keep the call to dlopen from the shared lib version of libdw and
embed all the backends code in the archive

I don't know if the second solution is worth the additional
work/complexity. What do you think ?

Laurent

Re: On demand static/shared libs and binary linkage

[Mark Wielaard]

On Thu, Jun 07, 2018 at 03:59:22PM +0200, Laurent Stacul wrote:
> Understood.
> 
> In this case, there are 2 solutions:
> 
> - we completely remove the call to dlopen
> - we keep the call to dlopen from the shared lib version of libdw and
> embed all the backends code in the archive
> 
> I don't know if the second solution is worth the additional
> work/complexity. What do you think ?

I kind of did the first on the mjw/RH-DTS branch. Which just has
the backends for the architectures that RHEL officially supports.

But I don't really like it. Ideally I would like to have a configure
option to say which backends need to be linked in directly and keep
the rest dynamic using dlopen. We could then default to include the
native backend (and maybe related sub-archies, like x86_64 plus i386).
But still build and ship the rest as shared libraries that can be
dlopened on demand.

One extra issue is that dlopen code (and libebl in general) has pretty
bad error handling. If we clean up this code it would be nice to get
a better error mechanism for when a backend cannot be found.

Cheers,

Mark