Re: [PATCH 1/1] Y2038: add function __difftime64

Albert ARIBAUD wrote: I really need you to develop in some more detail how you envision adding Y2038 support in Gnulib. It sounds like the best thing to do is the original plan: you develop a set of glibc patches without worrying about Gnulib, I'll suggest any necessary changes, and we iterat

Re: [PATCH]: regex: fix memory leak in multibyte character set regexes.

Thanks, I installed that into Gnulib.

Re: [PATCH]: regex: fix memory leak in multibyte character set regexes.

Hello Paul and all, > Paul Eggert wrote: > We've now cut glibc 2.28 so I short-circuited all this by installing the fix > into glibc (for 2.29) and propagating the fix into Gnulib. Thanks again. Thanks for installing it. I found another leak, this time in dfa: pointer returned from 'dfamalloc()'

Re: threadlib vs as-needed vs libtool

Sorry hit send too soon... On Thu, 2 Aug 2018 at 14:18, Michael Hudson-Doyle < michael.hud...@canonical.com> wrote: > > > On Thu, 2 Aug 2018 at 13:03, Bruno Haible wrote: > >> Michael Hudson-Doyle wrote: >> > > It sounds like you are using $(LIBMULTITHREAD) when you should in fact >> > > be usin

Re: threadlib vs as-needed vs libtool

On Thu, 2 Aug 2018 at 13:03, Bruno Haible wrote: > Michael Hudson-Doyle wrote: > > > It sounds like you are using $(LIBMULTITHREAD) when you should in fact > > > be using $(LTLIBMULTITHREAD). See the module description: > > > > This doesn't seem to help. ... I'm just a distro maintainer > > stabb

[PATCH] ieee754-h: new module

It looks like Emacs can use this for some NaN processing. Emacs uses it only on double NaNs so it should be safe. * MODULES.html.sh (func_all_modules): Add ieee754-h. * config/srclist.txt: Mention ieee754.h in a comment. * doc/glibc-headers/ieee754.texi (ieee754.h): Gnulib now has a substitute that

Re: threadlib vs as-needed vs libtool

Michael Hudson-Doyle wrote: > > It sounds like you are using $(LIBMULTITHREAD) when you should in fact > > be using $(LTLIBMULTITHREAD). See the module description: > > This doesn't seem to help. ... I'm just a distro maintainer > stabbing in the dark here! I may have the light. But I don't know

Re: threadlib vs as-needed vs libtool

Thanks for the reply. On Wed, 1 Aug 2018 at 23:06, Bruno Haible wrote: > Hi, > > Michael Hudson-Doyle wrote: > > I recently encountered the problem that the patch "threadlib: Fix > > LIBMULTITHREAD on platforms where --as-needed is enabled" was intended to > > fix. But unfortunately, the fix doe

Re: [PATCH 1/1] Y2038: add function __difftime64

Hi Paul, Le Wed, 1 Aug 2018 11:49:39 -0700, Paul Eggert a écrit : > Albert ARIBAUD wrote: > > Hm... I fear that there's a vicious circle here: Paul wants Y2038 > > support code to go into Gnulib before it goes to glibc (for that part > > of the code which exists in both, of course). > > Yes.

Re: [PATCH]: regex: fix memory leak in multibyte character set regexes.

Paul Eggert wrote: Thanks, could you please install into Gnulib after doing the following: * Comment out the lib/regcomp.c in config/srclist.txt. * File a glibc bug report about this. We're cutting a new glibc release now and this will have to wait until after the dust has settled down. * Pu

Re: [PATCH 1/1] Y2038: add function __difftime64

Albert ARIBAUD wrote: Hm... I fear that there's a vicious circle here: Paul wants Y2038 support code to go into Gnulib before it goes to glibc (for that part of the code which exists in both, of course). Yes. But in order for Y0238 support code to go in, Gnulib will need a Y2038-proof time_t

Re: [PATCH 1/1] Y2038: add function __difftime64

> > > * If the underlying time_t is not Y2038-proof, Gnulib makes no effort > > >to fix the situation. > > > > Incorrect. I explained this in > > . > > Maybe I misunderstood, then: for me, this explanation meant that if >

Re: [PATCH 1/1] Y2038: add function __difftime64

Hi Bruno, Le Wed, 01 Aug 2018 15:25:59 +0200, Bruno Haible a écrit : > Hello Albert, > > > Gnulib does not provide time_t > > > > and relies on the underlying system, which may or may not include GLIBC. > > Correct. > > > IIUC: > > > > * Gnulib does not *define* time_t at all, always ass

Re: [PATCH 1/1] Y2038: add function __difftime64

Hello Albert, > Gnulib does not provide time_t > > and relies on the underlying system, which may or may not include GLIBC. Correct. > IIUC: > > * Gnulib does not *define* time_t at all, always assuming >that it will exist in the underlying system. Correct. > * Also, Gnulib may, if mod

Re: threadlib vs as-needed vs libtool

Hi, Michael Hudson-Doyle wrote: > I recently encountered the problem that the patch "threadlib: Fix > LIBMULTITHREAD on platforms where --as-needed is enabled" was intended to > fix. But unfortunately, the fix doesn't actually work because libtool is > re-ordering the linker commands. In particula

Re: [PATCH 1/1] Y2038: add function __difftime64

Sorry, hit the enter key way earlier that I should have. Le Wed, 1 Aug 2018 11:49:49 +0200, Albert ARIBAUD a écrit : > Hi Paul, > > Le Fri, 6 Jul 2018 21:45:54 -0700, Paul Eggert a > écrit : > > > Bruno Haible wrote: > > > What would be the benefit of doing so in gnulib? That some, but not

Re: [PATCH 1/1] Y2038: add function __difftime64

Hi Paul, Le Fri, 6 Jul 2018 21:45:54 -0700, Paul Eggert a écrit : > Bruno Haible wrote: > > What would be the benefit of doing so in gnulib? That some, but not all, > > programs of a Linux distro can claim Y2038-proof-ness before all the rest? > > Basically that, yes, though the benefit is no