https://sourceware.org/bugzilla/show_bug.cgi?id=25509
Mark Wielaard changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
--- Comment #21 from Eli Schwartz ---
(In reply to Mark Wielaard from comment #17)
> I admit that having the combination --enable-libdebuginfod=dummy and
> --enable-libdebuginfod is somewhat redundant/non-sensical, but it helps with
> (build t
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
--- Comment #19 from Mark Wielaard ---
(In reply to Eli Schwartz from comment #13)
> I think we'd prefer to have the ability to build libdebuginfod without the
> server.
I believe you get that with --enable-libdebuginfod --disable-debuginfod,
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
--- Comment #18 from Martin Liska ---
> I am hoping that helps both the Suse use case which would like a
> bootstrap/dummy libdebuginfod.so (--enable-libdebuginfod=dummy
> --disable-debuginfod)
Yes, I can confirm the suggested scenario will w
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
--- Comment #17 from Mark Wielaard ---
Just to be clear, the current setup is:
--enable-debuginfod or --enable-debuginfod=yes: builds all debuginfod
server/client artifacts (requires libcurl)
--disable-debuginfod or --enable-debuginfod=no: bu
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
--- Comment #16 from Frank Ch. Eigler ---
(yup, misinterpreted what the "this" was you meant, sorry!)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
--- Comment #15 from Eli Schwartz ---
Wouldn't that be covered by "libdebuginfod disabled equals dummy enabled"?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
--- Comment #14 from Frank Ch. Eigler ---
It's not just for testing purposes. It's to aid bootstrapping new OS versions,
by reducing the transitive requirements of elfutils in the buildroot.
--
You are receiving this mail because:
You are o
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
--- Comment #13 from Eli Schwartz ---
I think we'd prefer to have the ability to build libdebuginfod without the
server. Ambivalent about a special option to force the libdebuginfod dummy to
be created, but...
If it's just for testing purpose
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
--- Comment #12 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #11)
> Martin, could you comment on the setup? Does this help your case? I will
> probably not actually use it myself, so don't want to add it unless it
> really ma
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
--- Comment #11 from Mark Wielaard ---
(In reply to Frank Ch. Eigler from comment #10)
> Comment on attachment 12628 [details]
> debuginfod: Add --disable-libdebuginfod and --enable-libdebuginfod=dummy.
>
> Looks workable.
>
> I don't know i
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
--- Comment #10 from Frank Ch. Eigler ---
Comment on attachment 12628
--> https://sourceware.org/bugzilla/attachment.cgi?id=12628
debuginfod: Add --disable-libdebuginfod and --enable-libdebuginfod=dummy.
Looks workable.
I don't know if we
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
Mark Wielaard changed:
What|Removed |Added
Last reconfirmed||2020-06-19
Assignee|unassig
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
Martin Liska changed:
What|Removed |Added
CC||mliska at suse dot cz
--- Comment #8 f
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
--- Comment #7 from Mark Wielaard ---
So there are two ideas here:
- Split --disable-debuginfod which currently disables building
debuginfod (the server), libdebuginfod (the library) and
debuginfod-find (the helper binaries) in two:
--d
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
--- Comment #6 from Frank Ch. Eigler ---
(In reply to Eli Schwartz from comment #5)
> > # Look for libmicrohttpd, libcurl, libarchive, sqlite for debuginfo server
> > # minimum versions as per rhel7. Single --enable-* option arranges to build
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
Eli Schwartz changed:
What|Removed |Added
CC||eschwartz at archlinux dot org
--- Com
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
--- Comment #4 from Martin Liška ---
(In reply to Mark Wielaard from comment #2)
> (In reply to Martin Liška from comment #0)
> > In openSUSE, we do face a problem with cyclic dependencies. Many core
> > packages like gcc, glibc, elfutils or b
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
Frank Ch. Eigler changed:
What|Removed |Added
CC||fche at redhat dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
Mark Wielaard changed:
What|Removed |Added
CC||mark at klomp dot org
--- Comment #2
https://sourceware.org/bugzilla/show_bug.cgi?id=25509
--- Comment #1 from Martin Liška ---
I have basically 2 possible solutions:
- elfutils will provide a stub client library (libdebuginfod-stub.so) which
will then do dlopen for the real libdebuginfod.so during run-rime
- one can do execv of de
21 matches
Mail list logo
