* building static libs @ 2020-10-31 19:10 Paul Smith 2020-10-31 19:52 ` ** POTENTIAL FRAUD ALERT - RED HAT ** " Frank Ch. Eigler 0 siblings, 1 reply; 5+ messages in thread From: Paul Smith @ 2020-10-31 19:10 UTC (permalink / raw) To: elfutils-devel 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ** POTENTIAL FRAUD ALERT - RED HAT ** building static libs 2020-10-31 19:10 building static libs Paul Smith @ 2020-10-31 19:52 ` Frank Ch. Eigler 2020-10-31 20:05 ` Paul Smith 0 siblings, 1 reply; 5+ messages in thread From: Frank Ch. Eigler @ 2020-10-31 19:52 UTC (permalink / raw) To: Paul Smith; +Cc: elfutils-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ** POTENTIAL FRAUD ALERT - RED HAT ** building static libs 2020-10-31 19:52 ` ** POTENTIAL FRAUD ALERT - RED HAT ** " Frank Ch. Eigler @ 2020-10-31 20:05 ` Paul Smith 2020-11-02 23:16 ` Mark Wielaard 0 siblings, 1 reply; 5+ messages in thread From: Paul Smith @ 2020-10-31 20:05 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: elfutils-devel 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! ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ** POTENTIAL FRAUD ALERT - RED HAT ** building static libs 2020-10-31 20:05 ` Paul Smith @ 2020-11-02 23:16 ` Mark Wielaard 2020-11-03 13:46 ` Paul Smith 0 siblings, 1 reply; 5+ messages in thread From: Mark Wielaard @ 2020-11-02 23:16 UTC (permalink / raw) To: Paul Smith; +Cc: Frank Ch. Eigler, elfutils-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: building static libs 2020-11-02 23:16 ` Mark Wielaard @ 2020-11-03 13:46 ` Paul Smith 0 siblings, 0 replies; 5+ messages in thread From: Paul Smith @ 2020-11-03 13:46 UTC (permalink / raw) To: Mark Wielaard; +Cc: elfutils-devel 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! ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-11-03 13:46 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-10-31 19:10 building static libs Paul Smith 2020-10-31 19:52 ` ** POTENTIAL FRAUD ALERT - RED HAT ** " Frank Ch. Eigler 2020-10-31 20:05 ` Paul Smith 2020-11-02 23:16 ` Mark Wielaard 2020-11-03 13:46 ` Paul Smith
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).