building static libs

building static libs

[Paul Smith]

Hi all; sorry for the lack of more details on my coredumper library
issue.  I am underwater with other things but I will definitely get
back to that, hopefully next week.

In the meantime I have a question: has anyone done any work to get the
--{enable/disable}-{shared/static} configure options working with
elfutils?

I'd like to build, just as an example, libdebuginfod as ONLY a static
library and link it statically with debuginfod, gdb, etc.

Many autoconf projects accept options like --disable-shared along with
--enable-static to get that kind of configuration.  It seems that
elfutils will always build both static and shared libraries, but it
only installs the shared library.  And of course if both exist the
linker will always choose shared (unless you add extra options).

I see that there's some support for shared vs. static but it doesn't
seem choose-able by the user.

Re: ** POTENTIAL FRAUD ALERT - RED HAT ** building static libs

[Frank Ch. Eigler]

Hi -


> I'd like to build, just as an example, libdebuginfod as ONLY a static
> library and link it statically with debuginfod, gdb, etc.

libdebuginfod relies on a bunch of other libraries (curl and all of
its dependencies), so a libdebuginfod.a is unlikely to buy you much.

OTOH, libtool is one way to arrange building both .a and .so's from
such libraries, and propagate dependencies via the .la files.

- FChE

Re: ** POTENTIAL FRAUD ALERT - RED HAT ** building static libs

[Paul Smith]

On Sat, 2020-10-31 at 15:52 -0400, Frank Ch. Eigler wrote:
> > I'd like to build, just as an example, libdebuginfod as ONLY a
> > static library and link it statically with debuginfod, gdb, etc.
> 
> libdebuginfod relies on a bunch of other libraries (curl and all of
> its dependencies), so a libdebuginfod.a is unlikely to buy you much.

Oh, I'm aware :).

I have all those other libraries built statically as well... they're
pretty easy to build that way actually.

I'm already statically linking libdebuginfod.a with GDB, along with
curl et.al.

But to do it, I need to build elfutils then reach into the build
directory and pluck out the static library and copy it somewhere else
then tell GDB to look there instead.

And, I have no solution for building the debuginfod server itself
statically.

> OTOH, libtool is one way to arrange building both .a and .so's from
> such libraries, and propagate dependencies via the .la files.

Well, I've had pretty much nothing but problems with libtool TBH, in
terms of trying to generate general-purpose, relocatable libraries.  In
my experience the libtool solutions always seem to have some hardcoded
paths somewhere that cause me to bang my forehead on my desk.

However, I can work with it if necessary.

I was mainly hoping someone had looked into this already; it doesn't
sound like it.

Thanks for the reply!

Re: ** POTENTIAL FRAUD ALERT - RED HAT ** building static libs

[Mark Wielaard]

Hi,

(Interesting Subject. Disclaimer, I work for Red Hat, but had no idea
 we had a potential fraud alert detection system :)

On Sat, Oct 31, 2020 at 04:05:52PM -0400, Paul Smith wrote:
> On Sat, 2020-10-31 at 15:52 -0400, Frank Ch. Eigler wrote:
> > > I'd like to build, just as an example, libdebuginfod as ONLY a
> > > static library and link it statically with debuginfod, gdb, etc.
> > 
> > libdebuginfod relies on a bunch of other libraries (curl and all of
> > its dependencies), so a libdebuginfod.a is unlikely to buy you much.
> 
> Oh, I'm aware :).
> 
> I have all those other libraries built statically as well... they're
> pretty easy to build that way actually.
> 
> I'm already statically linking libdebuginfod.a with GDB, along with
> curl et.al.
> 
> But to do it, I need to build elfutils then reach into the build
> directory and pluck out the static library and copy it somewhere else
> then tell GDB to look there instead.
> 
> And, I have no solution for building the debuginfod server itself
> statically.

To be honest I recently removed the static development libraries from
Fedora since nobody was using the (and the only package that dependent
on them did so by accident). And was hoping to eventually remove the
static builds from the code.

That said, I also use parts of it for DTS (Developer ToolSet).  See
the git mjw/RH-DTS branch. But there I use the static bits to
"secretly" create "fake" shared libaries. Using linker scripts that
link the actual elfutils bits static, but any dependencies shared. It
is complicated... 

> > OTOH, libtool is one way to arrange building both .a and .so's from
> > such libraries, and propagate dependencies via the .la files.
> 
> Well, I've had pretty much nothing but problems with libtool TBH, in
> terms of trying to generate general-purpose, relocatable libraries.  In
> my experience the libtool solutions always seem to have some hardcoded
> paths somewhere that cause me to bang my forehead on my desk.
> 
> However, I can work with it if necessary.
> 
> I was mainly hoping someone had looked into this already; it doesn't
> sound like it.

Although I am also not a fan of libtool, it might be the only thing
that can do this cleanly. The current support for static code is
actually only for the libraries and is otherwise only really used for
doing the coverage checks (and it isn't clear that really has to be
done static, that might just be a really old requirement that is no
longer true).

Is there an alternative to libtool you would recommend?

Thanks,

Mark

Re: building static libs

[Paul Smith]

My ISP appears to get this sort of treatment regularly.  I just don't
have the time or energy to investigate or switch to something else.  I
know that's why they can probably get away with it, but... that doesn't
give me more time or energy :p

On Tue, 2020-11-03 at 00:16 +0100, Mark Wielaard wrote:
> To be honest I recently removed the static development libraries from
> Fedora since nobody was using the (and the only package that
> dependent on them did so by accident). And was hoping to eventually
> remove the static builds from the code.

In the environment I have set up each package is deployed in its own
subdirectory, in a 100% relocatable configuration (the entire structure
is checked into source control and users can check it out anywhere they
want and it must work).  The repository contains versions of some tools
for Linux, Mac, Windows (of course things like GDB etc. are only in the
Linux section)  I prefer to avoid symlinks as they are not well-
supported on all platforms.

While I can conceivably figure out how to use an RPATH to get GDB to
find the libdebuginfod shared library in its project-specific location
via relative paths, it's just simpler all around to link statically.
 The advantages of shared libs aren't really compelling to me in this
configuration.

Hopefully they won't go away, but I guess that's up to you folks!