From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14438 invoked by alias); 17 Jan 2012 12:34:42 -0000 Received: (qmail 13512 invoked by uid 22791); 17 Jan 2012 12:34:38 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_DB X-Spam-Check-By: sourceware.org Received: from mail-iy0-f169.google.com (HELO mail-iy0-f169.google.com) (209.85.210.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Jan 2012 12:34:18 +0000 Received: by iadj38 with SMTP id j38so3289285iad.0 for ; Tue, 17 Jan 2012 04:34:18 -0800 (PST) Received: by 10.43.120.2 with SMTP id fw2mr13865965icc.37.1326803658181; Tue, 17 Jan 2012 04:34:18 -0800 (PST) Received: from [192.168.1.102] ([125.122.236.24]) by mx.google.com with ESMTPS id q30sm76973464ibc.1.2012.01.17.04.34.15 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 04:34:17 -0800 (PST) Message-ID: <4F156BDE.6030609@gmail.com> Date: Tue, 17 Jan 2012 13:40: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> In-Reply-To: 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/msg00590.txt.bz2 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