Re: Possible fix for mingw32 directory relocation problems

Re: Possible fix for mingw32 directory relocation problems

[Doug Evans]

[-- Attachment #1: Type: text/plain, Size: 2570 bytes --]

On Mon, Jan 16, 2012 at 7:03 AM, Pierre Muller
<pierre.muller@ics-cnrs.unistra.fr> wrote:
>  After some debugging,
> we finally managed to find out that
> mingw32 specific directory relocations are related
> to msys -> mingw32 argument conversions.

Thanks for the detective work!

> 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:   $(COMPILE) $(TARGET_SYSTEM_ROOT_DEFINE) -DBINDIR=\"$(bindir)\"
> $(srcdir)/main.c
> 1524-   $(POSTCOMPILE)
> 1525-
>
>  But this leads to a conversion:
>  -DBINDIR="/usr/local/bin\"
> gets transformed into '-D' 'BINDIR="E:/msys/mingw32/msys/1.0/local/bin"'
>
>  While 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.
>
>  The 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?

We don't need to pass them on the command line.

>  If 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.

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.

[-- Attachment #2: mingw-config.patch --]
[-- Type: application/octet-stream, Size: 3884 bytes --]

2012-01-16  Doug Evans  <dje@sebabeach.org>

	* Makefile.in (TARGET_SYSTEM_ROOT, TARGET_SYSTEM_ROOT_DEFINE): Delete.
	(main.o): Remove rule.
	* configure.ac (BINDIR): Define in config.h.
	(--with-sysroot): Define using GDB_AC_WITH_DIR.
	* configure: Regenerate.
	* config.in: Regenerate.

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.1186
diff -u -p -r1.1186 Makefile.in
--- Makefile.in	10 Jan 2012 16:30:43 -0000	1.1186
+++ Makefile.in	17 Jan 2012 06:42:31 -0000
@@ -166,10 +166,6 @@ INTL = @LIBINTL@
 INTL_DEPS = @LIBINTL_DEP@
 INTL_CFLAGS = @INCINTL@
 
-# Did the user give us a --with-sysroot option?
-TARGET_SYSTEM_ROOT = @TARGET_SYSTEM_ROOT@
-TARGET_SYSTEM_ROOT_DEFINE = @TARGET_SYSTEM_ROOT_DEFINE@
-
 # Did the user give us a --with-gdb-datadir option?
 GDB_DATADIR = @GDB_DATADIR@
 
@@ -1518,11 +1514,6 @@ ALLDEPFILES = \
 # Some files need explicit build rules (due to -Werror problems) or due
 # to sub-directory fun 'n' games.
 
-# main.o needs an explicit build rule to get TARGET_SYSTEM_ROOT and BINDIR.
-main.o: $(srcdir)/main.c
-	$(COMPILE) $(TARGET_SYSTEM_ROOT_DEFINE) -DBINDIR=\"$(bindir)\" $(srcdir)/main.c
-	$(POSTCOMPILE)
-
 # FIXME: cagney/2003-08-10: "monitor.c" gets -Wformat-nonliteral
 # errors.  It turns out that that is the least of monitor.c's
 # problems.  The function print_vsprintf appears to be using
Index: configure.ac
===================================================================
RCS file: /cvs/src/src/gdb/configure.ac,v
retrieving revision 1.152
diff -u -p -r1.152 configure.ac
--- configure.ac	4 Jan 2012 08:17:00 -0000	1.152
+++ configure.ac	17 Jan 2012 06:42:32 -0000
@@ -125,6 +125,14 @@ GDB_AC_WITH_DIR(DEBUGDIR, separate-debug
     [look for global separate debug info in this path @<:@LIBDIR/debug@:>@],
     [${libdir}/debug])
 
+# We can't pass paths as command line arguments.
+# Mingw32 tries to be clever and will convert the paths for us.
+# For example -DBINDIR="/usr/local/bin" passed on the command line may get
+# converted to  -DBINDIR="E:/msys/mingw32/msys/1.0/local/bin".
+# This breaks GDB's relocatable path conversions since paths passed in
+# config.h do not get so translated.
+AC_DEFINE_DIR(BINDIR, bindir, [Directory of programs.])
+
 # GDB's datadir relocation
 
 GDB_AC_WITH_DIR(GDB_DATADIR, gdb-datadir,
@@ -1753,42 +1761,12 @@ fi
 
 dnl Handle optional features that can be enabled.
 
-target_sysroot_reloc=0
-AC_ARG_WITH(sysroot,
-AS_HELP_STRING([--with-sysroot@<:@=DIR@:>@], [search for usr/lib et al within DIR]),
-[
- case ${with_sysroot} in
- yes) TARGET_SYSTEM_ROOT='${exec_prefix}/${target_alias}/sys-root' ;;
- *) TARGET_SYSTEM_ROOT=$with_sysroot ;;
- esac
-
- TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=\"$(TARGET_SYSTEM_ROOT)\"'
-
- if test "x$prefix" = xNONE; then
-  test_prefix=/usr/local
- else
-  test_prefix=$prefix
- fi
- if test "x$exec_prefix" = xNONE || test "x$exec_prefix" = 'x${prefix}'; then
-  test_exec_prefix=$test_prefix
- else
-  test_exec_prefix=$exec_prefix
- fi
- case ${TARGET_SYSTEM_ROOT} in
- "${test_prefix}"|"${test_prefix}/"*|\
- "${test_exec_prefix}"|"${test_exec_prefix}/"*|\
- '${prefix}'|'${prefix}/'*|\
- '${exec_prefix}'|'${exec_prefix}/'*)
-   target_sysroot_reloc=1
-   ;;
- esac
-], [
- TARGET_SYSTEM_ROOT=
- TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=\"\"'
-])
-TARGET_SYSTEM_ROOT_DEFINE="$TARGET_SYSTEM_ROOT_DEFINE -DTARGET_SYSTEM_ROOT_RELOCATABLE=$target_sysroot_reloc"
-AC_SUBST(TARGET_SYSTEM_ROOT)
-AC_SUBST(TARGET_SYSTEM_ROOT_DEFINE)
+if test "x$with_sysroot" = xyes; then
+  with_sysroot="${exec_prefix}/${target_alias}/sys-root"
+fi
+GDB_AC_WITH_DIR(TARGET_SYSTEM_ROOT, sysroot,
+    [search for usr/lib et al within PATH],
+    [])
 
 GDB_AC_WITH_DIR(SYSTEM_GDBINIT, system-gdbinit,
     [automatically load a system-wide gdbinit file],

Re: Possible fix for mingw32 directory relocation problems

[asmwarrior]

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

Re: Possible fix for mingw32 directory relocation problems

[asmwarrior]

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

RE: Possible fix for mingw32 directory relocation problems

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Doug Evans
> Envoyé : mardi 17 janvier 2012 08:00
> À : Pierre Muller
> Cc : gdb-patches@sourceware.org; Eli Zaretskii; asmwarrior@gmail.com; Tom
> Tromey
> Objet : Re: Possible fix for mingw32 directory relocation problems
> 
> On Mon, Jan 16, 2012 at 7:03 AM, Pierre Muller
> <pierre.muller@ics-cnrs.unistra.fr> wrote:
> >  After some debugging,
> > we finally managed to find out that
> > mingw32 specific directory relocations are related
> > to msys -> mingw32 argument conversions.
> 
> Thanks for the detective work!

  I always liked to debug GDB with itself!
 
> > 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:   $(COMPILE) $(TARGET_SYSTEM_ROOT_DEFINE) -DBINDIR=\"$(bindir)\"
> > $(srcdir)/main.c
> > 1524-   $(POSTCOMPILE)
> > 1525-
> >
> >  But this leads to a conversion:
> >  -DBINDIR="/usr/local/bin\"
> > gets transformed into '-D' 'BINDIR="E:/msys/mingw32/msys/1.0/local/bin"'
> >
> >  While 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.
> >
> >  The 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?
> 
> We don't need to pass them on the command line.
> 
> >  If 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.
> 
> 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.

  I tried it...
But got really into troubles to regenerate configure and config.in using
Cygwin
installation...
  I finally discovered gcc-tools-epoch2 cygwin package
that allowed me to successfully regenerate configure and config.in

  After that I did recompile and install gdb into e:\pas\fpc-2.7.1 directory
by specifying --prefix=/e/pas/fpc-2.7.1
(I tested with --preficx=e:/pas/fpc-2.4.4, which worked the same)

E:\pas\fpc-2.7.1\gdb>cd bin

E:\pas\fpc-2.7.1\gdb\bin>.\gdb ./gdb
GNU gdb (GDB) 7.4.50.20120117-cvs
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from E:\pas\fpc-2.7.1\gdb\bin\gdb.exe...done.
(gdb) py print gdb.PYTHONDIR
e:\pas\fpc-2.7.1\gdb\share\gdb/python
(gdb) py
>end
(gdb) q

E:\pas\fpc-2.7.1\gdb\bin>cd ..\..

E:\pas\fpc-2.7.1>cp -Rf gdb ..\fpc-2.6.0

E:\pas\fpc-2.7.1>cd ..\fpc-2.6.0\gdb\bin

E:\pas\fpc-2.6.0\gdb\bin>.\gdb ./gdb
GNU gdb (GDB) 7.4.50.20120117-cvs
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from E:\pas\fpc-2.6.0\gdb\bin\gdb.exe...done.
(gdb) py print gdb.PYTHONDIR
e:\pas\fpc-2.6.0\gdb\share\gdb/python
(gdb)

So the basic idea of rebasing gdb/python seems to work,
the next problem is that I never used python scripts
so that I didn't know what else to do to check that this directory is really
functional!
 
> 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 have really no idea about sysroot issue,
but the main point is the relocation flag is set to zero,
meaning that make_relative_prefix is not called there.

  From what I tested, I would say that this is an improvement for 
mingw32 GDB...

  Nevertheless, if you run gdb directly in the compilation directory,
you will notice the GDB_DATADIR macro set to  '/usr/local/share/gdb' in
config.h
into 'e:\usr\local\share\gdb'
due to a call to lrealpath which calls GetFullPathName if __WIN32 is
defined.

  Thus, I wonder if the correct solution should not be to
convert all the paths in config.h to mingw32 type at configure time.
But, once again, I don't really know how to do this....

  I went on to try to use this to test mingw64 Windows-64bit GDB debugger
using Cygwin cross-compiler x86_64-w64-mingw32 target, but
I couldn't get configure to accept the Windows 64-bit 2.7 python...
apparently because not libpython2.7.a is included in the distribution
(the library is, according to web search, non-functional...)
Does anyone know howto force python use for cygwin to mingw64 cross
compilation of GDB?


Pierre Muller

Re: Possible fix for mingw32 directory relocation problems

[asmwarrior]

On 2012-1-17 22:49, Pierre Muller 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.
>    I tried it...
> But got really into troubles to regenerate configure and config.in using
> Cygwin
> installation...
>    I finally discovered gcc-tools-epoch2 cygwin package
> that allowed me to successfully regenerate configure and config.in
I just use MSYS+autotools 2.68 to generate configure and config.in under src/gdb. I changed one file, see the change:
http://sourceware.org/ml/gdb-patches/2012-01/msg00591.html

The trick is that MSYS does not supply autoconf version 2.64, they have 2.63 and 2.65, but I'm not sure why 2.64 is skipped.

>    After that I did recompile and install gdb into e:\pas\fpc-2.7.1 directory
> by specifying --prefix=/e/pas/fpc-2.7.1
> (I tested with --preficx=e:/pas/fpc-2.4.4, which worked the same)
>
> E:\pas\fpc-2.7.1\gdb>cd bin
>
> E:\pas\fpc-2.7.1\gdb\bin>.\gdb ./gdb
> GNU gdb (GDB) 7.4.50.20120117-cvs
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-pc-mingw32".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from E:\pas\fpc-2.7.1\gdb\bin\gdb.exe...done.
> (gdb) py print gdb.PYTHONDIR
> e:\pas\fpc-2.7.1\gdb\share\gdb/python
> (gdb) py
>> end
> (gdb) q
>
> E:\pas\fpc-2.7.1\gdb\bin>cd ..\..
>
> E:\pas\fpc-2.7.1>cp -Rf gdb ..\fpc-2.6.0
>
> E:\pas\fpc-2.7.1>cd ..\fpc-2.6.0\gdb\bin
>
> E:\pas\fpc-2.6.0\gdb\bin>.\gdb ./gdb
> GNU gdb (GDB) 7.4.50.20120117-cvs
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-pc-mingw32".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from E:\pas\fpc-2.6.0\gdb\bin\gdb.exe...done.
> (gdb) py print gdb.PYTHONDIR
> e:\pas\fpc-2.6.0\gdb\share\gdb/python
> (gdb)
>
> So the basic idea of rebasing gdb/python seems to work,
> the next problem is that I never used python scripts
> so that I didn't know what else to do to check that this directory is really
> functional!
There are many python printer related function under the share folder of gdb, the simply one is "info pretty-printer", but there are many other commands.

If the gdb's own python script does NOT loaded correctly, when you run "info pretty-printer", gdb will say that there is not such command.

asmwarrior
ollydbg from codeblocks' forum

Re: Possible fix for mingw32 directory relocation problems

[Doug Evans]

On Tue, Jan 17, 2012 at 6:49 AM, Pierre Muller
<pierre.muller@ics-cnrs.unistra.fr> wrote:
>  Nevertheless, if you run gdb directly in the compilation directory,
> you will notice the GDB_DATADIR macro set to  '/usr/local/share/gdb' in
> config.h
> into 'e:\usr\local\share\gdb'
> due to a call to lrealpath which calls GetFullPathName if __WIN32 is
> defined.

A similar thing happens when running gdb from the build directory on
all systems,
this is not win32 specific.
GDB does not (currently) automagically support it.

>  Thus, I wonder if the correct solution should not be to
> convert all the paths in config.h to mingw32 type at configure time.
> But, once again, I don't really know how to do this....

When running gdb from the build directory,
pass -data-directory=$build_directory/data-directory.

>  I went on to try to use this to test mingw64 Windows-64bit GDB debugger
> using Cygwin cross-compiler x86_64-w64-mingw32 target, but
> I couldn't get configure to accept the Windows 64-bit 2.7 python...
> apparently because not libpython2.7.a is included in the distribution
> (the library is, according to web search, non-functional...)
> Does anyone know howto force python use for cygwin to mingw64 cross
> compilation of GDB?

I'm not sure the issue I'm referring to below is the issue you're
running into, but Python doesn't handle cross compilation very well,
and one workaround is the following hack.
When configuring gdb pass --with-python=/path/to/config-python-hack,
where /path/to/config-python-hack is a script like the following:
[edit the paths in this example to match your environment]

#! /bin/sh

if [ $# -ne 2 ]
then
        echo "Bad # args.  Blech!" >&2
        exit 1
fi

# The first argument is the path to python-config.py, ignore it.

case "$2" in
--includes) echo "-I/usr/include/python2.6 -I/usr/include/python2.6" ;;
--ldflags) echo "-L/usr/lib/python2.6/config -lpthread -ldl -lutil -lm
-lpython2.6" ;;
--exec-prefix) echo "/usr" ;;
*) echo "Bad arg $2.  Blech!" >&2 ; exit 1 ;;
esac

exit 0

Re: Possible fix for mingw32 directory relocation problems

[Doug Evans]

[-- Attachment #1: Type: text/plain, Size: 5884 bytes --]

On Tue, Jan 17, 2012 at 6:49 AM, Pierre Muller
<pierre.muller@ics-cnrs.unistra.fr> wrote:
>
>
>> -----Message d'origine-----
>> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
>> owner@sourceware.org] De la part de Doug Evans
>> Envoyé : mardi 17 janvier 2012 08:00
>> À : Pierre Muller
>> Cc : gdb-patches@sourceware.org; Eli Zaretskii; asmwarrior@gmail.com; Tom
>> Tromey
>> Objet : Re: Possible fix for mingw32 directory relocation problems
>>
>> On Mon, Jan 16, 2012 at 7:03 AM, Pierre Muller
>> <pierre.muller@ics-cnrs.unistra.fr> wrote:
>> >  After some debugging,
>> > we finally managed to find out that
>> > mingw32 specific directory relocations are related
>> > to msys -> mingw32 argument conversions.
>>
>> Thanks for the detective work!
>
>  I always liked to debug GDB with itself!
>
>> > 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:   $(COMPILE) $(TARGET_SYSTEM_ROOT_DEFINE) -DBINDIR=\"$(bindir)\"
>> > $(srcdir)/main.c
>> > 1524-   $(POSTCOMPILE)
>> > 1525-
>> >
>> >  But this leads to a conversion:
>> >  -DBINDIR="/usr/local/bin\"
>> > gets transformed into '-D' 'BINDIR="E:/msys/mingw32/msys/1.0/local/bin"'
>> >
>> >  While 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.
>> >
>> >  The 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?
>>
>> We don't need to pass them on the command line.
>>
>> >  If 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.
>>
>> 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.
>
>  I tried it...
> But got really into troubles to regenerate configure and config.in using
> Cygwin
> installation...
>  I finally discovered gcc-tools-epoch2 cygwin package
> that allowed me to successfully regenerate configure and config.in
>
>  After that I did recompile and install gdb into e:\pas\fpc-2.7.1 directory
> by specifying --prefix=/e/pas/fpc-2.7.1
> (I tested with --preficx=e:/pas/fpc-2.4.4, which worked the same)
>
> E:\pas\fpc-2.7.1\gdb>cd bin
>
> E:\pas\fpc-2.7.1\gdb\bin>.\gdb ./gdb
> GNU gdb (GDB) 7.4.50.20120117-cvs
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-pc-mingw32".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from E:\pas\fpc-2.7.1\gdb\bin\gdb.exe...done.
> (gdb) py print gdb.PYTHONDIR
> e:\pas\fpc-2.7.1\gdb\share\gdb/python
> (gdb) py
>>end
> (gdb) q
>
> E:\pas\fpc-2.7.1\gdb\bin>cd ..\..
>
> E:\pas\fpc-2.7.1>cp -Rf gdb ..\fpc-2.6.0
>
> E:\pas\fpc-2.7.1>cd ..\fpc-2.6.0\gdb\bin
>
> E:\pas\fpc-2.6.0\gdb\bin>.\gdb ./gdb
> GNU gdb (GDB) 7.4.50.20120117-cvs
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-pc-mingw32".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from E:\pas\fpc-2.6.0\gdb\bin\gdb.exe...done.
> (gdb) py print gdb.PYTHONDIR
> e:\pas\fpc-2.6.0\gdb\share\gdb/python
> (gdb)
>
> So the basic idea of rebasing gdb/python seems to work,
> the next problem is that I never used python scripts
> so that I didn't know what else to do to check that this directory is really
> functional!

Here is the patch I committed.
Tested on amd64-linux with various values for --with-sysroot.

The test the previous code was using to compute the relocability of
TARGET_SYSTEM_ROOT, is, AFAICT, excessively complex.
main.c treats TARGET_SYSTEM_ROOT no different than other relocatable
dirs, so I went with what GDB_AC_WITH_DIR does.
Alas I can't just use GDB_AC_WITH_DIR as the help output will be
wrong, and I didn't want to add another argument to GDB_AC_WITH_DIR
and update all its callers just for this.  Still, I think this is an
improvement.
Thanks again for the detective work.

2012-01-18  Doug Evans  <dje@sebabeach.org>

        * Makefile.in (TARGET_SYSTEM_ROOT, TARGET_SYSTEM_ROOT_DEFINE): Delete.
        (main.o): Remove rule.
        * configure.ac (BINDIR): Define with AC_DEFINE_DIR.
        (--with-sysroot): Rewrite.
        * configure: Regenerate.
        * config.in: Regenerate.

[-- Attachment #2: gdb-120118-mingw-sysroot-config-1.patch.txt --]
[-- Type: text/plain, Size: 8666 bytes --]

2012-01-16  Doug Evans  <dje@sebabeach.org>

	* Makefile.in (TARGET_SYSTEM_ROOT, TARGET_SYSTEM_ROOT_DEFINE): Delete.
	(main.o): Remove rule.
	* configure.ac (BINDIR): Define with AC_DEFINE_DIR.
	(--with-sysroot): Rewrite.
	* configure: Regenerate.
	* config.in: Regenerate.

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.1186
diff -u -p -r1.1186 Makefile.in
--- Makefile.in	10 Jan 2012 16:30:43 -0000	1.1186
+++ Makefile.in	18 Jan 2012 18:18:40 -0000
@@ -166,10 +166,6 @@ INTL = @LIBINTL@
 INTL_DEPS = @LIBINTL_DEP@
 INTL_CFLAGS = @INCINTL@
 
-# Did the user give us a --with-sysroot option?
-TARGET_SYSTEM_ROOT = @TARGET_SYSTEM_ROOT@
-TARGET_SYSTEM_ROOT_DEFINE = @TARGET_SYSTEM_ROOT_DEFINE@
-
 # Did the user give us a --with-gdb-datadir option?
 GDB_DATADIR = @GDB_DATADIR@
 
@@ -1518,11 +1514,6 @@ ALLDEPFILES = \
 # Some files need explicit build rules (due to -Werror problems) or due
 # to sub-directory fun 'n' games.
 
-# main.o needs an explicit build rule to get TARGET_SYSTEM_ROOT and BINDIR.
-main.o: $(srcdir)/main.c
-	$(COMPILE) $(TARGET_SYSTEM_ROOT_DEFINE) -DBINDIR=\"$(bindir)\" $(srcdir)/main.c
-	$(POSTCOMPILE)
-
 # FIXME: cagney/2003-08-10: "monitor.c" gets -Wformat-nonliteral
 # errors.  It turns out that that is the least of monitor.c's
 # problems.  The function print_vsprintf appears to be using
Index: config.in
===================================================================
RCS file: /cvs/src/src/gdb/config.in,v
retrieving revision 1.130
diff -u -p -r1.130 config.in
--- config.in	12 Jan 2012 23:38:47 -0000	1.130
+++ config.in	18 Jan 2012 18:18:40 -0000
@@ -7,6 +7,9 @@
 /* Define if building universal (internal helper macro) */
 #undef AC_APPLE_UNIVERSAL_BUILD
 
+/* Directory of programs. */
+#undef BINDIR
+
 /* Define to the number of bits in type 'ptrdiff_t'. */
 #undef BITSIZEOF_PTRDIFF_T
 
@@ -854,6 +857,12 @@
    moved. */
 #undef SYSTEM_GDBINIT_RELOCATABLE
 
+/* search for usr/lib et al within DIR */
+#undef TARGET_SYSTEM_ROOT
+
+/* Define if the sysroot directory should be relocated when GDB is moved. */
+#undef TARGET_SYSTEM_ROOT_RELOCATABLE
+
 /* Define if <thread_db.h> has the TD_NOTALLOC error code. */
 #undef THREAD_DB_HAS_TD_NOTALLOC
 
Index: configure
===================================================================
RCS file: /cvs/src/src/gdb/configure,v
retrieving revision 1.337
diff -u -p -r1.337 configure
--- configure	12 Jan 2012 23:38:47 -0000	1.337
+++ configure	18 Jan 2012 18:18:40 -0000
@@ -654,7 +654,6 @@ SER_HARDWIRE
 WERROR_CFLAGS
 WARN_CFLAGS
 SYSTEM_GDBINIT
-TARGET_SYSTEM_ROOT_DEFINE
 TARGET_SYSTEM_ROOT
 CONFIG_LDFLAGS
 RDYNAMIC
@@ -7900,6 +7899,24 @@ _ACEOF
 
 
 
+# We can't pass paths as command line arguments.
+# Mingw32 tries to be clever and will convert the paths for us.
+# For example -DBINDIR="/usr/local/bin" passed on the command line may get
+# converted to -DBINDIR="E:/msys/mingw32/msys/1.0/local/bin".
+# This breaks GDB's relocatable path conversions since paths passed in
+# config.h would not get so translated, the path prefixes no longer match.
+
+  test "x$prefix" = xNONE && prefix="$ac_default_prefix"
+  test "x$exec_prefix" = xNONE && exec_prefix='${prefix}'
+  ac_define_dir=`eval echo $bindir`
+  ac_define_dir=`eval echo $ac_define_dir`
+
+cat >>confdefs.h <<_ACEOF
+#define BINDIR "$ac_define_dir"
+_ACEOF
+
+
+
 # GDB's datadir relocation
 
 
@@ -15043,45 +15060,53 @@ $as_echo "#define HAVE_PERSONALITY 1" >>
 fi
 
 
-target_sysroot_reloc=0
+# Support for --with-sysroot is a copy of GDB_AC_WITH_DIR,
+# except that the argument to --with-sysroot is optional.
+# --with-sysroot (or --with-sysroot=yes) sets the default sysroot path.
+if test "x$with_sysroot" = xyes; then
+  with_sysroot="${exec_prefix}/${target_alias}/sys-root"
+fi
 
 # Check whether --with-sysroot was given.
 if test "${with_sysroot+set}" = set; then :
-  withval=$with_sysroot;
- case ${with_sysroot} in
- yes) TARGET_SYSTEM_ROOT='${exec_prefix}/${target_alias}/sys-root' ;;
- *) TARGET_SYSTEM_ROOT=$with_sysroot ;;
- esac
+  withval=$with_sysroot; TARGET_SYSTEM_ROOT=$withval
+else
+  TARGET_SYSTEM_ROOT=
+fi
 
- TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=\"$(TARGET_SYSTEM_ROOT)\"'
 
- if test "x$prefix" = xNONE; then
-  test_prefix=/usr/local
- else
-  test_prefix=$prefix
- fi
- if test "x$exec_prefix" = xNONE || test "x$exec_prefix" = 'x${prefix}'; then
-  test_exec_prefix=$test_prefix
- else
-  test_exec_prefix=$exec_prefix
- fi
- case ${TARGET_SYSTEM_ROOT} in
- "${test_prefix}"|"${test_prefix}/"*|\
- "${test_exec_prefix}"|"${test_exec_prefix}/"*|\
- '${prefix}'|'${prefix}/'*|\
- '${exec_prefix}'|'${exec_prefix}/'*)
-   target_sysroot_reloc=1
-   ;;
- esac
+  test "x$prefix" = xNONE && prefix="$ac_default_prefix"
+  test "x$exec_prefix" = xNONE && exec_prefix='${prefix}'
+  ac_define_dir=`eval echo $TARGET_SYSTEM_ROOT`
+  ac_define_dir=`eval echo $ac_define_dir`
 
-else
+cat >>confdefs.h <<_ACEOF
+#define TARGET_SYSTEM_ROOT "$ac_define_dir"
+_ACEOF
 
- TARGET_SYSTEM_ROOT=
- TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=\"\"'
 
-fi
 
-TARGET_SYSTEM_ROOT_DEFINE="$TARGET_SYSTEM_ROOT_DEFINE -DTARGET_SYSTEM_ROOT_RELOCATABLE=$target_sysroot_reloc"
+
+  if test "x$exec_prefix" = xNONE || test "x$exec_prefix" = 'x${prefix}'; then
+     if test "x$prefix" = xNONE; then
+     	test_prefix=/usr/local
+     else
+	test_prefix=$prefix
+     fi
+  else
+     test_prefix=$exec_prefix
+  fi
+  value=0
+  case ${ac_define_dir} in
+     "${test_prefix}"|"${test_prefix}/"*|\
+	'${exec_prefix}'|'${exec_prefix}/'*)
+     value=1
+     ;;
+  esac
+
+cat >>confdefs.h <<_ACEOF
+#define TARGET_SYSTEM_ROOT_RELOCATABLE $value
+_ACEOF
 
 
 
Index: configure.ac
===================================================================
RCS file: /cvs/src/src/gdb/configure.ac,v
retrieving revision 1.152
diff -u -p -r1.152 configure.ac
--- configure.ac	4 Jan 2012 08:17:00 -0000	1.152
+++ configure.ac	18 Jan 2012 18:18:40 -0000
@@ -125,6 +125,14 @@ GDB_AC_WITH_DIR(DEBUGDIR, separate-debug
     [look for global separate debug info in this path @<:@LIBDIR/debug@:>@],
     [${libdir}/debug])
 
+# We can't pass paths as command line arguments.
+# Mingw32 tries to be clever and will convert the paths for us.
+# For example -DBINDIR="/usr/local/bin" passed on the command line may get
+# converted to -DBINDIR="E:/msys/mingw32/msys/1.0/local/bin".
+# This breaks GDB's relocatable path conversions since paths passed in
+# config.h would not get so translated, the path prefixes no longer match.
+AC_DEFINE_DIR(BINDIR, bindir, [Directory of programs.])
+
 # GDB's datadir relocation
 
 GDB_AC_WITH_DIR(GDB_DATADIR, gdb-datadir,
@@ -1753,42 +1761,20 @@ fi
 
 dnl Handle optional features that can be enabled.
 
-target_sysroot_reloc=0
+# Support for --with-sysroot is a copy of GDB_AC_WITH_DIR,
+# except that the argument to --with-sysroot is optional.
+# --with-sysroot (or --with-sysroot=yes) sets the default sysroot path.
+if test "x$with_sysroot" = xyes; then
+  with_sysroot="${exec_prefix}/${target_alias}/sys-root"
+fi
 AC_ARG_WITH(sysroot,
-AS_HELP_STRING([--with-sysroot@<:@=DIR@:>@], [search for usr/lib et al within DIR]),
-[
- case ${with_sysroot} in
- yes) TARGET_SYSTEM_ROOT='${exec_prefix}/${target_alias}/sys-root' ;;
- *) TARGET_SYSTEM_ROOT=$with_sysroot ;;
- esac
-
- TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=\"$(TARGET_SYSTEM_ROOT)\"'
-
- if test "x$prefix" = xNONE; then
-  test_prefix=/usr/local
- else
-  test_prefix=$prefix
- fi
- if test "x$exec_prefix" = xNONE || test "x$exec_prefix" = 'x${prefix}'; then
-  test_exec_prefix=$test_prefix
- else
-  test_exec_prefix=$exec_prefix
- fi
- case ${TARGET_SYSTEM_ROOT} in
- "${test_prefix}"|"${test_prefix}/"*|\
- "${test_exec_prefix}"|"${test_exec_prefix}/"*|\
- '${prefix}'|'${prefix}/'*|\
- '${exec_prefix}'|'${exec_prefix}/'*)
-   target_sysroot_reloc=1
-   ;;
- esac
-], [
- TARGET_SYSTEM_ROOT=
- TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=\"\"'
-])
-TARGET_SYSTEM_ROOT_DEFINE="$TARGET_SYSTEM_ROOT_DEFINE -DTARGET_SYSTEM_ROOT_RELOCATABLE=$target_sysroot_reloc"
+  AS_HELP_STRING([--with-sysroot@<:@=DIR@:>@],
+                 [search for usr/lib et al within DIR]),
+  [TARGET_SYSTEM_ROOT=$withval], [TARGET_SYSTEM_ROOT=])
+AC_DEFINE_DIR(TARGET_SYSTEM_ROOT, TARGET_SYSTEM_ROOT,
+              [search for usr/lib et al within DIR])
 AC_SUBST(TARGET_SYSTEM_ROOT)
-AC_SUBST(TARGET_SYSTEM_ROOT_DEFINE)
+GDB_AC_DEFINE_RELOCATABLE(TARGET_SYSTEM_ROOT, sysroot, ${ac_define_dir})
 
 GDB_AC_WITH_DIR(SYSTEM_GDBINIT, system-gdbinit,
     [automatically load a system-wide gdbinit file],

Re: Possible fix for mingw32 directory relocation problems

[Asmwarrior]

On 2012-1-17 14:11, asmwarrior wrote:
> char *
> make_relative_prefix (const char *progname, const char *bin_prefix,
>               const char *prefix)
> 
> Now, the arguments maybe looks like:
> progname          = "e:/mymingw/bin/gdb.exe"  (this is the folder you
> copy to)
> bin_prefix=BINDIR = "E:/msys/mingw32/msys/1.0/local/bin"   
> prefix            = "/usr/local/share/gdb"
> 
> The return value should be a "relative path" to ""e:/mymingw/bin/"
> 
> Right?
> 
> asmwarrior
Ok, the comments under:
\libiberty\make-relative-prefix.c line 217 clearly said it should work.
(it also give us an example about path handling)

/* Given three strings PROGNAME, BIN_PREFIX, PREFIX, return a string
that gets
   to PREFIX starting with the directory portion of PROGNAME and a relative
   pathname of the difference between BIN_PREFIX and PREFIX.

   For example, if BIN_PREFIX is /alpha/beta/gamma/gcc/delta, PREFIX is
   /alpha/beta/gamma/omega/, and PROGNAME is /red/green/blue/gcc, then this
   function will return /red/green/blue/../../omega/.

   If no relative prefix can be found, return NULL.  */

static char *
make_relative_prefix_1 (const char *progname, const char *bin_prefix,
			const char *prefix, const int resolve_links)

PS: make_relative_prefix() internally call make_relative_prefix_1().

asmwarrior
ollydbg from codeblocks forum

Re: Possible fix for mingw32 directory relocation problems

[asmwarrior]

On 2012-1-17 13:29, Doug Evans wrote:
> On Mon, Jan 16, 2012 at 9:16 PM, asmwarrior <asmwarrior@gmail.com> wrote:
>> On 2012-1-17 13:09, Doug Evans wrote:
>>
>> [- gdb-patches]
>>
>> On Mon, Jan 16, 2012 at 5:07 PM, asm warrior <asmwarrior@gmail.com> wrote:
>>
>> 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.
>>
>> Beyond what GDB has already?
>>
>> [I get the feeling people just aren't listening to me ...]
>>
>> Dear Doug.
>>
>> Sorry, I may slip your messages. (My English is not quite good) or I may not
>> fully understand your idea.
>> I just review your posts under "Building GDB 7.3.92 with MinGW" thread, and
>> you have said:
>>
>> *If* there is a bug here, and it's not pilot error, it feels like
>> perhaps the bug is in relocate_gdb_directory.
>> [Why don't all calls to relocate_gdb_directory require similar treatment?
>> Thus this feels like the wrong way to go.]
>>
>> Maybe if you provide a sample session (and complete session please, no
>> editing to trim it down), that will help.
>>
>>
>> I don't fully understand the above sentences. Sorry.
>> You mean we can change/improve the function body of
>> "relocate_gdb_directory".
> Let's put it this way.
> If we move the definitions of BINDIR and TARGET_SYSTEM_ROOT to config.h,
> what is still broken?
>
> [btw, I'm working on such a patch.]
It looks like under Windows/MinGW, relocation GDB_DATADIR will
internally call a function in libiberty


char *
make_relative_prefix (const char *progname, const char *bin_prefix,
              const char *prefix)

Now, the arguments maybe looks like:
progname          = "e:/mymingw/bin/gdb.exe"  (this is the folder you
copy to)
bin_prefix=BINDIR = "E:/msys/mingw32/msys/1.0/local/bin"   
prefix            = "/usr/local/share/gdb"

The return value should be a "relative path" to ""e:/mymingw/bin/"

Right?

asmwarrior

PS: I have cc gdb-patches mail list.

Re: Possible fix for mingw32 directory relocation problems

[asm warrior]

On Mon, Jan 16, 2012 at 11:03 PM, Pierre Muller
<pierre.muller@ics-cnrs.unistra.fr> wrote:
>
>  After 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:   $(COMPILE) $(TARGET_SYSTEM_ROOT_DEFINE) -DBINDIR=\"$(bindir)\"
> $(srcdir)/main.c
> 1524-   $(POSTCOMPILE)
> 1525-
>
>  But this leads to a conversion:
>  -DBINDIR="/usr/local/bin\"
> gets transformed into '-D' 'BINDIR="E:/msys/mingw32/msys/1.0/local/bin"'
>
>  While 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.
>
>  The 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?
>
>  If 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=xxxxx in the compiler command line option.

>
>  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.
>
> 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

Possible fix for mingw32 directory relocation problems

[Pierre Muller]

  After 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:   $(COMPILE) $(TARGET_SYSTEM_ROOT_DEFINE) -DBINDIR=\"$(bindir)\"
$(srcdir)/main.c
1524-   $(POSTCOMPILE)
1525-

  But this leads to a conversion:
  -DBINDIR="/usr/local/bin\"
gets transformed into '-D' 'BINDIR="E:/msys/mingw32/msys/1.0/local/bin"'

  While 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.

  The 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?
  
 If 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 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.

Comments most welcome and help needed...

Pierre Muller
GDB pascal language maintainer