Also related: https://haskell-phabricator.global.ssl.fastly.net/D151 as Solaris is not the only problematic platform with CPP, HVR has started excellent 'RFC: "Native -XCPP" Proposal' thread in the past together with the wiki page: https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp Hope this helps, Karel On 12/31/15 09:28 AM, Karel Gardas wrote:

Hi Alain,

I guess you are hit by well known issue in GCC's CPP on Solaris. Just verify here:

https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html

solution in this case is simple: use configure option to set different non buggy CPP as a CPP for GHC.

Please let me know if this is the culprit,

Thanks, Karel

On 12/31/15 08:09 AM, Alain O'Dea wrote:

...

On SmartOS GHC flag warnings show up like this: /tmp/ghc72341_0/ghc_1.hscpp:7:16: Warning: -fffi is deprecated: use -XForeignFunctionInterface or pragma {-# LANGUAGE ForeignFunctionInterface #-} instead

It appears that this line in DriverPipeline leads to the correct filename in warnings on Ubuntu, but not on SmartOS: src_opts <- liftIO $ getOptionsFromFile dflags0 output_fn https://github.com/ghc/ghc/blob/bb7f2e33197e667eb694bd1243f125c722a0a868/com...

How does the intermediate hscpp filename get restored to a correct filename if warnings are generated during a re-read of the pragmas after having preprocessed the file?

Full investigation notes are here (rambling and unedited): https://gist.github.com/AlainODea/98141991849093285c52

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Thank you Karel. I'll try that tomorrow and report back my results. On Thu, Dec 31, 2015 at 09:00 Ben Gamari wrote:

Karel Gardas writes:

...

Hi Alain,

I guess you are hit by well known issue in GCC's CPP on Solaris. Just verify here:

https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html

solution in this case is simple: use configure option to set different non buggy CPP as a CPP for GHC.

Please let me know if this is the culprit,

Perhaps we should add an autoconf check to preempt this issue and point affected users in the direction of a solution?

Cheers,

- Ben

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. I think requiring cpphs on Illumos and Solaris might be a reasonable compromise. I like the idea of warning about this and suggesting --with-hs-cpp /path/to/cpphs. On Thu, Dec 31, 2015 at 11:51 Karel Gardas wrote:

On 12/31/15 01:30 PM, Ben Gamari wrote:

...

Karel Gardas writes:

...

Hi Alain,

I guess you are hit by well known issue in GCC's CPP on Solaris. Just verify here:

https://gcc.gnu.org/ml/gcc/2014-08/msg00114.html

solution in this case is simple: use configure option to set different non buggy CPP as a CPP for GHC.

Please let me know if this is the culprit,

Perhaps we should add an autoconf check to preempt this issue and point affected users in the direction of a solution?

Hmm, I tried that with https://phabricator.haskell.org/D151 -- but perhaps some nice warning emitted during configure time in case of undetected GCC 3.4.3 on Solaris will help here? This will also need to be done in bindist configure thought.

Alain, would you do that? I'm asking since you've been hit by this recently...

Karel

Thanks for the clarification. I understand now. On Thu, Dec 31, 2015 at 16:52 Karel Gardas 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

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 mailto:alain.odea@gmail.com> wrote:

Thanks for the clarification. I understand now. On Thu, Dec 31, 2015 at 16:52 Karel Gardas 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 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

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

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 mailto:alain.odea@gmail.com> wrote:

Thanks for the clarification. I understand now. On Thu, Dec 31, 2015 at 16:52 Karel Gardas 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 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

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

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 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 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

Configuring GHC with modified hs-cpp-flags works to fix the tests: ./configure --with-hs-cpp-flags="-specs=/opt/local/etc/ghc/overridecpp.spec -E -undef -traditional -x assembler-with-cpp" overridecpp.spec: *cpp: %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} The challenge now is how to integrate this extra file and new default hs-cpp-flags cleanly into the GHC build and install. I know I can modify aclocal.m4 to add the -specs argument to hs-cpp-flags easily: https://github.com/ghc/ghc/blob/f7b45c31f07daa4c3dca39f6ccc1a52c86900b7c/acl... Where should I put overridecpp.spec in the GHC source and how do I get it to be included during make install? On Sun, Jan 10, 2016 at 4:38 PM Alain O'Dea wrote:

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 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 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

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 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 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 >