Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Alain O'Dea]

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

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Alain O'Dea]

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

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[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

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

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Alain O'Dea]

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 > > > wrote:
>> >
>> > 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
>> >
>>
>>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Alain O'Dea]

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 >> > > wrote:
>>> >
>>> > Thanks for the clarification. I understand now.
>>> > On Thu, Dec 31, 2015 at 16:52 Karel Gardas <
>>> karel.gar...@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
>>> >
>>>
>>>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Karel Gardas]

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

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



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

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Alain O'Dea]

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  > > wrote:
> >
> > 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
> >
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Karel Gardas]

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/compiler/main/DriverPipeline.hs#L865

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

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Karel Gardas]

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/compiler/main/DriverPipeline.hs#L865


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



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

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Ben Gamari]

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



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Alain O'Dea]

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
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Alain O'Dea]

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
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Karel Gardas]

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

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

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Alain O'Dea]

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

> 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
>>
>>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Karel Gardas]

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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Flag warnings show intermediate hscpp filenames on SmartOS

[Alain O'Dea]

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
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Flag warnings show intermediate hscpp filenames on SmartOS

[Alain O'Dea]

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/compiler/main/DriverPipeline.hs#L865

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