Sven.Panne: > Simon Marlow wrote: > >>[...] OK, after a couple more strange experiences, whereby -fvia-c > >>sometimes > >>worked and sometimes did not, depending on what directory I was in, > >>I finally determined that the failure happened only when I had a file > >>called "stdint.h" in the current directory. > >> > >>So apparently, since a straight call of gcc does not display the same > >>problem, the search path given to gcc by ghc somehow has . before > >>the standard location of /usr/include? > > > > > >Thanks for tracking this down. For a workaround, you can say > > > > ghc -I- ... > > > >this causes ghc to pass '-I-' to gcc, which causes gcc to interpret all > >the include paths as applying only to includes of the form #include > >"...". Includes of the form #include <...> will be searched for in the > >system directories only. Put the -I- after any other -I options on the > >ghc command line. > > > >I've made this change in GHC, but I probably won't merge it into 6.2.2 > >because it's only of those changes that could easily cause something > >else to break, so we need plenty of testing. > > FYI: This change breaks things quite badly, e.g. a simple > > #include <GL/glut.h> > > fails for me now, because /usr/include/GL/glut.h contains > > #include "freeglut_std.h"
It broke a couple of things for me to. In particular libraries/X11, because it can't find /usr/X11R6/include. Exporting C_INCLUDE_PATH=/usr/X11R6/include to make this dir a "system" dir works around this, as does the magic flag -optc-isystem/usr/X11R6/include. -- Don
