mingw32 build failure [ANNOUNCEMENT] GDB 7.12 release branch created!

Pierre Muller pierre.muller@ics-cnrs.unistra.fr
Mon Aug 8 14:56:00 GMT 2016


I would like to report a problem that I encounter when trying to generate
a new GDB binary for i686-w64-mingw32 host.
 I am using cygwin to compile a GDB for this host with
../gdb-7.11.90/configure --host=i686-w64-mingw32

  The configuration succeeds, but compilation fails a gdb binary linking
the following error:
gdb-dlfcn.o: dans la fonction « Z10gdb_dlopenPKc »:
dlfcn.c:72: référence indéfinie vers « dlopen(char const*, int) »
dlfcn.c:80: référence indéfinie vers « dlerror() »
gdb-dlfcn.o: dans la fonction « gdb_dlclose »:
dlfcn.c:113: référence indéfinie vers « dlclose(void*) »
gdb-dlfcn.o: dans la fonction « Z9gdb_dlsymPvPKc »:
dlfcn.c:103: référence indéfinie vers « dlsym(void*, char const*) »
gdb-dlfcn.o: dans la fonction « Z11gdb_dlclosePv »:
dlfcn.c:113: référence indéfinie vers « dlclose(void*) »
collect2: erreur : ld a retourné 1 code d'état d'exécution
make[1]: *** [Makefile:1409: gdb.exe] Error 1
make[1] : on quitte le répertoire
« /usr/local/src/gdb-releases/build-gdb-7.11.90/gdb »
make: *** [Makefile:9169: all-gdb] Error 2

This is due the switch to using C++ as default compiler combined with
the fact that i686-w64-mingw32 does supply a dlfcn.h header,
but this header does not contain the usual C++ macros:
#ifdef __cplusplus
extern "C" {
and final counterpart.

  Thus GNU C++ compiler mangles the dlopen, dlerror, dlclose and dlsym
functions instead of using the C compiler generated assembler symbols,
i.e. simply '_dlopen', '_dlerror' ...
and final linking fails because of this.

Is this only an error in the i686-w64-mingw32 distribution?
The problem is that it does not seem possible to use the 
'old' mingw32 substitute code by some configure option.
Disabling the #define HAVE_DLFCN_H 1 inside the generated gdb/config.h
does NOT work, because after manual change to config.h,
calling make with regenerate gdb/config.h with the wrong #define
HAVE_DLFCN_H 1 line.

Is it also an error in the configure process?

I would expect that if we use g++ as a compiler, we should test the
different headers
using this compiler, rather than using gcc.

  I also noticed that mingw32 still adds -D__USE_MINGW_ACCESS to CFLAGS
but it doesn't do so for CXXFLAGS.

  According to /mingw/include/io.h, this might also influence generated
349:#ifdef __USE_MINGW_ACCESS
350-/*  Old versions of MSVCRT access() just ignored X_OK, while the version
351-    shipped with Vista, returns an error code.  This will restore the
352-    old behaviour  */
353-static inline int __mingw_access (const char *__fname, int __mode) {
354-  return  _access (__fname, __mode & ~X_OK);
357-#define access(__f,__m)  __mingw_access (__f, __m)

Apart from temporarily hiding include/dlfcn.h header, is there any 
less ugly way to overcome this problem?

Pierre Muller
Pascal language maintainer

> -----Message d'origine-----
> De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la
> part de Joel Brobecker
> Envoyé : lundi 1 août 2016 17:28
> À : gdb@sourceware.org
> Objet : [ANNOUNCEMENT] GDB 7.12 release branch created!
> Hello,
> A quick message to announce that the GDB 7.12 branch has just been
> created.
> The prerelease snapshots will be available at:
>     ftp://sourceware.org/pub/gdb/snapshots/branch/gdb.tar.xz
>     ftp://sourceware.org/pub/gdb/snapshots/branch/gdb.tar.gz
> The sources are also accessible via GIT:
>     git clone --single-branch --branch=gdb-7.12-branch
> git://sourceware.org/git/binutils-gdb.git
> This announcement has also been posted on the GDB web site at:
>     http://www.sourceware.org/gdb/

More information about the Gdb mailing list