Re: can't compile `stdlib.h` on mxe

[Bruno Haible <bruno@clisp.org>]

Hello Werner,

> Note that this is a new error; it didn't happen in July 2019 (the
> last time I've tried to build ttfautohint with mxe and Qt5).

Yes. We have added 'restrict' in many places, to match the function
declarations in POSIX.

> > * Can you verify that ddlineedit.moc.cpp starts with a '#include
> >   <config.h>' statement? [1]
> 
> It doesn't – it is an auto-generated Qt file.  However, the file starts
> with
> 
> ```
> #include <memory>
> #include "ddlineedit.h"
> ...
> ```
> 
> and `ddlineedit.h`'s first code lines are
> 
> ```
> #ifndef DDLINEEDIT_H_
> #define DDLINEEDIT_H_
> 
> #include <config.h>
> ```

That's not enough. <config.h> needs to be included before <memory>.

The Qt documentation [1] recommends a Makefile rule such as

	moc $(DEFINES) $(INCPATH) -i $< -o $@

Try to change this to

	moc -fconfig.h $(DEFINES) $(INCPATH) -i $< -o $@

or

	{ echo '#include <config.h>'; moc $(DEFINES) $(INCPATH) -i $< ; } > $@.tmp
	mv $@.tmp $@

> > * Can you show the block of preprocessor statements in <config.h> that
> >   defines 'restrict'?
> 
> ```
> /* Define to the equivalent of the C99 'restrict' keyword, or to
>    nothing if this is not supported.  Do not define if restrict is
>    supported only directly.  */
> #define restrict __restrict__
> /* Work around a bug in older versions of Sun C++, which did not
>    #define __restrict__ or support _Restrict or __restrict__
>    even though the corresponding Sun C compiler ended up with
>    "#define restrict _Restrict" or "#define restrict __restrict__"
>    in the previous line.  This workaround can be removed once
>    we assume Oracle Developer Studio 12.5 (2016) or later.  */
> #if defined __SUNPRO_CC && !defined __RESTRICT && !defined __restrict__
> # define _Restrict
> # define __restrict__
> #endif
> ```

That's OK.

> > * Can you show the command that is being executed (make V=1)?  A
> >   symbolic placeholder like 'CXX' is useless for debugging a
> >   compilation failure.
> 
> ```
> i686-w64-mingw32.static-g++ -std=gnu++11 -DHAVE_CONFIG_H -I. -I.. \
>   -I../lib -I../gnulib/src \
>   -I../gnulib/src
>   -I/home/wl/git/mxe/usr/i686-w64-mingw32.static/include/freetype2 \
>   -DUNICODE -D_UNICODE -DWIN32 -DMINGW_HAS_SECURE_API=1 -DQT_NO_DEBUG \
>   -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NEEDS_QMAIN -I. \
>   -I. -I/home/wl/git/mxe/usr/i686-w64-mingw32.static/qt5/include \
>   -I/home/wl/git/mxe/usr/i686-w64-mingw32.static/qt5/include/QtWidgets \
>   -I/home/wl/git/mxe/usr/i686-w64-mingw32.static/qt5/include/QtGui \
>   -I/home/wl/git/mxe/usr/i686-w64-mingw32.static/qt5/include/QtCore \
>   -Irelease \
>   -I/home/wl/git/mxe/usr/i686-w64-mingw32.static/qt5/mkspecs/win32-g++ \
>   -DBUILD_GUI \
>   -I/home/wl/git/mxe/usr/i686-w64-mingw32.static/include/freetype2 \
>   -pipe -fno-keep-inline-dllexport -O2 -std=gnu++11 -Wall -Wextra \
>   -Wextra -ffunction-sections -fdata-sections -fexceptions -mthreads \
>   -DUNICODE -D_UNICODE -DWIN32 -DMINGW_HAS_SECURE_API=1 -DQT_NO_DEBUG \
>   -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NEEDS_QMAIN -g -O2 \
>   -MT ttfautohintGUI-ddlineedit.moc.o -MD -MP -MF \
>   .deps/ttfautohintGUI-ddlineedit.moc.Tpo -c \
>    -o ttfautohintGUI-ddlineedit.moc.o `test -f 'ddlineedit.moc.cpp' \
>    || echo './'`ddlineedit.moc.cpp
> ```

That's also OK.

> > * What are the C compiler and C++ compiler versions that you use in
> >   this build?
> 
> gcc & g++ 5.5.0, which are the default compilers of mxe

That's also OK. In the past, we could have problems if the C compiler
and the C++ compiler were of a different brand. But that does not seem
to be the case any more.

Bruno

[1] https://doc.qt.io/qt-6/moc.html