> I ended up not having time before going on holiday. If the resync
> hasn't already been done, I'll do it now.
Thanks for doing that, Iain!
--
Joel
On 30 May 2017 at 19:10, Joel Brobecker wrote:
>> This has been on my todo-list for a little while, as re-syncing is
>> something I normally do after pushing D language support updates into
>> libiberty. However I decided to give it a wait until I got all
>> pending patches in, the last of which
> This has been on my todo-list for a little while, as re-syncing is
> something I normally do after pushing D language support updates into
> libiberty. However I decided to give it a wait until I got all
> pending patches in, the last of which I'm just pushing in now.
That's very kind of you to
On 26 May 2017 at 18:30, Joel Brobecker wrote:
>> 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?
>
> Normally, I'd expect someone pushing to GCC's libibert to also
> update our repo accordingly. Howev
> What can I do to expedite the process? This currently holds the 8.0
> release, and I'm uneasy to be the culprit.
The way I usually do it is grab the commit in GCC, and apply it
as is in the GDB repository. To make it easier, I use the git
mirror of the GCC repository, because I can then just ad
Joel Brobecker writes:
> Normally, I'd expect someone pushing to GCC's libibert to also
> update our repo accordingly.
Note that I used to auto-sync libiberty from gcc to binutils/gdb, but
when binutils/gdb switched to git, that script broke, and as I don't
like using git, I announced that I wou
> 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 easy to forget so,
> if you notice a change
> 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?
Normally, I'd expect someone pushing to GCC's libibert to also
update our repo accordingly. However, it's easy to forget so,
if you notice a change that
> 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?
Thanks. Committed!
> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Tue, 23 May 2017 22:26:22 -0400
>
> > Is there anything else I need to do about this part to get it solved
> > in the upstream repository?
>
> A ChangeLog entry would be nice, so I don't have to write one ;-)
S
Eli Zaretskii writes:
>> What about mingw64?
>
> It will be covered as well, because it defines __MINGW32__,
Ah, OK.
> Is there anything else I need to do about this part to get it solved
> in the upstream repository?
A ChangeLog entry would be nice, so I don't have to write one ;-)
> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Tue, 23 May 2017 15:37:32 -0400
>
>
> Eli Zaretskii writes:
> > Instead of making waitpid an always-failing stub on MinGW, wouldn't it
> > be better to make it work on MinGW? Like this:
>
> That's up to you,
Eli Zaretskii writes:
> Instead of making waitpid an always-failing stub on MinGW, wouldn't it
> be better to make it work on MinGW? Like this:
That's up to you, if it's target-specific. What about mingw64?
> --- libiberty/waitpid.c~0 2016-08-01 18:50:21.0 +0300
> +++ libiberty/wa
> 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 use some #ifdefs to
Eli Zaretskii writes:
> Hmm... no, this doesn't solve the problem. The expansion of AC_LIBOBJ
> for waitpid is gone from the configure script, but the value of
> LIBOBJS in libiberty/Makefile still includes waitpid.o. What else is
> related to this?
After re-reading the sources a bit, I come t
> From: DJ Delorie
> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
> Date: Fri, 19 May 2017 21:28:25 -0400
>
>
> Please try this patch, since my mingw environment is old:
>
> Index: libiberty/ChangeLog
> ===
> --- libiber
Please try this patch, since my mingw environment is old:
Index: libiberty/ChangeLog
===
--- libiberty/ChangeLog (revision 248307)
+++ libiberty/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2017-05-19 Eli Zaretskii
+
+ * configu
> 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.
On 05/08/2017 04:27 PM, Eli Zaretskii wrote:
> 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-prototype
20 matches
Mail list logo
