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

 Hi,

after an email to mingw-w64-public,
it appeared that this was due to the fact that I had an
obsolete installation of dlfcn-win32:

The current version:
https://github.com/dlfcn-win32/dlfcn-win32

has indeed the required C++ wrappers.
Thanks to Kai Tietz for his reply there which allowed
me to understand that it was a local issue.

  I wonder if the question about the header testing 
is nevertheless a valid question or not.
As the compiler is now g++ instead of gcc, shouldn't
it be used also for header test?

  There is also the question about __USE_MINGW_ACCESS:
>   I also noticed that mingw32 still adds -D__USE_MINGW_ACCESS to CFLAGS
> but it doesn't do so for CXXFLAGS.
See more details below.

  After updating the header, compilation is successful,
but generated executable exits as soon as I press any keyboard key...


Pierre
  

> -----Message d'origine-----
> De : [email protected] [mailto:[email protected]] De la
> part de Pierre Muller
> Envoyé : lundi 8 août 2016 16:56
> À : [email protected]
> Objet : mingw32 build failure [ANNOUNCEMENT] GDB 7.12 release branch
> created!
> 
>   Hello,
> 
> 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
> with
> the following error:
> gdb-dlfcn.o: dans la fonction « Z10gdb_dlopenPKc »:
> /usr/local/src/gdb-releases/build-gdb-7.11.90/gdb/../../gdb-
> 7.11.90/gdb/gdb-
> dlfcn.c:72: référence indéfinie vers « dlopen(char const*, int) »
> /usr/local/src/gdb-releases/build-gdb-7.11.90/gdb/../../gdb-
> 7.11.90/gdb/gdb-
> dlfcn.c:80: référence indéfinie vers « dlerror() »
> gdb-dlfcn.o: dans la fonction « gdb_dlclose »:
> /usr/local/src/gdb-releases/build-gdb-7.11.90/gdb/../../gdb-
> 7.11.90/gdb/gdb-
> dlfcn.c:113: référence indéfinie vers « dlclose(void*) »
> gdb-dlfcn.o: dans la fonction « Z9gdb_dlsymPvPKc »:
> /usr/local/src/gdb-releases/build-gdb-7.11.90/gdb/../../gdb-
> 7.11.90/gdb/gdb-
> dlfcn.c:103: référence indéfinie vers « dlsym(void*, char const*) »
> gdb-dlfcn.o: dans la fonction « Z11gdb_dlclosePv »:
> /usr/local/src/gdb-releases/build-gdb-7.11.90/gdb/../../gdb-
> 7.11.90/gdb/gdb-
> 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" {
> #endif
> 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
> executables:
> 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);
> 355-}
> 356-
> 357-#define access(__f,__m)  __mingw_access (__f, __m)
> 358-#endif
> 
> 
> 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 : [email protected] [mailto:[email protected]] De la
> > part de Joel Brobecker
> > Envoyé : lundi 1 août 2016 17:28
> > À : [email protected]
> > 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/