Re: [PATCH 6/4] libbacktrace: Add loaded dlls after initialize

> Date: Tue, 9 Jan 2024 21:02:44 +0100 > Cc: i...@google.com, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org > From: Björn Schäpers > > Am 07.01.2024 um 18:03 schrieb Eli Zaretskii: > > In that case, you an call either GetModuleHandeExA or > > GetModuleHandeExW, the dif

Re: [PATCH 6/4] libbacktrace: Add loaded dlls after initialize

> Date: Sun, 7 Jan 2024 17:07:06 +0100 > Cc: i...@google.com, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org > From: Björn Schäpers > > > That was about GetModuleHandle, not about GetModuleHandleEx. For the > > latter, all Windows versions that support it also support "wide" APIs. > > So my

Re: [PATCH 6/4] libbacktrace: Add loaded dlls after initialize

[I re-added the other addressees, as I don' think you meant to make this discussion private between the two of us.] > Date: Sun, 7 Jan 2024 12:58:29 +0100 > From: Björn Schäpers > > Am 07.01.2024 um 07:50 schrieb Eli Zaretskii: > >> Date: Sat, 6 Jan 2024 23:15:24 +0100 >

Re: [PATCH 6/4] libbacktrace: Add loaded dlls after initialize

> Date: Sat, 6 Jan 2024 23:15:24 +0100 > From: Björn Schäpers > Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org > > This patch adds libraries which are loaded after backtrace_initialize, like > plugins or similar. > > I don't know what style is preferred for the Win32 typedefs, should the code

Re: [PATCH 4/4] libbacktrace: get debug information for loaded dlls

> Date: Thu, 30 Nov 2023 11:53:54 -0800 > Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org > From: Ian Lance Taylor via Gcc > > Also starting with a module count of 1000 seems like a lot. Do > typical Windows programs load that many modules? Unlikely. I'd start with 100.

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

> Date: Mon, 20 Nov 2023 20:57:38 +0100 > Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org > From: Björn Schäpers > > +#ifndef NOMINMAX > +#define NOMINMAX > +#endif Why is this part needed? Otherwise, LGTM, thanks. (But I'm don't have the approval rights, so please wait for Ian to chime in.)

Re: RFC: Top level configure: Require a minimum version 6.8 texinfo

> Date: Tue, 29 Aug 2023 17:45:20 +0200 > Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org, > binut...@sourceware.org > From: Jakub Jelinek via Gdb-patches > > On Tue, Aug 29, 2023 at 04:21:44PM +0100, Nick Clifton via Gcc-patches wrote: > > Currently the top level configure.ac file

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

> From: Ian Lance Taylor > Date: Tue, 24 Jan 2023 09:58:10 -0800 > Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org > > I'd rather that the patch look like the appended. Can someone with a > Windows system test to see what that builds and passes the tests? ENOPATCH

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

> From: Ian Lance Taylor > Date: Tue, 24 Jan 2023 06:35:21 -0800 > Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org > > > > On Windows it seems that MAX_PATH is not > > > a true limit, as an extended length path may be up to 32767 bytes. > > > > The limit of 32767 characters (not

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

> Date: Mon, 23 Jan 2023 15:00:56 -0800 > Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org > From: Ian Lance Taylor via Gcc > > > +#ifdef HAVE_WINDOWS_H > > + > > +static char * > > +windows_get_executable_path (char *buf, backtrace_error_callback > > error_callback, > > +

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

> Date: Sat, 21 Jan 2023 11:47:42 +0100 > Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org > From: Gabriel Ravier > > > On 1/21/23 05:05, Eli Zaretskii wrote: > >> Date: Fri, 20 Jan 2023 21:39:56 +0100 > >> Cc: g...@hazardy.de, gcc-patches@gcc

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

> Date: Sat, 21 Jan 2023 17:18:14 +0800 > Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org > From: LIU Hao > > 在 2023-01-21 12:05, Eli Zaretskii via Gcc 写道: > > I'm not sure I follow the logic. A program that calls > > GetModuleHandleW will refuse to st

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

> Date: Fri, 20 Jan 2023 21:39:56 +0100 > Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org > From: Gabriel Ravier > > >> - using wide APIs with Windows is generally considered to be a best > >> practice, even when not strictly needed (and in this case I can't see > >> any problem

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

> Date: Fri, 20 Jan 2023 17:46:59 +0100 > Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org > From: Gabriel Ravier > > On 1/20/23 14:39, Eli Zaretskii via Gcc wrote: > >> From: Björn Schäpers > >> Date: Fri, 20 Jan 2023 11:54:08 +0100 > >> > >> @@

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

> From: Björn Schäpers > Date: Fri, 20 Jan 2023 11:54:08 +0100 > > @@ -856,7 +870,12 @@ coff_add (struct backtrace_state *state, int descriptor, > + (sections[i].offset - min_offset)); > } > > - if (!backtrace_dwarf_add (state, /* base_address */ 0,

Re: Benefits of using Sphinx documentation format

> From: Jonathan Wakely > Date: Mon, 12 Jul 2021 15:54:49 +0100 > Cc: Martin Liška , > "g...@gcc.gnu.org" , gcc-patches > , > "Joseph S. Myers" > > You like texinfo. We get it. Would you please drop the attitude?

Re: Benefits of using Sphinx documentation format

> Cc: h...@bitrange.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org, > jos...@codesourcery.com > From: Martin Liška > Date: Mon, 12 Jul 2021 16:37:00 +0200 > > > 4) The need to learn yet another markup language. > > While this is not a problem for simple text, it does require a > >

Re: Benefits of using Sphinx documentation format

> Cc: g...@gcc.gnu.org, gcc-patches@gcc.gnu.org, jos...@codesourcery.com > From: Martin Liška > Date: Mon, 12 Jul 2021 16:34:11 +0200 > > > "Texinfo must go" is one possible conclusion from your description. > > But it isn't the only one. An alternative is "the Texinfo source of > > the GCC

Re: Benefits of using Sphinx documentation format

> From: Jonathan Wakely > Date: Mon, 12 Jul 2021 15:05:11 +0100 > Cc: Martin Liška , > "g...@gcc.gnu.org" , gcc-patches > , > "Joseph S. Myers" > > To be clear, I give links to users frequently (several times a week, > every week, for decades) and prefer to give them a link to

Re: Benefits of using Sphinx documentation format

> From: Jonathan Wakely > Date: Mon, 12 Jul 2021 14:53:44 +0100 > Cc: Martin Liška , > "g...@gcc.gnu.org" , gcc-patches > , > "Joseph S. Myers" > > For me, these items are enough justification to switch away from > texinfo, which produces crap HTML pages with crap anchors. If we

Re: Benefits of using Sphinx documentation format

> Cc: g...@gcc.gnu.org, gcc-patches@gcc.gnu.org, jos...@codesourcery.com > From: Martin Liška > Date: Mon, 12 Jul 2021 15:25:47 +0200 > > Let's make it a separate sub-thread where we can discuss motivation why > do I want moving to Sphinx format. Thanks for starting this discussion. >

Re: [PATCH] Port GCC documentation to Sphinx

> From: Richard Sandiford > Cc: Eli Zaretskii , g...@gcc.gnu.org, > gcc-patches@gcc.gnu.org, jos...@codesourcery.com > Date: Mon, 05 Jul 2021 10:17:38 +0100 > > Hans-Peter Nilsson writes: > > I've read the discussion downthread, but I seem to miss (a recap > &

Re: [PATCH] Port GCC documentation to Sphinx

> Cc: Eli Zaretskii , g...@gcc.gnu.org, gcc-patches@gcc.gnu.org, > jos...@codesourcery.com > From: Martin Liška > Date: Fri, 2 Jul 2021 11:40:06 +0200 > > > It must > > look sensible without that. In this case it seems that already the > > generated .texinf

Re: [PATCH] Port GCC documentation to Sphinx

> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org > From: Martin Liška > Date: Fri, 2 Jul 2021 11:30:02 +0200 > > > So the purpose of having the comma there is to avoid having a period > > in the middle of a sentence, which is added by makeinfo (because the > > Info

Re: [PATCH] Port GCC documentation to Sphinx

> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org > From: Martin Liška > Date: Thu, 1 Jul 2021 18:04:24 +0200 > > > Emacs doesn't hide the period. But there shouldn't be a period to > > begin with, since it's the middle of a sentence. The correct way of > > writing this

Re: [PATCH] Port GCC documentation to Sphinx

> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org > From: Martin Liška > Date: Thu, 1 Jul 2021 16:14:30 +0200 > > >> If I understand the notes correct, the '.' should be also hidden by e.g. > >> Emacs. > > > > No, it doesn't. The actual text in the Info file is: > > >

Re: [PATCH] Port GCC documentation to Sphinx

> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org > From: Martin Liška > Date: Thu, 1 Jul 2021 14:44:10 +0200 > > > It helps some, but not all of the issues disappear. For example, > > stuff like this is still hard to read: > > > >To select this standard in GCC, use

Re: [PATCH] Port GCC documentation to Sphinx

> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org > From: Martin Liška > Date: Wed, 30 Jun 2021 16:04:32 +0200 > > > Thanks, but does that mean @var will no longer stand out in the > > produced Info format? That'd be sub-optimal, I think, because a clear > > reference to

Re: [PATCH] Port GCC documentation to Sphinx

> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org > From: Martin Liška > Date: Wed, 30 Jun 2021 15:28:40 +0200 > > >‘@`file'’ > > > > Read command-line options from ‘`file'’. The options read are > > inserted in place of the original ‘@`file'’ option.

Re: [PATCH] Port GCC documentation to Sphinx

> Cc: jos...@codesourcery.com, g...@gcc.gnu.org, gcc-patches@gcc.gnu.org > From: Martin Liška > Date: Wed, 30 Jun 2021 12:11:03 +0200 > > > (Admittedly, Emacs by default hides some of the text of a > > cross-reference, but not hiding them in this case produces an even > > less legible text.) >

Re: [PATCH] Port GCC documentation to Sphinx

> Date: Tue, 29 Jun 2021 19:57:11 +0300 > From: Eli Zaretskii via Gcc > Cc: g...@gcc.gnu.org, gcc-patches@gcc.gnu.org, jos...@codesourcery.com > > Or how about this: > > `Overall Options' > >See Options Controlling the Kind of Output. > >*n

Re: [PATCH] Port GCC documentation to Sphinx

> From: Martin Liška > Date: Tue, 29 Jun 2021 12:09:23 +0200 > Cc: GCC Development , gcc-patches@gcc.gnu.org > > On 6/28/21 5:33 PM, Joseph Myers wrote: > > Are formatted manuals (HTML, PDF, man, info) corresponding to this patch > > version also available for review? > > I've just uploaded

Re: Compilation error in simple-object-elf.c

> Cc: d...@redhat.com, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org > From: Pedro Alves > Date: Thu, 19 Jul 2018 14:41:13 +0100 > > On 07/19/2018 02:06 PM, Eli Zaretskii wrote: > >> From: Richard Biener > >> Date: Thu, 19 Jul 2018 10:46:01 +0200

Re: Compilation error in simple-object-elf.c

> From: Richard Biener > Date: Thu, 19 Jul 2018 10:46:01 +0200 > Cc: DJ Delorie , GCC Patches , > gdb-patc...@sourceware.org > > > *err = ENOTSUP; > >^~~ > > ./simple-object-elf.c:1284:14: note: each undeclared identifier is > > reported only once for

Compilation error in simple-object-elf.c

note: each undeclared identifier is reported only once for each function it appears in Suggested fix: 2018-07-18 Eli Zaretskii * libiberty/simple-object-elf.c (ENOTSUP): If not defined by errno.h, redirect to ENOSYS. --- libiberty/simple-object-elf.c~0 2018-07-04 18:41:59.0

Re: Compilation warning in simple-object-xcoff.c

> From: Ian Lance Taylor <i...@google.com> > Date: Sat, 20 Jan 2018 21:01:09 -0800 > Cc: DJ Delorie <d...@redhat.com>, gcc-patches <gcc-patches@gcc.gnu.org>, > gdb-patches <gdb-patc...@sourceware.org> > > On Sat, Jan 20, 2018 at 4:47 AM, Eli Zare

Re: Compilation warning in simple-object-xcoff.c

> Date: Thu, 18 Jan 2018 05:25:20 +0200 > From: Eli Zaretskii <e...@gnu.org> > CC: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org, > gdb-patc...@sourceware.org > > > From: DJ Delorie <d...@redhat.com> > > Cc: sch...@linux-m68k.org, gcc-patches@gcc.g

Re: Compilation warning in simple-object-xcoff.c

> From: DJ Delorie <d...@redhat.com> > Cc: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org > Date: Wed, 17 Jan 2018 15:47:49 -0500 > > Eli Zaretskii <e...@gnu.org> writes: > > > DJ, would the following semi-kludgey workaround be a

Re: Compilation warning in simple-object-xcoff.c

> From: Andreas Schwab <sch...@linux-m68k.org> > Cc: Eli Zaretskii <e...@gnu.org>, gcc-patches@gcc.gnu.org, > gdb-patc...@sourceware.org > Date: Tue, 16 Jan 2018 23:00:55 +0100 > > On Jan 16 2018, DJ Delorie <d...@redhat.com> wrote: > > >

Re: Compilation warning in simple-object-xcoff.c

> From: DJ Delorie > Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org > Date: Tue, 16 Jan 2018 13:00:48 -0500 > > > I think that warning is valid - the host has a 32-bit limit to file > sizes (off_t) but it's trying to read a 64-bit offset (in that clause). > It's

Compilation warning in simple-object-xcoff.c

Compiling GDB 8.0.91 with mingw.org's MinGW GCC 6.0.3 produces this warning in libiberty: gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS -I. -I./../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -D_GNU_SOURCE ./simple-object-xcoff.c -o

Re: MinGW compilation warnings in libiberty's xstrndup.c

> From: DJ Delorie <d...@redhat.com> > Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org > Date: Wed, 31 May 2017 00:17:14 -0400 > > > Eli Zaretskii <e...@gnu.org> writes: > > Seems to work fine, thanks. > > Checked into gcc trunk then :-) Thanks!

Re: MinGW compilation warnings in libiberty's xstrndup.c

> From: DJ Delorie > Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org > Date: Fri, 26 May 2017 17:34:12 -0400 > > > Please try this patch: Seems to work fine, thanks.

Re: MinGW compilation warnings in libiberty's waitpid.c

> Date: Fri, 26 May 2017 09:30:53 -0700 > From: Joel Brobecker > Cc: DJ Delorie , gcc-patches@gcc.gnu.org, > gdb-patc...@sourceware.org > > Normally, I'd expect someone pushing to GCC's libibert to also > update our repo accordingly. However, it's

Re: MinGW compilation warnings in libiberty's waitpid.c

> From: DJ Delorie > Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org > Date: Wed, 24 May 2017 17:36:16 -0400 > > Thanks. Committed! Thanks. Is the environ thing also fixed? Joel/Pedro, how should I go about making sure these changes are in the GDB copy of libiberty?

Re: MinGW compilation warnings in libiberty's waitpid.c

entry would be nice, so I don't have to write one ;-) Sure: 2017-05-24 Eli Zaretskii <e...@gnu.org> * libiberty/waitpid.c (wait) [__MINGW32__]: Define as a macro that calls _cwait, so that this function works on MinGW.

Re: MinGW compilation warnings in libiberty's waitpid.c

> From: DJ Delorie <d...@redhat.com> > Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org > Date: Tue, 23 May 2017 15:37:32 -0400 > > > Eli Zaretskii <e...@gnu.org> writes: > > Instead of making waitpid an always-failing stub on MinGW, wouldn't it &g

Re: MinGW compilation warnings in libiberty's waitpid.c

> From: DJ Delorie > Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org > Date: Mon, 22 May 2017 15:38:40 -0400 > > Since (or "if") nobody will (should) use waitpid() on mingw anyway, and > since libiberty really wants to include waitpid.o, how difficult would > it be to

Re: MinGW compilation warnings in libiberty's waitpid.c

gt; Index: libiberty/ChangeLog > === > --- libiberty/ChangeLog (revision 248307) > +++ libiberty/ChangeLog (working copy) > @@ -1,3 +1,7 @@ > +2017-05-19 Eli Zaretskii <e...@gnu.org> > + > + * configure.ac (*-*-mingw*): Don't build waitpid.c. > + > 2017

Re: MinGW compilation warnings in libiberty's include/environ.h

> From: DJ Delorie <d...@redhat.com> > Cc: pal...@redhat.com, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org > Date: Sat, 20 May 2017 02:16:14 -0400 > > Eli Zaretskii <e...@gnu.org> writes: > > My problem is, I don't have a GCC repository, so doing the abo

Re: MinGW compilation warnings in libiberty's include/environ.h

> From: DJ Delorie > Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org > Date: Fri, 19 May 2017 21:25:56 -0400 > > Fix committed. Thanks! Pedro, how do we make this propagated to the GDB repository? > As Pedro noted, the correct way to request a change is > to make the

Re: MinGW compilation warnings in libiberty's include/environ.h

> Cc: gdb-patc...@sourceware.org > From: Pedro Alves > Date: Fri, 19 May 2017 16:51:30 +0100 > > So again there's a system header that defines the symbol > but for some reason libiberty still wants to declare/define > it is if it weren't? Yes. AFAICS, libiberty's configure

Re: MinGW compilation warnings in libiberty's waitpid.c

> Cc: gdb-patc...@sourceware.org > From: Pedro Alves > Date: Fri, 19 May 2017 16:36:46 +0100 > > So I wonder whether we could just unconditionally remove the waitpid > replacement instead. That's probably the best path forward.

Re: MinGW compilation warnings in libiberty's xstrndup.c

> Cc: gdb-patc...@sourceware.org, Thomas Schwinge > From: Pedro Alves > Date: Fri, 19 May 2017 16:22:55 +0100 > > But then, xstrndup.c has at the top: > > #ifdef HAVE_STRING_H > #include > #else > # ifdef HAVE_STRINGS_H > # include > # endif >

MinGW compilation warnings in libiberty's xstrndup.c

When compiling libiberty (as part of GDB) with MinGW on MS-Windows, I see the following warning: gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS -I. -I./../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -D_GNU_SOURCE ./xstrndup.c -o xstrndup.o

MinGW compilation warnings in libiberty's waitpid.c

When compiling libiberty (as part of GDB) with MinGW on MS-Windows, I see the following warning: gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS -I. -I./../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -D_GNU_SOURCE ./waitpid.c -o waitpid.o

MinGW compilation warnings in libiberty's include/environ.h

When compiling libiberty (as part of GDB) with MinGW on MS-Windows, I see the following warning: gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS -I. -I./../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -D_GNU_SOURCE ./setenv.c -o setenv.o

Re: Change license of filenames.h to LGPL

> From: Ozkan Sezer <seze...@gmail.com> > Date: Thu, 29 Sep 2016 00:09:19 +0300 > Cc: Alexandre Oliva <aol...@redhat.com>, gcc-patches@gcc.gnu.org > > On 9/28/16, Eli Zaretskii <e...@gnu.org> wrote: > >> From: Alexandre Oliva <aol...@redhat.com> >

Re: Change license of filenames.h to LGPL

> From: Alexandre Oliva > Cc: gcc-patches@gcc.gnu.org > Date: Wed, 28 Sep 2016 16:03:02 -0300 > > Does that work for everyone involved? Except that no one will reimburse me for the time I wasted talking to several people, with eventually null result...

Re: Change license of filenames.h to LGPL

> From: Florian Weimer <f...@deneb.enyo.de> > Cc: DJ Delorie <d...@redhat.com>, gcc-patches@gcc.gnu.org, seze...@gmail.com > Date: Wed, 28 Sep 2016 16:43:53 +0200 > > * Eli Zaretskii: > > > If my arithmetics is correct, about 70% of its files is LGPL, the &g

Re: Change license of filenames.h to LGPL

> From: DJ Delorie > Cc: gcc-patches@gcc.gnu.org, e...@gnu.org, f...@deneb.enyo.de > Date: Tue, 27 Sep 2016 15:45:28 -0400 > > > I wonder if us relicensing our modified copy would apply to your old > copy. I mean, are we sure RMS knows you're also relicensing an old > copy,

Re: Change license of filenames.h to LGPL

> From: DJ Delorie > Cc: f...@deneb.enyo.de, gcc-patches@gcc.gnu.org, seze...@gmail.com > Date: Tue, 27 Sep 2016 15:23:46 -0400 > > > Why would it need to > > change? It's perfectly okay to link GPL code with LGPL code, we do > > this all the time with libgcc, no? Or am I

Re: Change license of filenames.h to LGPL

> From: DJ Delorie <d...@redhat.com> > Cc: f...@deneb.enyo.de, gcc-patches@gcc.gnu.org, seze...@gmail.com > Date: Tue, 27 Sep 2016 15:23:46 -0400 > > Eli Zaretskii <e...@gnu.org> writes: > >> But then the implementation would need relicensing as w

Re: Change license of filenames.h to LGPL

> From: DJ Delorie <d...@redhat.com> > Cc: gcc-patches@gcc.gnu.org, seze...@gmail.com > Date: Tue, 27 Sep 2016 15:00:46 -0400 > > > Eli Zaretskii <e...@gnu.org> writes: > > Because Ozkan wants to use it in an otherwise LGPL package. > > Ok, but that do

Re: Change license of filenames.h to LGPL

> From: Florian Weimer > Cc: DJ Delorie , gcc-patches@gcc.gnu.org, seze...@gmail.com > Date: Tue, 27 Sep 2016 20:54:59 +0200 > > >> Most of the files in include/ are GPL, not LGPL. Why is this one > >> different? > > > > Because Ozkan wants to use it in an

Re: Change license of filenames.h to LGPL

> Cc: gcc-patches@gcc.gnu.org, seze...@gmail.com > From: Jeff Law > Date: Tue, 27 Sep 2016 12:36:11 -0600 > > On 09/27/2016 11:52 AM, DJ Delorie wrote: > > > > Most of the files in include/ are GPL, not LGPL. Why is this one > > different? > Right. ANd it's not like this file

Re: Change license of filenames.h to LGPL

> From: DJ Delorie > Cc: gcc-patches@gcc.gnu.org, seze...@gmail.com > Date: Tue, 27 Sep 2016 13:52:10 -0400 > > > Most of the files in include/ are GPL, not LGPL. Why is this one > different? Because Ozkan wants to use it in an otherwise LGPL package.

Change license of filenames.h to LGPL

responses, as I'm not subscribed to this list. == Relicense include/filenames.h as LGPL2+. include/ChangeLog: 2016-09-24 Eli Zaretskii <e...@gnu.org> * filenames.h: Relicense as LGPL 2.1 or later. diff --git a/i

Fix make TAGS in libdecnumber

make TAGS in the GDB source tree fails because libdecnumber doesn't have a TAGS target. This patch fixes that: commit 53bef1c10759f1fd7faf675459871b2f4cc12e53 Author: Eli Zaretskii e...@gnu.org Date: Thu Jan 22 21:07:31 2015 +0200 Another part of fixing make TAGS. libdecnumber

Re: Fix a MinGW warning in libiberty/strerror.c

Date: Fri, 16 Jan 2015 16:39:20 -0500 From: DJ Delorie d...@redhat.com CC: ktiet...@googlemail.com, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org Thanks. Do I need to hear from someone else approving this, or can I go ahead and commit? Go ahead and commit. Thanks.

Re: Fix a MinGW warning in libiberty/strerror.c

Ping! Date: Fri, 02 Jan 2015 12:54:47 +0200 From: Eli Zaretskii e...@gnu.org When compiling GDB 7.8.1, I get this warning in libiberty: gcc -c -DHAVE_CONFIG_H -O0 -g3 -D__USE_MINGW_ACCESS -I. -I./../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic

Re: Fix a MinGW warning in libiberty/strerror.c

Date: Fri, 16 Jan 2015 12:34:25 +0100 From: Kai Tietz ktiet...@googlemail.com Cc: GCC Patches gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org gdb-patc...@sourceware.org Hi Eli, patch is reasonable and ok for me. Thanks. Do I need to hear from someone else approving this, or

Fix a MinGW warning in libiberty/strerror.c

When compiling GDB 7.8.1, I get this warning in libiberty: gcc -c -DHAVE_CONFIG_H -O0 -g3 -D__USE_MINGW_ACCESS -I. -I./../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ./strerror.c -o strerror.o ./strerror.c:472:12: warning: '_sys_nerr' redeclared

Re: [PATCH 1/2] Windows libibery: Don't quote args unnecessarily

Date: Sat, 19 Apr 2014 16:23:33 -0400 (EDT) From: Kai Tietz kti...@redhat.com Cc: gcc-patches@gcc.gnu.org, ktiet...@gmail.com, binut...@sourceware.org Development binut...@sourceware.org, gdb-patc...@sourceware.org + /* We only quote arguments that contain spaces, \n

Re: Fix a MinGW warning in libiberty/setenv.c

Date: Wed, 13 Mar 2013 11:52:48 -0700 From: Ian Lance Taylor i...@google.com Cc: gdb-patc...@sourceware.org, d...@redhat.com, gcc-patches@gcc.gnu.org On 3/13/13, Eli Zaretskii e...@gnu.org wrote: #ifdef __MSVCRT__ extern _CRTIMP char *** __cdecl __MINGW_NOTHROW __p__environ

Fox a MinGW warning in libiberty/setenv.c

I get this compiling the latest pretest of GDB 7.6 with MinGW: gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-2 -g3 -D__USE_MINGW_ACCESS -I. -I./../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ./setenv.c -o setenv.o ./setenv.c:66:1: warning: function declaration

Re: [RFA libiberty, gdb] Add hashtab support to filename_ncmp.c and use it in gdb.

Date: Fri, 13 Jul 2012 14:26:15 -0700 From: Doug Evans d...@google.com Cc: d...@redhat.com, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org Sorry if I'm missing something, but why do we need to advertise such a function at all? Given that libiberty already provides filename_cmp,

Re: [RFA libiberty, gdb] Add hashtab support to filename_ncmp.c and use it in gdb.

Date: Fri, 13 Jul 2012 12:36:44 -0700 From: Doug Evans d...@google.com Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org On Fri, Jul 13, 2012 at 12:21 PM, DJ Delorie d...@redhat.com wrote: I think it's confusing to have filename_cmp and filename_eq that do basically the same

Re: [RFA/libiberty] Darwin has case-insensitive filesystems

Date: Wed, 15 Jun 2011 06:59:11 -0400 From: Robert Dewar de...@adacore.com CC: vinsc...@redhat.com, d...@redhat.com, pins...@gmail.com, brobec...@adacore.com, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org or some piece of code in the toolchain arbitrarily changed the case of a

Re: [patch libiberty include]: Add additional helper functions for directory-separator searching

From: Pedro Alves pe...@codesourcery.com Date: Wed, 9 Mar 2011 11:46:36 + Cc: gdb-patc...@sourceware.org, d...@redhat.com, ktiet...@googlemail.com, binut...@sourceware.org, gcc-patches@gcc.gnu.org On Wednesday 09 March 2011 05:29:09, Eli Zaretskii wrote: Actually, is there any

Re: [patch libiberty include]: Add additional helper functions for directory-separator searching

From: Pedro Alves pe...@codesourcery.com Date: Wed, 9 Mar 2011 12:58:38 + Cc: gdb-patc...@sourceware.org, d...@redhat.com, ktiet...@googlemail.com, binut...@sourceware.org, gcc-patches@gcc.gnu.org The one's left are: 1 in a linux-native only file (never cares for other

Re: [patch libiberty include]: Add additional helper functions for directory-separator searching

Date: Tue, 8 Mar 2011 12:25:37 +0100 From: Kai Tietz ktiet...@googlemail.com Cc: binut...@sourceware.org, gdb-patc...@sourceware.org, gcc-patches@gcc.gnu.org Btw, why do we need filename_dirchr?  The use case for filename_dirrchr is clear, but in what situations will we need the

Re: [patch libiberty include]: Add additional helper functions for directory-separator searching

From: Pedro Alves pe...@codesourcery.com Date: Tue, 8 Mar 2011 13:33:02 + Cc: Kai Tietz ktiet...@googlemail.com, gcc-patches@gcc.gnu.org, Eli Zaretskii e...@gnu.org, binut...@sourceware.org On Tuesday 08 March 2011 12:48:11, Kai Tietz wrote: Well, a better example