[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:
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:
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:
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 12:30:48PM +0300, Axel Thimm wrote:
Sorry, as stated in a post just moments ago, the broken build is RHEL5, and RHEL6 works.
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 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
Hi,
On Sun, May 30, 2010 at 12:12:17PM +0100, Timo Sirainen wrote:
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:
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:
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.
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:
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:
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.
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:
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
participants (4)
-
Axel Thimm
-
Brandon Davidson
-
Pascal Volk
-
Timo Sirainen