Patch RFC: Fix broken builds with Sun CC

[ellie timoney]

> You noted that the `lib/imapopts.c` file is autogenerated -- and indeed
> it is, but not during `configure` or `make`, but it is already shipped
> in the code tar bundle (with GCCisms included).

Oh, good catch!

I'm not sure what the reasoning is behind distributing a generated
lib/imapopts.c.  It might just be oversight.  It might be a deliberate
choice to protect the user from tools/config2header's own dependencies. 
tools/config2header does some shell tricks to require perl 5, which
might have once been the "problematic" dependency, but I don't think
that's a problematic dependency anymore.

So I'll just go ahead and fix this for future releases, if there's no
objections?

Cheers,

ellie

On Fri, Apr 1, 2016, at 06:40 PM, Jens Erat wrote:
> Hi Ellie,
> 
> although quite some time passed since I gave feedback last time, this
> issue is still open for us (although we have a workaround, so it doesn't
> bother us too much). By now I think that the issue isn't with
> `configure` or `make` parsing `$CC` wrong, we probably have been mislead
> by several other issues we had.
> 
> You noted that the `lib/imapopts.c` file is autogenerated -- and indeed
> it is, but not during `configure` or `make`, but it is already shipped
> in the code tar bundle (with GCCisms included).
> 
> Our current workaround is to remove `lib/imapopts.c` before `make`ing
> Cyrus IMAP, the file is automatically recreated. Is it possible that
> this file should never have been included in the source distribution?
> 
> Build is successfull with following commands:
> 
> 
>     export PATH=/opt/solarisstudio12.4/bin:$PATH
>     export CC=/opt/solarisstudio12.4/bin/cc
>     # also exported several compiler- and linkerflags,
>     # don't seem relevant here
>     ./configure # and a bunch of configure options
>     rm lib/imapopts.c
>     gmake
>     gmake install
> 
> `gmake` also regenerates `lib/imaptops.c` (without those union casts).
> 
> Regards,
> Jens
> 
> Am 22.09.2015 um 02:09 schrieb ellie timoney:
> > Hi Jens,
> > 
> >> We already set `CC=cc`, which resulted in following `configure` output:
> >> [...]
> >> indeed, void casts are generated. For now, the issue is resolved by
> >> exporting the full path of the Sun C compiler.
> > 
> > That's curious.  I wonder if configure is being clever in some unhelpful
> > way.
> > 
> > Can you re-run configure, once with CC=cc and once with the exported
> > full path that actually worked, and attach the config.log files that are
> > generated by each run?  You might need to send them directly to me, I'm
> > not sure if the mailing list allows attachments.
> > 
> > I'm not sure I'll actually be able to get to the bottom of this without
> > a Sun environment to experiment in, but I can at least have a look and
> > see if it's something obvious.
> > 
> > Cheers,
> > 
> > ellie
> > 
> > On Mon, Sep 21, 2015, at 09:11 PM, Jens Erat wrote:
> >> Hi Ellie,
> >>
> >> thank you for the detailed analysis.
> >>
> >>>> This is not as simple as just removing the casts from lib/imapopts.c --
> >>>> it's a generated file.  Note the comments at the top:
> >>>>
> >>>>> /* auto-generated by config2header 1.17 */
> >>>>>
> >>>>> /* DO NOT EDIT */
> >>>>>
> >>>>> /* THIS FILE AUTOMATICALLY GENERATED BY config2header 1.17 */
> >>>>
> >>
> >> Indeed, this is not the way to go.
> >>
> >>
> >>> I don't know what the Sun compiler is called, though I'm assuming it
> >>> doesn't call itself "gcc".  If it does, there is your problem.
> >>>
> >>> Otherwise, you should be able to do something like this to make sure it
> >>> uses the same compiler for the whole build:
> >>>
> >>>> make clean
> >>>> ./configure CC=/path/to/sun/compiler [...]
> >>>> make
> >>
> >> We already set `CC=cc`, which resulted in following `configure` output:
> >>
> >> checking build system type... i386-pc-solaris2.11
> >> checking host system type... i386-pc-solaris2.11
> >> checking target system type... i386-pc-solaris2.11
> >> checking for a BSD-compatible install... /usr/bin/ginstall -c
> >> checking whether build environment is sane... yes
> >> checking for a thread-safe mkdir -p... /usr/bin/gmkdir -p
> >> checking for gawk... gawk
> >> checking whether make sets $(MAKE)... yes
> >> checking whether to enable maintainer-specific portions of Makefiles...
> >> no
> >> checking for gcc... cc
> >> checking whether the C compiler works... yes
> >> checking for C compiler default output file name... a.out
> >> checking for suffix of executables...
> >> checking whether we are cross compiling... no
> >> checking for suffix of object files... o
> >> checking whether we are using the GNU C compiler... no
> >> checking whether cc accepts -g... yes
> >> checking for cc option to accept ISO C89... none needed
> >> checking for style of include used by make... GNU
> >> checking dependency style of cc... none
> >> checking whether cc understands -c and -o together... yes
> >> checking whether ln -s works... yes
> >> checking whether make sets $(MAKE)... (cached) yes
> >> checking how to run the C preprocessor... cc -E
> >> checking for grep that handles long lines and -e... /usr/bin/ggrep
> >> checking for egrep... /usr/bin/ggrep -E
> >> checking for ANSI C header files... yes
> >>
> >>
> >> Also if using `export CC=/opt/solarisstudio12.4/bin/cc`, union casts are
> >> created, but one single line changes to
> >>
> >> checking fgor gcc... /opt/solarisstudio12.4/bin/cc
> >>
> >> `./configure CC=/opt/solarisstudio12.4/bin/cc [...]` does not change
> >> anything, either. GCC _is_ installed as `/usr/bin/gcc`, but should not
> >> have been used.
> >>
> >> Interestingly, configure also recognizes `make` as GNU make (available
> >> under `gmake`, though); resulting in a GNU-style make file (and we have
> >> to use `gmake` for Cyrus IMAP instead of `make`, but I guess that's just
> >> fine, at least for us, but also might hint a problem).
> >>
> >>
> >>
> >>>> The mailing list discussions you reference talk about this being a
> >>>> result of the Sun compiler being strict about "Ansi C", by which I'm
> >>>> assuming they mean C89/C90.  We generally target C99 these days (it is,
> >>>> after all, 16 years old, and has itself already been superceded by
> >>>> C11...).
> >>>>
> >>>> I don't know if the Sun compiler has options to support C99, but if it
> >>>> does, have you tried using them?
> >>
> >> Following the man pages, Sun CC not only supports C99, but also C11, and
> >> C11 is set as default:
> >>
> >>      -std=value
> >>
> >>          C language standard selection flag.
> >>
> >>          value is defined as one of the following:
> >>
> >>
> >>          c89          C source language accepted is that  defined
> >>                       by the ISO C90 standard.
> >>
> >>
> >>          c99          C source language accepted is that  defined
> >>                       by the ISO C99 standard.
> >>
> >>
> >>          c11          C source language accepted is that  defined
> >>                       by the ISO C11 standard.
> >>
> >>          The first default is c11, implying acceptance of  the  C
> >>          source  language as defined by ANSI C11 with extensions.
> >>
> >> Enforcing C99 by adding `-std=c99` to CFLAGS did not resolve the issue,
> >> but c11 should be the default, anyway...
> >>
> >>
> >>> If your $CC evaluates to 'gcc' then it will generate union casts;
> >>> otherwise, it will generate (void *) casts.  Watch:
> >>>
> >>>> $rm lib/imapopts.c
> >>>> $make CC=gcc lib/imapopts.c
> >>
> >> If I run
> >>
> >>     gmake CC=`which cc` lib/imapopts.c
> >>
> >> indeed, void casts are generated. For now, the issue is resolved by
> >> exporting the full path of the Sun C compiler.
> >>
> >> Regards,
> >> Jens
> >>
> >> -- 
> >> Jens Erat
> >> Universität Konstanz
> >> Kommunikations-, Infomations-, Medienzentrum (KIM)
> >> Abteilung Basisdienste
> >> D-78457 Konstanz
> >> Mail: jens.erat at uni-konstanz.de
> >>
> >>
> >> Email had 1 attachment:
> >> + smime.p7s
> >>   7k (application/pkcs7-signature)
> 
> -- 
> Jens Erat
> Universität Konstanz
> Kommunikations-, Infomations-, Medienzentrum (KIM)
> Abteilung Basisdienste
> D-78457 Konstanz
> Mail: jens.erat at uni-konstanz.de
> 
> Email had 1 attachment:
> + smime.p7s
>   7k (application/pkcs7-signature)