> 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.e...@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.e...@uni-konstanz.de > > Email had 1 attachment: > + smime.p7s > 7k (application/pkcs7-signature)
