Re: Local Build ID Directory Lookup (DEBUGINFOD_LOCAL_PATH)
On Wed, 2023-05-31 at 15:17 -0700, Daniel Thornburgh via Elfutils-devel wrote: > This isn't the case for files available locally, but there is some > prior art: GDB's build ID directory layout (commonly > `/usr/lib/debug/.build-id// build ID>`). GDB has a flag to control this (`--with-separate-debug- > dir`), but that flag isn't shared by other tools. For example, > binutils supports this layout, but it simply hardcodes a list of > directories to search for, with no way to extend or override it. LLVM > also supports this, but has a differently named flag for it. Having content in /usr/lib is less good. It's perfect for allowing package managers to install debug info files for packages, but it's not good for allowing users to either download or "publish" their own info files. Couldn't the standard XDG environment variables be used to generate a search path or paths, rather than inventing new ones (or, the new variable can be used to override the default which is computed based on XDG), to find the user's personal build ID directories? This location can be updated without root, can easily be made available inside containers (flatpak / snap), etc. If everyone could agree on a naming convention so that all tools that need debug info could write them to a common location after download (or even on generation), and check that location for files first before querying debuginfod, that would be a great "it just works" feature and avoid a lot of duplication. Or, maybe I'm just misunderstanding something :).
pkg-config not used in configure?
I'm trying to build the latest elfutils release 0.191. The configure help says: ZSTD_COMPRESS_CFLAGS C compiler flags for ZSTD_COMPRESS, overriding pkg-config ZSTD_COMPRESS_LIBS linker flags for ZSTD_COMPRESS, overriding pkg-config but the last part of these statements is misleading, in that pkg-config is not used to find zstd headers and libraries. It seems to be used only to check the version of zstd after it's been found in some other way, which seems a bit dangerous (how do we know the version provided via pkg-config is the same version used via the above flags?) Setting PKG_CONFIG_PATH to the right place find the pkg-config definition as expected: $ PKG_CONFIG_PATH=/my/zstd/lib/pkgconfig \ pkg-config --cflags libzstd -I/my/zstd/include but configure does not: $ PKG_CONFIG_PATH=/my/zstd/lib/pkgconfig \ configure --with-zstd ... checking for library containing gzdirect... -lz checking for library containing BZ2_bzdopen... no checking for library containing lzma_auto_decoder... no checking for library containing ZSTD_decompress... no configure: error: missing -lzstd for --with-zstd Checking configure.ac it seems that elfutils uses the locally defined macro eu_ZIPLIB, and this doesn't consult pkg-config.
elfutils doesn't support building static only
The elfutils configure script doesn't provide support for the standard
GNU --{enable,disable}-{static,shared} options.
I found the makefile variable BUILD_STATIC, but it doesn't seem
possible to build only static libraries; for example, in libelf there's
no way to avoid building libelf.so.
Also, in debuginfo/Makefile.am it never installs the libdebuginfod.a
static library.
I would really like to be able to build GDB with debuginfo support, but
WITHOUT using a shared library for it and instead linking it
statically.
I can do this with a lot of hacking around to extract the uninstalled
libdebuginfod.a and copying it into the right place, but it would be
nice if elfutils provided first-class support for disabling shared
libraries!
Thanks for considering...
Re: pkg-config not used in configure?
On Mon, 2024-09-09 at 15:29 -0400, Paul Smith wrote: > I'm trying to build the latest elfutils release 0.191. The configure > help says: > > ZSTD_COMPRESS_CFLAGS > C compiler flags for ZSTD_COMPRESS, overriding pkg- > config > ZSTD_COMPRESS_LIBS > linker flags for ZSTD_COMPRESS, overriding pkg-config Actually, these variables don't seem to work either. Looking at the generated configure script, I don't see how to get elfutils to use zstd from a non-standard location? Do we just have to set the default CFLAGS / LDFLAGS...?
Re: pkg-config not used in configure?
Hi Mark; thanks for the note. On Tue, 2024-09-10 at 10:52 +0200, Mark Wielaard wrote: > On Mon, Sep 09, 2024 at 06:21:16PM -0400, Paul Smith wrote: > > On Mon, 2024-09-09 at 15:29 -0400, Paul Smith wrote: > > > I'm trying to build the latest elfutils release 0.191. The > > > configure > > > help says: > > > > > > ZSTD_COMPRESS_CFLAGS > > > C compiler flags for ZSTD_COMPRESS, overriding pkg- > > > config > > > ZSTD_COMPRESS_LIBS > > > linker flags for ZSTD_COMPRESS, overriding pkg- > > > config > > > > Actually, these variables don't seem to work either. > > > > Looking at the generated configure script, I don't see how to get > > elfutils to use zstd from a non-standard location? > > Yeah, this is unfortunate. There are two checks in configure.ac. One > for zstd decompression support (as used in libdw) which uses the > eu_ZIPLIB macro (as defined in m4/zip.m4). This is the main check, it > also creates the --with-zstd=... configure argument to provide an > alternative location. Hm. Are you saying that if I use --with-zstd=/my/prefix that should work? That was the first thing I tried, but it didn't seem to work and I don't think (from reading the configure script) where this value is used as part of the path search. But, the shell output of autoconf is not easy to read so maybe I missed it. I can give it another try. So far the only thing that's worked for me is to set CFLAGS and LDFLAGS directly on the configure script with the appropriate options to find zstd in is proper location. I have similar problems trying to add an alternate location for curl.
Writing core files to contain buildids
Hi all; I'm maintaining a fork of the old Google coredumper code: Original: https://github.com/anatol/google-coredumper My fork: https://github.com/madscientist/google-coredumper We use this for various reasons rather than relying on the Linux kernel coredumper and it's worked well for us for many years now. However, I would like to start using build IDs in our shared libs and binaries and to take best advantage of that I need to ensure that the build ID values appear in the generated core files, which, at the moment, they do not unfortunately. I'm hoping someone can point me to some information about what extra content I need to make sure is preserved in the generated coredump so that I can retrieve build IDs from it. Thanks!
Re: Writing core files to contain buildids
Thanks Mark, On Tue, 2020-10-27 at 15:39 +0100, Mark Wielaard wrote: > The basic idea behind getting buildids into core files is that they > (the GNU ELF notes) are at the start of the file in the first page > that is dumped (together with the phdrs) in the core file so when > core file consumers can walk the program headers and find the buildid > note (almost immediately following those headers). Something is missing; if I check the binary I see a build ID in it. I can control whether the userspace coredumper or the kernel coredumper is used via an environment variable: the kernel-generated core contains a full set of build ID values including vdso.so, the binary, and all normal .so's. But when using the userspace coredumper I get a completely valid coredump that GDB is happy with, for example, but there is only the vdso.so build ID present: I don't see any build IDs from the binary or shared libraries. I guess another possibility is that they are there but eu-unstrip --core can't find them? The userspace coredumper uses the output of /proc/self/maps and /proc/self/smaps to determine what memory to dump; the code is a bit hairy but I will investigate what's going on. The parsing of the maps starts here (I don't really expect anyone to read this but if you're curious): https://github.com/madscientist/google-coredumper/blob/1b64fbc282ba08654853f34c2bda00ffe5e26855/src/elfcore.c#L760 and the write-out starts here: https://github.com/madscientist/google-coredumper/blob/1b64fbc282ba08654853f34c2bda00ffe5e26855/src/elfcore.c#L1019 > A few more technical details can be found at: > https://fedoraproject.org/wiki/Releases/FeatureBuildId#Include_build_IDs_in_core_dumps Thanks I did see that but I will read it harder.
Re: Writing core files to contain buildids
On Tue, 2020-10-27 at 23:23 +0100, Mark Wielaard wrote: > Do you have the generated core files somehwere so others can look at > them? How exactly are you testing the build-id notes are there? I don't have one to publish but I can create one. That's a good idea anyway as it will be simpler to debug than the actual system which is much more complex. I'm using eu-unstrip -n --core core.xxx to check for build IDs.
building static libs
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
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: building static libs
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!
