From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10248 invoked by alias); 17 Jan 2012 01:08:03 -0000 Received: (qmail 10239 invoked by uid 22791); 17 Jan 2012 01:08:02 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-we0-f169.google.com (HELO mail-we0-f169.google.com) (74.125.82.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Jan 2012 01:07:39 +0000 Received: by werl4 with SMTP id l4so1386736wer.0 for ; Mon, 16 Jan 2012 17:07:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.139.71 with SMTP id b49mr4841170wej.47.1326762458226; Mon, 16 Jan 2012 17:07:38 -0800 (PST) Received: by 10.216.132.198 with HTTP; Mon, 16 Jan 2012 17:07:38 -0800 (PST) In-Reply-To: <4f143c35.4fecd80a.473e.ffffbd75SMTPIN_ADDED@mx.google.com> References: <4f143c35.4fecd80a.473e.ffffbd75SMTPIN_ADDED@mx.google.com> Date: Tue, 17 Jan 2012 02:49:00 -0000 Message-ID: Subject: Re: Possible fix for mingw32 directory relocation problems From: asm warrior To: Pierre Muller Cc: gdb-patches@sourceware.org, Eli Zaretskii , Tom Tromey Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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/msg00582.txt.bz2 On Mon, Jan 16, 2012 at 11:03 PM, Pierre Muller wrote: > > =C2=A0After some debugging, > we finally managed to find out that > mingw32 specific directory relocations are related > to msys -> mingw32 argument conversions. > > http://sourceware.org/ml/gdb-patches/2012-01/msg00537.html > > This is explained in: > > http://www.mingw.org/wiki/Posix_path_conversion > > This page also allows to understand why > using mingw32 style paths for prefix at configure > level works and avoid the troubles encountered. > > This conversion concerns defines passed by command line arguments > to gcc, which are specific to main.o > compilation, as found in gdb/Makefile.in > 1520- > 1521:# main.o needs an explicit build rule to get TARGET_SYSTEM_ROOT and > BINDIR. > 1522-main.o: $(srcdir)/main.c > 1523: =C2=A0 $(COMPILE) $(TARGET_SYSTEM_ROOT_DEFINE) -DBINDIR=3D\"$(bindi= r)\" > $(srcdir)/main.c > 1524- =C2=A0 $(POSTCOMPILE) > 1525- > > =C2=A0But this leads to a conversion: > =C2=A0-DBINDIR=3D"/usr/local/bin\" > gets transformed into '-D' 'BINDIR=3D"E:/msys/mingw32/msys/1.0/local/bin"' > > =C2=A0While other pates used in relocate_gdb_directory calls > are macros defined inside gdb/config.h > > config.h:#define DEBUGDIR "/usr/local/lib/debug" > config.h:#define GDB_DATADIR "/usr/local/share/gdb" > config.h:#define JIT_READER_DIR "/usr/local/lib/gdb" > > Those are of course not affected by msys command-line argument conversion. > > =C2=A0The first question is: > Why do we need to pass BINDIR (and TARGET_SYSTEM_ROOT_DEFINE) > at the command line instead of inside config.h as for other > directories? > > =C2=A0If the answer to the first question is "we don't", > then I need help about how to convert those > Makefile.in variables into new entries of generated config.h file. I agree that we don't need BINDIR=3Dxxxxx in the compiler command line opti= on. > > =C2=A0I don't have enough knowledge about autoconf scripts to > handle this... > =C2=A0An extra bonus of this change would be that it would > render the special rule for main.o compilation unnecessary. > > Comments most welcome and help needed... > > Pierre Muller > GDB pascal language maintainer > > I'm not quite familiar with autoconf either. So, suppose we can put BINDIR in config.h, I think we still have some problem. Those values (DEBUGDIR, GDB_DATADIR, JIT_READER_DIR, BINDIR) were macro definition strings, so there are location are still fixed. But under Windows, I think there are many conditions that gdb.exe and other related gdb's share folder will be copied and pasted to many different paths. So, a true relocate scheme is still necessary. asmwarrior