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 <alain.odea at gmail.com> 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 <alain.odea at gmail.com> 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 <karel.gardas at centrum.cz>
>> 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 <alain.odea at gmail.com
>>> > <mailto:alain.odea at gmail.com>> wrote:
>>> >
>>> > Thanks for the clarification. I understand now.
>>> > On Thu, Dec 31, 2015 at 16:52 Karel Gardas <
>>> karel.gardas at centrum.cz
>>> > <mailto:karel.gardas at 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
>>> >
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160101/669a267a/attachment-0001.html>