Flag warnings show intermediate hscpp filenames on SmartOS
Alain O'Dea
alain.odea at gmail.com
Mon Jan 11 04:14:14 UTC 2016
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/aclocal.m4#L2160
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 <alain.odea at gmail.com> 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 <alain.odea at gmail.com> 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 <alain.odea at gmail.com> 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 <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/20160111/07232ab8/attachment.html>
More information about the ghc-devs
mailing list