Re: Order of AM_CPPFLAGS and other xxx_CFLAGS

[Rik]

On 11/14/2013 07:57 PM, Michael Goffioul wrote:
> Rik,
>
> This changeset breaks my compilation with MSVC:
>
> http://hg.savannah.gnu.org/hgweb/octave/rev/a230b996ae8a
>
> The problem is that compilation of (among others) __init_fltk__.cc uses
> now the following CPPFLAGS definition:
>
> $(GRAPHICS_CFLAGS) $(FT2_CPPFLAGS) $(FONTCONFIG_CPPFLAGS) $(AM_CPPFLAGS)
>
> The variable GRAPHICS_CFLAGS, pulled from fltk-config, contains a -Ixxx
> statement containing the base installation directory of my MXE system.
> The libgnu directory, on the other hand, is part of AM_CPPFLAGS. As a
> result, gnulib header substitution fails for some headers. A similar
> problem could also occur on Linux if any of the variables preceding
> AM_CPPFLAGS happen to contain -I/usr/include. I believe the libgnu
> directory should appear early in the include chain, otherwise it'll fail
> to override what it's supposed to override.
>
Ugh.  This doesn't look like it is going to be fun to solve.

The changeset was made to fix bug #36064
(https://savannah.gnu.org/bugs/?func=detailitem&item_id=36064) and I do
like the approach taken.  Thus, I'd like to pursue the minimally disturbing
changeset that allows MSVC to compile.  Base compiling of Octave, no weird
cross-compilations or MXE environment, work just fine with the current
ordering so I don't think we should hack on the Octave build system. 
Instead, I think something specific to MXE, and possibly specific to using
the MSVC compiler, should be enough.

One solution, would be to add a new diff file 'msvc-octave-2.patch' to the
the src/ directory of MXE.  This patch would revert the above-mentioned
changeset just for MSVC MEX builds.

A second solution, would be to try and place libgnu earlier in the include
list.  For conventional Octave builds we had a problem with this which is
why it is always the last entry in the AM_CPPFLAGS list.  If I look at the
CXX compile command in the Makefile generated in the MXE temporary build
directory I find it has the line:

dldfcn/dldfcn___init_fltk___la-__init_fltk__.lo: dldfcn/__init_fltk__.cc
    $(AM_V_CXX)$(LIBTOOL) $(AM_V_lt) --tag=CXX $(AM_LIBTOOLFLAGS)
$(LIBTOOLFLAGS) --mode=compile $(CXX) $(DEFS) $(DEFAULT_INCLUDES)
$(INCLUDES) $(dldfcn___init_fltk___la_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS)
$(CXXFLAGS) -MT dldfcn/dldfcn___init_fltk___la-__init_fltk__.lo -MD -MP -MF
dldfcn/$(DEPDIR)/dldfcn___init_fltk___la-__init_fltk__.Tpo -c -o
dldfcn/dldfcn___init_fltk___la-__init_fltk__.lo `test -f
'dldfcn/__init_fltk__.cc' || echo '$(srcdir)/'`dldfcn/__init_fltk__.cc
    $(AM_V_at)$(am__mv)
dldfcn/$(DEPDIR)/dldfcn___init_fltk___la-__init_fltk__.Tpo
dldfcn/$(DEPDIR)/dldfcn___init_fltk___la-__init_fltk__.Plo

which expands on my system to

/bin/bash ../libtool  --tag=CXX   --mode=compile i686-pc-mingw32-g++
-DHAVE_CONFIG_H -I.
-I/home/rik/wip/Projects_Mine/mxe-octave/tmp-octave/octave-3.7.7/libinterp
-I.. 
-I/home/rik/wip/Projects_Mine/mxe-octave/tmp-octave/octave-3.7.7/liboctave/cruft/misc
-I/home/rik/wip/Projects_Mine/mxe-octave/tmp-octave/octave-3.7.7/liboctave/array
-I../liboctave/numeric
-I/home/rik/wip/Projects_Mine/mxe-octave/tmp-octave/octave-3.7.7/liboctave/numeric
-I../liboctave/operators
-I/home/rik/wip/Projects_Mine/mxe-octave/tmp-octave/octave-3.7.7/liboctave/operators
-I/home/rik/wip/Projects_Mine/mxe-octave/tmp-octave/octave-3.7.7/liboctave/system
-I/home/rik/wip/Projects_Mine/mxe-octave/tmp-octave/octave-3.7.7/liboctave/util
-I/home/rik/wip/Projects_Mine/mxe-octave/tmp-octave/octave-3.7.7/libinterp/octave-value
-I/home/rik/wip/Projects_Mine/mxe-octave/tmp-octave/octave-3.7.7/libinterp/operators
-Iparse-tree
-I/home/rik/wip/Projects_Mine/mxe-octave/tmp-octave/octave-3.7.7/libinterp/parse-tree
-Icorefcn
-I/home/rik/wip/Projects_Mine/mxe-octave/tmp-octave/octave-3.7.7/libinterp/corefcn
-I../libgnu
-I/home/rik/wip/Projects_Mine/mxe-octave/tmp-octave/octave-3.7.7/libgnu
-I/home/rik/wip/Projects_Mine/mxe-octave/usr/i686-pc-mingw32/include
-mwindows -DWIN32 -DUSE_OPENGL32 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE 
-I/home/rik/wip/Projects_Mine/mxe-octave/usr/i686-pc-mingw32/include
-mieee-fp
-I/home/rik/wip/Projects_Mine/mxe-octave/usr/i686-pc-mingw32/include
-I/home/rik/wip/Projects_Mine/mxe-octave/usr/i686-pc-mingw32/include/freetype2
-I/home/rik/wip/Projects_Mine/mxe-octave/usr/i686-pc-mingw32/include 
-I/home/rik/wip/Projects_Mine/mxe-octave/usr/i686-pc-mingw32/include  -Wall
-W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings
-Wcast-align -Wcast-qual -g -O2 -pthread -MT
dldfcn/dldfcn___init_fltk___la-__init_fltk__.lo -MD -MP -MF
dldfcn/.deps/dldfcn___init_fltk___la-__init_fltk__.Tpo -c -o
dldfcn/dldfcn___init_fltk___la-__init_fltk__.lo `test -f
'dldfcn/__init_fltk__.cc' || echo
'/home/rik/wip/Projects_Mine/mxe-octave/tmp-octave/octave-3.7.7/libinterp/'`dldfcn/__init_fltk__.cc

Contrary to the regular build where $(INCLUDES) is null, it seems to have
been filled with $(AM_CPPFLAGS) for the MEX build.  The important point is
that the entry for libgnu is already ahead of the base reference to
.../mxe-octave/usr/i686-pc-mingw32/include.  Maybe you can check the last
octave compilation log in mxe-octave/log/octave and see whether this is
also the case for the MSVC build.  If it is, then just putting libgnu early
isn't going to help.

A third solution would be to add another .patch file to change octave's
configure.ac to add a sed command to remove any -I
.../mxe-octave/usr/i686-pc-mingw32/include entry from *both*
GRAPHICS_CFLAGS and FT2_CFLAGS.

Finally, I think the problem may mostly be with FLTK which has it's own
math.h file.  Various FLTK files use '#include "FL/math.h"', but math.h
then tries to pick up a copy of "<math.h>" and through a long process you
are getting the raw math.h rather than the one in libgnu.  It might be
possible to write a different sort of .patch that adds some -D defines to
change the behavior of FL/math.h.  It's just a possibility because I notice
from the file that they are already doing some odd things on OSX and maybe
something odd needs to be done for MEX as well.

--- top of FL/math.h ---
// Xcode on OS X includes files by recursing down into directories.
// This code catches the cycle and directly includes the required file.
#ifdef fl_math_h_cyclic_include
#  include "/usr/include/math.h"
#endif

#ifndef fl_math_h
#  define fl_math_h

#  define fl_math_h_cyclic_include
#  include <math.h>
#  undef fl_math_h_cyclic_include
--- end code ---

Hopefully one of these solutions will work for you.

--Rik