
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
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
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
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
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
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
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
mailto:alain.odea@gmail.com> wrote: Thanks for the clarification. I understand now. On Thu, Dec 31, 2015 at 16:52 Karel Gardas < karel.gardas@centrum.cz mailto:karel.gardas@centrum.cz> 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
On 01/ 1/16 12:17 AM, Alain O'Dea wrote: 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