On Wed, 2019-11-20 at 08:29 -0500, Frank Ch. Eigler wrote:
> Hi -
>
> > But it isn't just about interference with other libcurl activity.
> > If
> > you look at the curl_global_init code you see that it actually
> > calls
> > a lot of code in other libraries. It is the curl_global_init code
> > th
Hi -
> But it isn't just about interference with other libcurl activity. If
> you look at the curl_global_init code you see that it actually calls
> a lot of code in other libraries. It is the curl_global_init code
> that shouldn't be run in a multi-threaded environment. That it is
> acceptable to
Hi,
On Tue, 2019-11-19 at 16:22 -0500, Frank Ch. Eigler wrote:
> On Tue, Nov 19, 2019 at 09:15:20PM +0100, Mark Wielaard wrote:
> > > That's what the doc says. What the code does, as far back as the year
> > > 2001, is have a static flag/counter in curl_global_init() that
> > > prevents multiple
Hi -
On Tue, Nov 19, 2019 at 09:15:20PM +0100, Mark Wielaard wrote:
> > That's what the doc says. What the code does, as far back as the year
> > 2001, is have a static flag/counter in curl_global_init() that
> > prevents multiple initialization.
>
> But the warning isn't about multiple initiali
Hi Frank,
On Tue, Nov 19, 2019 at 11:20:34AM -0500, Frank Ch. Eigler wrote:
> > > Doing a redundant initialization later is not a problem; there is a
> > > counter in there. The problematic case would be
> > > - a multithreaded application
> > > - loading debuginfod.so multiply concurrently someh
Hi -
> > Doing a redundant initialization later is not a problem; there is a
> > counter in there. The problematic case would be
> > - a multithreaded application
> > - loading debuginfod.so multiply concurrently somehow
> > - and calling the solib ctor concurrently somehow
> > - and all of this
Hi,
On Mon, 2019-11-18 at 15:33 -0500, Frank Ch. Eigler wrote:
> > > > Do you know how other libraries that use libcurl deal with this?
> > >
> > > I looked over some other libcurl users in fedora. Some don't worry
> > > about the issue at all, relying on implicit initialization, which is
> > >
Hi -
> > > But since the user won't see the URL generated they might not notice
> > > what is really going on. They will just see that something wasn't
> > > found, won't they?
> >
> > Yes, so the only benefit would be the generation of a different error
> > message for impossible buildids.
>
>
Hi,
On Sat, 2019-11-16 at 13:52 -0500, Frank Ch. Eigler wrote:
> Yeah, maybe a different automake version made it work after my earlier
> failing tests. (dead horse PS. It remains my opinion that we should
> commit auto* generated files into git.)
>
> > > Possible, but since these bits are just
Hi -
> It also seems that how you did it on the branch:
Yeah, maybe a different automake version made it work after my earlier
failing tests. (dead horse PS. It remains my opinion that we should
commit auto* generated files into git.)
> > Possible, but since these bits are just getting transcr
Hi -
> I was just thinking put them together in one file.
.. or a header?
> Otherwise, just add a comment in both that there is similar code in the
> other file and if you update one, then you probably want to update the
> other too.
Did this for now.
- FChE
On Thu, 2019-11-14 at 06:24 -0500, Frank Ch. Eigler wrote:
> > [...libdw* debuginfod_find_* calls]
> > But given that they are almost similar, I would suggest to move both
> > into their own file sharing most of the code to do the dlopen dance.
>
> Where? It can't be in the solib. We're talking
Hi,
On Wed, 2019-11-13 at 18:24 -0500, Frank Ch. Eigler wrote:
> Hurrah! Documentation! Thanks.
> >
> > But given that all other documentation is under doc/ could you move it
> > there (guarded by DEBUGINFOD). It is just more consistent. If you leave
> > it in this subdir I think you should also
On Tue, 2019-11-12 at 10:14 -0500, Frank Ch. Eigler wrote:
> > My only concern is that these might slow down configure when debuginfod
> > isn't enabled? Can/Should they be moved later after the enable test?
>
> It'd be fractions of a second per configure run ... worth worrying about?
Probably no
Hi -
> [...libdw* debuginfod_find_* calls]
> But given that they are almost similar, I would suggest to move both
> into their own file sharing most of the code to do the dlopen dance.
Where? It can't be in the solib. We're talking about sharing, what,
two copies of three or four lines of code
Hi -
> > It'd be fractions of a second per configure run ... worth worrying
> > about?
>
> Probably not, but if it is easy to hide after the check, why not do it?
> Don't if it requires nasty trickery though.
OK.
> > > > +PKG_PROG_PKG_CONFIG
> > > > +AC_ARG_ENABLE([debuginfod], AC_HELP_STRING([
Hi -
> Hurrah! Documentation! Thanks.
>
> But given that all other documentation is under doc/ could you move it
> there (guarded by DEBUGINFOD). It is just more consistent. If you leave
> it in this subdir I think you should also move the existing
> documentation files (and I think that is not w
Hi,
On Mon, 2019-10-28 at 15:06 -0400, Frank Ch. Eigler wrote:
> Subject: [PATCH 1/2] debuginfod 1/2: client side
>
> Introduce the debuginfod/ subdirectory, containing the client for a
> new debuginfo-over-http service, in shared-library and command-line
> forms. Two functions in libdwfl make c
Hi Frank,
On Tue, 2019-11-12 at 10:14 -0500, Frank Ch. Eigler wrote:
> > My only concern is that these might slow down configure when
> > debuginfod
> > isn't enabled? Can/Should they be moved later after the enable
> > test?
>
> It'd be fractions of a second per configure run ... worth worrying
Hi,
On Mon, 2019-10-28 at 15:06 -0400, Frank Ch. Eigler wrote:
> Introduce the debuginfod/ subdirectory, containing the client for a
> new debuginfo-over-http service, in shared-library and command-line
> forms. Two functions in libdwfl make calls into the client library to
> fetch elf/dwarf file
Hi -
> A few comments on the first (top-level) part, just to make progress.
Thanks.
> > diff --git a/config/libdebuginfod.pc.in b/config/libdebuginfod.pc.in
> No Requires on libelf or libdw?
Correct, the debuginfo client code does not call into elfutils.
> My only concern is that these might
Hi,
On Mon, 2019-10-28 at 15:06 -0400, Frank Ch. Eigler wrote:
> From 3e1f8d93569004d06902459d84baceb636e139d5 Mon Sep 17 00:00:00 2001
> From: Aaron Merey
> Date: Mon, 28 Oct 2019 13:29:26 -0400
> Subject: [PATCH 1/2] debuginfod 1/2: client side
>
> Introduce the debuginfod/ subdirectory, conta
From 3e1f8d93569004d06902459d84baceb636e139d5 Mon Sep 17 00:00:00 2001
From: Aaron Merey
Date: Mon, 28 Oct 2019 13:29:26 -0400
Subject: [PATCH 1/2] debuginfod 1/2: client side
Introduce the debuginfod/ subdirectory, containing the client for a
new debuginfo-over-http service, in shared-library an
23 matches
Mail list logo
