Possible bug in GDB configuration machinery

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Possible bug in GDB configuration machinery

Keith Marshall-2
I first raised this as a MinGW.org discussion topic:

Eli Zaretskii has suggested that I also raise it here.

First, some background: I use a self-built mingw32-gcc cross compiler,
hosted on GNU/Linux, to build 32-bit software packages for publication
on the MinGW.org file release system (hosted on OSDN.net).  In the case
of packages which do not originate in MinGW itself, I keep dependencies
in a separate /mingw staging directory, outside the cross compiler's
default search path.  When I build GCC itself, (as a crossed-native
build), I specify a pair of complementary configuration options:

  --with-libiconv-prefix=/mingw  --with-libintl-prefix=/mingw

so that the i18n support libraries can be found at build time.

Despite many similarities between GCC and GDB configuration machinery,
it appears that GDB supports only the first of this pair of options; is
there any particular reason why the second is unsupported?  (It results
in failure of my GDB build, because <libintl.h> cannot be found).

Even if the omission is deliberate, it should be possible to work around
the problem, by specifying "CPPFLAGS=-I/mingw/include", (as documented
via "./configure --help"), as an argument the top-level configure, but
this doesn't work either ... the CPPFLAGS setting at top level does not
seem to propagate to subdirectory configurations, (which are deferred to
"make" time).  Both Eli and I believe this to be a bug in the GDB
configuration machinery.

If responding, please keep me in cc; I am reluctant to subscribe to a
list for which the bulk of traffic is unrelated to MinGW, and is thus of
little interest to me.


Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F

signature.asc (849 bytes) Download Attachment