[Dovecot] beta5 builds under RHEL
Hi,
beta4 built under RHEL4, RHEL5 and RHEL6 (the latter being the public beta). beta5 now builds only for RHEL5, the other two fail with:
strnum.c: In function str_to_llong': strnum.c:139: error: LLONG_MIN' undeclared (first use in this function)
strnum.c:139: error: (Each undeclared identifier is reported only once
strnum.c:139: error: for each function it appears in.)
Thanks!
Axel.Thimm at ATrpms.net
On 05/30/2010 09:05 AM Axel Thimm wrote:
Hi,
beta4 built under RHEL4, RHEL5 and RHEL6 (the latter being the public beta). beta5 now builds only for RHEL5, the other two fail with:
strnum.c: In function
str_to_llong': strnum.c:139: error:LLONG_MIN' undeclared (first use in this function) strnum.c:139: error: (Each undeclared identifier is reported only once strnum.c:139: error: for each function it appears in.)Thanks!
LLONG_MIN is defined in /usr/include/limits.h (at least on my systems). It's provided by the package libc6-dev (on Debian GNU/Linux).
src/lib/strnum.c <- includes "lib.h" src/lib/lib.h <- includes <limits.h>
Defines your limits.h LLONG_MIN? If not, which libc/version is RHEL 6 using?
Regards, Pascal
The trapper recommends today: 5e1f1e55.1015009@localdomain.org
On Sun, May 30, 2010 at 09:42:38AM +0200, Pascal Volk wrote:
On 05/30/2010 09:05 AM Axel Thimm wrote:
beta4 built under RHEL4, RHEL5 and RHEL6 (the latter being the public beta). beta5 now builds only for RHEL5, the other two fail with:
strnum.c: In function
str_to_llong': strnum.c:139: error:LLONG_MIN' undeclared (first use in this function) strnum.c:139: error: (Each undeclared identifier is reported only once strnum.c:139: error: for each function it appears in.)LLONG_MIN is defined in /usr/include/limits.h (at least on my systems). It's provided by the package libc6-dev (on Debian GNU/Linux).
src/lib/strnum.c <- includes "lib.h" src/lib/lib.h <- includes <limits.h>
Defines your limits.h LLONG_MIN? If not, which libc/version is RHEL 6 using?
LLONG_MIN/LLONG_MAX and some other defines are there, but protected by
ifdef __USE_ISOC99
Maybe dovecot's buildsystem should check for and use -std=c99? But then I wonder why it does build for RHEL5 and all recent Fedoras? I grepped the logs and found no explicit -std switch in any of the successful builds.
Thanks!
Axel.Thimm at ATrpms.net
On 05/30/2010 09:54 AM Axel Thimm wrote:
LLONG_MIN/LLONG_MAX and some other defines are there, but protected by
ifdef __USE_ISOC99
Maybe dovecot's buildsystem should check for and use -std=c99? But then I wonder why it does build for RHEL5 and all recent Fedoras? I grepped the logs and found no explicit -std switch in any of the successful builds.
Wow, now I'm wondering too:
limits.h:102 # ifdef __USE_ISOC99 define LLONG_MAX, LLONG_MIN, ULLONG_MAX limits.h:111 # endif /* ISO C99 */ limits.h:131 #if defined __USE_ISOC99 && defined __GNUC__ ifndef LLONG_MIN, LLONG_MAX, ULLONG_MAX define theme limits.h:141 #endif
Dovecot used std=gnu99, when possible configure.in:300 # Use std=gnu99 if we have new enough gcc configure.in:301 old_cflags=$CFLAGS configure.in:302 CFLAGS="-std=gnu99"
gcc(1) gnu99 GNU dialect of ISO C99. When ISO C99 is fully implemented in GCC, this will become the default. …
Which gcc uses RHEL 6? It works for me with gcc-4.3 and gcc-4.4.
Regards, Pascal
The trapper recommends today: cafebabe.1015010@localdomain.org
On Sun, May 30, 2010 at 10:41:12AM +0200, Pascal Volk wrote:
On 05/30/2010 09:54 AM Axel Thimm wrote:
LLONG_MIN/LLONG_MAX and some other defines are there, but protected by
ifdef __USE_ISOC99
Maybe dovecot's buildsystem should check for and use -std=c99? But then I wonder why it does build for RHEL5 and all recent Fedoras? I grepped the logs and found no explicit -std switch in any of the successful builds.
Wow, now I'm wondering too:
limits.h:102 # ifdef __USE_ISOC99 define LLONG_MAX, LLONG_MIN, ULLONG_MAX limits.h:111 # endif /* ISO C99 */ limits.h:131 #if defined __USE_ISOC99 && defined __GNUC__ ifndef LLONG_MIN, LLONG_MAX, ULLONG_MAX define theme limits.h:141 #endif
Dovecot used std=gnu99, when possible configure.in:300 # Use std=gnu99 if we have new enough gcc configure.in:301 old_cflags=$CFLAGS configure.in:302 CFLAGS="-std=gnu99"
gcc(1) gnu99 GNU dialect of ISO C99. When ISO C99 is fully implemented in GCC, this will become the default. …
Which gcc uses RHEL 6? It works for me with gcc-4.3 and gcc-4.4.
The gcc I used are
RHEL4 3.4.6 fails RHEL5 4.1.2 builds F11 4.4.1 builds F12 4.4.3 builds RHEL6 (beta1) 4.4.3 fails F13 4.4.4 builds
Axel.Thimm at ATrpms.net
On Sun, May 30, 2010 at 12:30:48PM +0300, Axel Thimm wrote:
On Sun, May 30, 2010 at 10:41:12AM +0200, Pascal Volk wrote:
On 05/30/2010 09:54 AM Axel Thimm wrote:
LLONG_MIN/LLONG_MAX and some other defines are there, but protected by
ifdef __USE_ISOC99
Maybe dovecot's buildsystem should check for and use -std=c99? But then I wonder why it does build for RHEL5 and all recent Fedoras? I grepped the logs and found no explicit -std switch in any of the successful builds.
Sorry, as stated in a post just moments ago, the broken build is RHEL5, and RHEL6 works.
Which gcc uses RHEL 6? It works for me with gcc-4.3 and gcc-4.4.
The gcc I used are [...]
OK, the proper matrix looks like:
RHEL4 3.4.6 fails RHEL5 4.1.2 fails F11 4.4.1 builds F12 4.4.3 builds RHEL6 (beta1) 4.4.3 builds F13 4.4.4 builds
Now it is more consistent and looks like a change between 4.1.2 and 4.4.1.
Maybe in the older gcc -std=gnu99 didn't set __USE_ISOC99 and thus the missing constants were not defined?
Axel.Thimm at ATrpms.net
On 30.5.2010, at 11.39, Axel Thimm wrote:
RHEL4 3.4.6 fails RHEL5 4.1.2 fails .. Now it is more consistent and looks like a change between 4.1.2 and 4.4.1.
Maybe in the older gcc -std=gnu99 didn't set __USE_ISOC99 and thus the missing constants were not defined?
Well, it compiles in CentOS 5.4..
On 05/30/2010 01:01 PM Timo Sirainen wrote:
Well, it compiles in CentOS 5.4..
Also on CentOS release 5.5 (Final)
[root@vh1 dovecot-2.0]# ./configure > configure.stdout [root@vh1 dovecot-2.0]# make > make.stdout --2010-05-30 14:53:56-- http://www.unicode.org/Public/UNIDATA/UnicodeData.txt Auflösen des Rechnernamens »www.unicode.org«.... 69.13.187.182 Verbindungsaufbau mit www.unicode.org[69.13.187.182]:80... verbunden. HTTP-Anfrage gesendet, warte auf Antwort... 200 OK Länge: 1239519 (1,2M) [text/plain] Speichere nach: »UnicodeData.txt«
100%[================…=============>] 1.239.519 785K/s in 1,5s
2010-05-30 14:53:58 (785 KB/s) - »UnicodeData.txt« gespeichert [1239519/1239519]
mail-host.c: In function »mail_hosts_add_range«: mail-host.c:65: Warnung: unbenutzter Parameter »list« [root@vh1 dovecot-2.0]#
Regards, Pascal
The trapper recommends today: c01dcafe.1015013@localdomain.org
Axel,
On 5/30/10 3:39 AM, "Axel Thimm" <Axel.Thimm@ATrpms.net> wrote:
Now it is more consistent and looks like a change between 4.1.2 and 4.4.1.
Maybe in the older gcc -std=gnu99 didn't set __USE_ISOC99 and thus the missing constants were not defined?
If I '%define optflags -std=gnu99' in the spec it builds just fine, so I don't think it's a compiler problem. Maybe a libtool issue?
-Brad
Hi,
On Sun, May 30, 2010 at 12:12:17PM +0100, Timo Sirainen wrote:
On 30.5.2010, at 12.03, Brandon Davidson wrote:
If I '%define optflags -std=gnu99' in the spec it builds just fine, so I don't think it's a compiler problem. Maybe a libtool issue?
Oh, the spec file overrides CFLAGS and doesn't contain -std=gnu99?
The config.log for RHEL5/x86_64 says:
CFLAGS='-std=gnu99 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -I/usr/kerberos/include '
Axel.Thimm at ATrpms.net
Axel,
On 5/30/10 10:22 AM, "Axel Thimm" <Axel.Thimm@ATrpms.net> wrote:
Oh, the spec file overrides CFLAGS and doesn't contain -std=gnu99?
The config.log for RHEL5/x86_64 says:
CFLAGS='-std=gnu99 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -I/usr/kerberos/include '
It may be a specfile after all. %configure exports CFLAGS before calling ./configure, which should be sufficient to get any needed options into the Makefile, merged with whatever configure auto-detects (including -std=gnu99).
Your spec also calls "make CFLAGS="$RPM_OPT_FLAGS" which overrides everything and omits -std=gnu99 unless specifically included by the packager. If I remove that and just call 'make' it works fine - my %optflags are merged in with the CFLAGS from configure and the build completes without error.
-Brad
Hi,
On Sun, May 30, 2010 at 12:22:52PM -0700, Brandon Davidson wrote:
On 5/30/10 10:22 AM, "Axel Thimm" <Axel.Thimm@ATrpms.net> wrote:
Oh, the spec file overrides CFLAGS and doesn't contain -std=gnu99?
The config.log for RHEL5/x86_64 says:
CFLAGS='-std=gnu99 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -I/usr/kerberos/include '
It may be a specfile after all. %configure exports CFLAGS before calling ./configure, which should be sufficient to get any needed options into the Makefile, merged with whatever configure auto-detects (including -std=gnu99).
Your spec also calls "make CFLAGS="$RPM_OPT_FLAGS" which overrides everything and omits -std=gnu99 unless specifically included by the packager.
No, that's not quite correct. If you check the above you will find that the CFLAGS passed on the make argument list is just the starting value for CFLAGS. The -std=gnu99 is added by configure, there is no need to have it added by the packager.
If I remove that and just call 'make' it works fine - my %optflags are merged in with the CFLAGS from configure and the build completes without error.
How are your %optflags (which is the same as $RPM_OPT_FLAGS) merged into the build if it is not passed to make? And it would yield the same CFLAGS as above (merged default optflags with what configure adds to it).
Axel.Thimm at ATrpms.net
On 5/30/10 2:49 PM, "Axel Thimm" <Axel.Thimm@ATrpms.net> wrote:
How are your %optflags (which is the same as $RPM_OPT_FLAGS) merged into the build if it is not passed to make? And it would yield the same CFLAGS as above (merged default optflags with what configure adds to it).
They're exported by the %configure macro, and configure writes the combined CFLAGS, CXXFLAGS, and FFLAGS into the Makefile... so it's not necessary (and possibly detrimental) to both export them before configuring and pass them explicitly to make, as the command-line CLFAGS option overrides the Makefile CFLAGS declaration that includes -std=gnu99.
My point is, if I don't inclue CFLAGS="..." in my call to make in the spec file, it builds fine, and *does* include all the necessary optflags. Give it a try.
-Brad
Hi,
On Sun, May 30, 2010 at 08:02:03PM -0700, Brandon Davidson wrote:
On 5/30/10 2:49 PM, "Axel Thimm" <Axel.Thimm@ATrpms.net> wrote:
How are your %optflags (which is the same as $RPM_OPT_FLAGS) merged into the build [...]
They're exported by the %configure macro, and configure writes the combined CFLAGS, CXXFLAGS, and FFLAGS into the Makefile... so it's not necessary (and possibly detrimental) to both export them before configuring and pass them explicitly to make, as the command-line CLFAGS option overrides the Makefile CFLAGS declaration that includes -std=gnu99.
True, I wasn't wearing my brain in the last post ;) Indeed, both configure and make were getting the same CFLAGS, and while configure was properly altering it, the make invocation was resetting it again. :/
More interesting is the fact that I introduced the bug with the dovecot-2.x specfile, so the 1.x builds were unaffected. I wonder how this did sneak in.
My point is, if I don't inclue CFLAGS="..." in my call to make in the spec file, it builds fine, and *does* include all the necessary optflags. Give it a try.
Doing so and RHEL5/x86_64 already built w/o an issue, I now quite positive that the rest including RHEL4 will be as happy!
Thanks for finding the bug!
Axel.Thimm at ATrpms.net
Axel,
On 5/30/10 12:05 AM, "Axel Thimm" <Axel.Thimm@ATrpms.net> wrote:
beta4 built under RHEL4, RHEL5 and RHEL6 (the latter being the public beta). beta5 now builds only for RHEL5, the other two fail with:
strnum.c: In function
str_to_llong': strnum.c:139: error:LLONG_MIN' undeclared (first use in this function) strnum.c:139: error: (Each undeclared identifier is reported only once strnum.c:139: error: for each function it appears in.)
FWIW, the build fails with the same error within my CentOS 5 Mock build environment. I'm not sure what I've got set up different than you, but I'm using a slightly tweaked version of your spec file and a pretty vanilla Mock 0.6 setup.
-Brad
On Sun, May 30, 2010 at 02:32:49AM -0700, Brandon Davidson wrote:
Axel,
On 5/30/10 12:05 AM, "Axel Thimm" <Axel.Thimm@ATrpms.net> wrote:
beta4 built under RHEL4, RHEL5 and RHEL6 (the latter being the public beta). beta5 now builds only for RHEL5, the other two fail with:
strnum.c: In function
str_to_llong': strnum.c:139: error:LLONG_MIN' undeclared (first use in this function) strnum.c:139: error: (Each undeclared identifier is reported only once strnum.c:139: error: for each function it appears in.)FWIW, the build fails with the same error within my CentOS 5 Mock build environment. I'm not sure what I've got set up different than you, but I'm using a slightly tweaked version of your spec file and a pretty vanilla Mock 0.6 setup.
Sorry, I mixed things up (RHEL6 beta1 is labeled as el5_89 at ATrpms).
E.g. the broken builds are RHEL4 and RHEL5, and RHEL6 beta builds.
Axel.Thimm at ATrpms.net
participants (4)
-
Axel Thimm
-
Brandon Davidson
-
Pascal Volk
-
Timo Sirainen