From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4780 invoked by alias); 29 Mar 2013 02:08:47 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 4743 invoked by uid 89); 29 Mar 2013 02:08:39 -0000 X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from oarmail.oarcorp.com (HELO OARmail.OARCORP.com) (67.63.146.244) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 29 Mar 2013 02:08:36 +0000 Received: from OARmail.OARCORP.com ([192.168.2.2]) by OARmail.OARCORP.com ([192.168.2.2]) with mapi; Thu, 28 Mar 2013 21:08:34 -0500 From: Joel Sherrill To: Joel Brobecker CC: Eli Zaretskii , "gdb-patches@sourceware.org" , "vapier@gentoo.org" , Chris Johns Date: Fri, 29 Mar 2013 12:53:00 -0000 Subject: Re: one week to gdb-7.6 release? Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2013-03/txt/msg01096.txt.bz2 Does this mean that you can't build a mingw hosted cross compiler either na= tively on mingw or via Canadian cross? If so, I would consider that a serious regression and blocker. If I read your comment correctly, you consider it a blocker also. And is there a list somewhere of mingw issues? Like dv-socker.o, simulators= using POSIX signals and termios, etc.. Seems like a good GSOC project. --joel RTEMS Joel Brobecker wrote: > > The > > code in main.c already does > > > > #ifdef __MINGW32__ > > /* On Windows, argv[0] is not necessarily set to absolute form when > > GDB is found along PATH, without which relocation doesn't work. = */ > > gdb_program_name =3D windows_get_absolute_argv0 (argv[0]); > > #else > > gdb_program_name =3D xstrdup (argv[0]); > > #endif > > > > Is moving that to posix-hdep.c just to avoid an ifdef? > > The main purpose is to move the code away out of windows-nat, which > is only linked in native debuggers, not cross ones - so that building > a cross debugger hosted on Windows will work again. Basically, your > new function is really only dependent on the host, whereas the -nat > file makes the assumption that host & target are Windows. I have added this item to the TODO list for the 7.6 release, so as not to forget. I was wondering if this discussion was stalled, or if it was just a matter of not finding the time to do the implementation. I could possibly take care of it tomorrow if you'd like. There is not real rush, however, as I will be off next week, and thus unable to create a release at least until Tue Apr 9th. -- Joel