From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11172 invoked by alias); 17 Jan 2012 13:42:38 -0000 Received: (qmail 11160 invoked by uid 22791); 17 Jan 2012 13:42:37 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_DB,TW_SM X-Spam-Check-By: sourceware.org Received: from mail-gx0-f169.google.com (HELO mail-gx0-f169.google.com) (209.85.161.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Jan 2012 13:42:24 +0000 Received: by ggnp4 with SMTP id p4so3627197ggn.0 for ; Tue, 17 Jan 2012 05:42:23 -0800 (PST) Received: by 10.50.217.168 with SMTP id oz8mr14915514igc.24.1326807743293; Tue, 17 Jan 2012 05:42:23 -0800 (PST) Received: from [192.168.1.102] ([125.122.236.24]) by mx.google.com with ESMTPS id 36sm77472070ibc.6.2012.01.17.05.42.20 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 05:42:21 -0800 (PST) Message-ID: <4F157BD3.4020009@gmail.com> Date: Tue, 17 Jan 2012 14:15:00 -0000 From: asmwarrior User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Doug Evans CC: gdb-patches@sourceware.org Subject: Re: Possible fix for mingw32 directory relocation problems References: <4f143c53.ca3c440a.1d95.ffff9b71SMTPIN_ADDED@mx.google.com> <4F156BDE.6030609@gmail.com> In-Reply-To: <4F156BDE.6030609@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2012-01/txt/msg00592.txt.bz2 On 2012-1-17 20:38, asmwarrior wrote: > On 2012-1-17 15:00, Doug Evans wrote: >> Possible patch is attached. Can you try it? I don't know that it will fix things, but based on what you've said it seems reasonable to try. There is an open issue that the current --with-sysroot relocatability computation is different than what GDB_AC_WITH_DIR does. We should fix that regardless. I've left that as a separate issue. [We should resolve it before checkin, but at this point I'm willing to just experiment until we know what the right fix is.] >>> I don't have enough knowledge about autoconf scripts to >>> handle this... >>> An extra bonus of this change would be that it would >>> render the special rule for main.o compilation unnecessary. > Would you mind to give a full patch (include the diff of configure and config.in). > Under MSYS+autotools > I have problems generate those files by reference: > http://sourceware.org/gdb/wiki/DeveloperTips#Editing_configure.ac > > $ aclocal -I gnulib/m4 > acinclude.m4:84: the serial number must appear before any macro definition > configure.ac:22: error: Please use exactly Autoconf 2.64 instead of 2.68. > ../config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from... > configure.ac:22: the top level > autom4te: /bin/m4 failed with exit status: 1 > aclocal: autom4te failed with exit status: 1 > > Thanks. > > asmwarrior > ollydbg from codeblocks' forum > OK, I just use such change, and regenerate the configure under autotools 2.68. config/override.m4 | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/config/override.m4 b/config/override.m4 index 52bd1c3..4ade55c 100644 --- a/config/override.m4 +++ b/config/override.m4 @@ -29,7 +29,7 @@ m4_copy_force([_AC_PREREQ], [AC_PREREQ]) dnl Ensure exactly this Autoconf version is used m4_ifndef([_GCC_AUTOCONF_VERSION], - [m4_define([_GCC_AUTOCONF_VERSION], [2.64])]) + [m4_define([_GCC_AUTOCONF_VERSION], [2.68])]) dnl Test for the exact version when AC_INIT is expanded. dnl This allows to update the tree in steps (for testing) I just test your patch, and it works Fine under Windows!!! (gdb relocation works OK!) Thank you!! asmwarrior ollydbg from codeblocks' forum