cpphs doesn't currently work for compiling GHC. libraries/base/GHC/Natural.hs uses a macro with arguments inside an if defined preprocessor expression and cpphs tries to expand the macro and errors since there are no arguments provided.
This is non-compliant if cpphs is trying to be a C99 preprocessor: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf 6.10.1/1 Conditional Inclusion pg 148 clearly indicates that the token after defined or within defined ( ) is an identifier, not a macro to be expanded. On Sun, Jan 10, 2016 at 2:14 AM Alain O'Dea <[email protected]> wrote: > Progress Update: > 1. fixing CPP fixes the majority of the remaining test failures > 2. cpphs builds and runs successfully on SmartOS > 3. --with-hs-cpp-flags='-specs=overridecpp.spec" can be used in lieu of a > wrapper script > 3. I am running some experiments with cpphs to see how it works > 4. I will run some experiments with hs-cpp-flags and gcc to see how that > goes (it would be a smaller impact change on GHC to include and reference a > spec file) > > On Fri, Jan 1, 2016 at 5:32 PM Alain O'Dea <[email protected]> wrote: > >> Okay Karel. I have a solution that works to make T2464 pass. >> >> Create overridecpp.spec: >> >> *cpp: >> %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} >> >> Create ghc-cpp and make it executable: >> >> #!/bin/bash >> gcc -spec=/path/to/overridecpp.spec $@ >> >> Configure and make GHC with ghc-cpp and run T2464: >> >> ./configure --with-hs-cpp=/path/to/ghc-cpp >> make -j8 >> make TEST=T2464 test >> >> This should work on Solaris 11 as well. >> >> So GHC could ship a GCC Specs file like this and that wrapper script as >> an interim solution. In the interim I'll include these as patches in >> PKGSRC and get a GHC 7.10.3 built with them applied. I'm going to hold off >> on PKGSRC stuff until I get fixes for more of the failing tests though. >> >> Does this seem like a reasonable solution to you? >> >> On Fri, Jan 1, 2016 at 4:58 PM Alain O'Dea <[email protected]> wrote: >> >>> Actually Karel, if "gcc -dumpspecs" shows you that same -P as I get you >>> can override it with spec files as described here: >>> https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html >>> >>> I think this means that you could specify "gcc >>> -specs=/path/to/overridecpp.spec" as --with-hs-cpp when building GHC. I'm >>> trying that now. I've already gotten a strawman example based on your post >>> to the GCC list working, and I'm going to try to expand on it. >>> >>> On Fri, Jan 1, 2016 at 3:08 PM Alain O'Dea <[email protected]> wrote: >>> >>>> True, but I'd still like to find a mutual solution since we're both >>>> somewhat at the edge of the supported landscape for GHC. >>>> >>>> Is installing cpphs and configuring GHC to use that an option on >>>> Solaris 11? I haven't built cpphs successfully on SmartOS yet. Supplying a >>>> custom C preprocessor may be your best bet and using GCC 3.4's works for >>>> you. If I can get cpphs working that may be the common ground needed to >>>> keep Illumos and Solaris support from diverging. >>>> >>>> On Fri, Jan 1, 2016 at 7:52 AM Karel Gardas <[email protected]> >>>> wrote: >>>> >>>>> >>>>> Alain, >>>>> >>>>> indeed, on SmartOS you are free to modify the supplied GCC so the fix >>>>> to >>>>> remove -P is most natural one. On the other hand I'm not so lucky with >>>>> binary Solaris 11.x distribution provided by Oracle so I need to use >>>>> not >>>>> so clean and nice workarounds... >>>>> >>>>> Karel >>>>> >>>>> On 01/ 1/16 12:17 AM, Alain O'Dea wrote: >>>>> > cpphs isn't a direct option. It won't install on SmartOS with Cabal. >>>>> > GCC 4.7 is the earliest GCC supported so I'll have to try something >>>>> else >>>>> > for SmartOS. >>>>> > >>>>> > It looks like the GCC Specs are the problem. >>>>> > >>>>> > On Ubuntu the Spec for cpp is: >>>>> > >>>>> > *cpp: >>>>> > %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} >>>>> > >>>>> > On SmartOS the Spec for cpp is: >>>>> > >>>>> > *cpp: >>>>> > %{,assembler-with-cpp:-P} %(cpp_subtarget) >>>>> > >>>>> > I think this is how the -P gets injected. I think this is >>>>> correctable. >>>>> > I had a similar issue with -std=c99 which is the default for C >>>>> compiling >>>>> > on Ubuntu but not on SmartOS leading to issues with compiling source >>>>> > that isn't old school C (like persistent-sqlite). >>>>> > >>>>> > Anyways I must retire from this and entertain my guests. Happy New >>>>> Year >>>>> > folks. >>>>> > >>>>> > >>>>> > On Thu, Dec 31, 2015 at 5:19 PM Alain O'Dea <[email protected] >>>>> > <mailto:[email protected]>> wrote: >>>>> > >>>>> > Thanks for the clarification. I understand now. >>>>> > On Thu, Dec 31, 2015 at 16:52 Karel Gardas < >>>>> [email protected] >>>>> > <mailto:[email protected]>> wrote: >>>>> > >>>>> > On 12/31/15 07:41 PM, Alain O'Dea wrote: >>>>> > > Yes. I can do that. >>>>> > > >>>>> > > On SmartOS it may not be GCC 3.4.3 causing this. I see >>>>> this >>>>> > on GCC 4.7.x >>>>> > > through 4.9.x. The paths to gcc on SmartOS also differ. >>>>> I'll >>>>> > have to >>>>> > > verify that as part of checking this. >>>>> > >>>>> > This is misunderstanding. GCC 3.4.3 provides *correct* CPP >>>>> behavior, >>>>> > while all 4.x provides broken CPP. That means as a workaround >>>>> > when GCC >>>>> > 3.4.3 is installed I set it as GHC's CPP automatically on >>>>> > Solaris. When >>>>> > it is not available, then GHC behaves like you've seen when >>>>> > using CPP... >>>>> > >>>>> > Hopefully this is more clear now, >>>>> > >>>>> > Karel >>>>> > >>>>> >>>>>
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
