Re: Timo - is the v2.3.15 GCC limitation really necessarily or it's just a bug?

[Bernd Petrovitsch]

Hi all!

On 01/08/2021 23:24, Aki Tuomi wrote:
>> On 01/08/2021 23:44 Michael Orlitzky  wrote:
[...]
>> On Sun, 2021-08-01 at 21:53 +0300, Mart Pirita wrote:
>>>
>>> As Docvecot does not support INC_PATH= and ignores --includedir= option, 
>>
>> You can try CPPFLAGS="-I" in the future. I don't know how a
>> normal person would ever figure it out, but that's the "correct" way to

Just write Makefiles (or read the docs of `make`);-)

>> include headers from a non-default directory.
> 
> That's a feature of autoconf, documented in e.g. 
> https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Preset-Output-Variables.html.
>  You can use ./configure ... EXTRA_CFLAGS or CPPFLAGS. The EXTRA_CFLAGS is 
> dovecot specific.

CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS, LDLIBS (and a lot more) are
actually used/defined by the default rules of `make`.
autoconf just generates shell scripts and Makefiles as it uses
`make` ...

MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 There is NO CLOUD, just other people's computers. - FSFE
 LUGA : http://www.luga.at

Re: Timo - is the v2.3.15 GCC limitation really necessarily or it's just a bug?

[Aki Tuomi]

> On 01/08/2021 23:44 Michael Orlitzky  wrote:
> 
>  
> On Sun, 2021-08-01 at 21:53 +0300, Mart Pirita wrote:
> > 
> > As Docvecot does not support INC_PATH= and ignores --includedir= option, 
> 
> You can try CPPFLAGS="-I" in the future. I don't know how a
> normal person would ever figure it out, but that's the "correct" way to
> include headers from a non-default directory.

That's a feature of autoconf, documented in e.g. 
https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Preset-Output-Variables.html.
 You can use ./configure ... EXTRA_CFLAGS or CPPFLAGS. The EXTRA_CFLAGS is 
dovecot specific.

Aki

Re: Timo - is the v2.3.15 GCC limitation really necessarily or it's just a bug?

[Michael Orlitzky]

On Sun, 2021-08-01 at 21:53 +0300, Mart Pirita wrote:
> 
> As Docvecot does not support INC_PATH= and ignores --includedir= option, 

You can try CPPFLAGS="-I" in the future. I don't know how a
normal person would ever figure it out, but that's the "correct" way to
include headers from a non-default directory.

Re: Timo - is the v2.3.15 GCC limitation really necessarily or it's just a bug?

[Mart Pirita]

Hi,

Update:

1) Centos 5 and 6, compiled GCC 4.8.5 and successfully built Dovecot v2.3.15.

2) RedHat based customized build, first compiled GCC 4.7.4 and with it compiled 
GCC 4.8.5, then added --disable-hardening to options, got new error:

In file included from /usr/include/sys/wait.h:79:0,
 from db-checkpassword.c:21:
db-checkpassword.c: In function 'sigchld_handler':
db-checkpassword.c:426:6: error: assignment of read-only member '__in'
  if (WIFSIGNALED(status->status)) {
  ^
...

As Docvecot does not support INC_PATH= and ignores --includedir= option, I 
replaced the /usr/include/sys/wait.h file from the newer glibc-headers package 
and successfully built Dovecot v2.3.15.


Old text:

Compiled GCC 4.7.4 with options:
--enable-languages=c,c++ --disable-multilib

Compiled Dovecot v2.3.15 wih options:
export CC=/usr/local/gcc-4.7.4/bin/gcc
export CXX=/usr/local/gcc-4.7.4/bin/g++

./configure --prefix=/usr --with-ssl=openssl --with-ssldir=/etc/ssl 
--sysconfdir=/etc --with-pam --without-bsdauth --without-sql --without-nss 
--without-ldap --without-pgsql --without-mysql --without-sqlite 
--with-rundir=/var/run/dovecot --without-cassandra --without-lucene 
--without-solr --without-textcat --without-libcap --without-stemmer 
--disable-rpath --disable-dependency-tracking --disable-silent-rules 
--without-gssapi --without-cdb

Got error:
configure: error: fd passing is required for Dovecot to work

Added --disable-hardening and got further, but then with GCC 4.7.4, now I'm 
getting same old error, which I first got 4 years ago with version v2.2.30 and 
which Timo fixed - https://dovecot.org/list/dovecot/2017-June/108418.html 

db-checkpassword.c: In function 'sigchld_handler':
db-checkpassword.c:426:6: error: assignment of read-only member '__in'
db-checkpassword.c:427:3: error: assignment of read-only member '__in'
db-checkpassword.c:431:13: error: assignment of read-only member '__in'
db-checkpassword.c:432:26: error: assignment of read-only member '__in'
make[3]: *** [db-checkpassword.lo] Error 1

Due GCC segmentation faults during compilation, so far I'm unable to compile 
any newer GCC, but got also same result with GCC 4.6.4.

Please advise?


Mart

Timo Sirainen wrote:
> On 29. Jul 2021, at 7.21, Mart Pirita  > wrote:
>>
>> Hello.
>>
>> So far I have successfully built Dovecot until v2.3.14 on Centos 4-6 (yes I 
>> know, they are old, but as they are remote servers, distros can't upgraded), 
>> and sometimes I have also met compilation issues, but after highlighting 
>> them, Timo have fixed the code.
>>
>> Found from similar thread (Dovecot 2.3.15 compilation fails 
>> https://dovecot.org/list/dovecot/2021-June/122412.html ) that new GCC is 
>> needed. However I can't find such requirement in v2.3.15 change log.
> 
> Looks like we forgot to mention that.
> 
>> As seems that I'm not the only one with compilation issues, then @Timo - can 
>> You please fix the code so that also v2.3.15 can compiled on older distros?
> 
> Sorry, it's no longer possible. The buffer.h API had to be changed to fix 
> some real bugs: 
> https://github.com/dovecot/core/commit/1d9b4e14008b15b7a34b5c633b09b9670e866256
> 
> The original way I changed it would have made the code more complex and it 
> was also a huge change. The final method was much simpler, but it requires 
> now compiler support for anonymous unions and anonymous structs, i.e. C11. 
> Although some older GCCs should also support it, but I guess you've a too old 
> version.
> 

Re: Timo - is the v2.3.15 GCC limitation really necessarily or it's just a bug?

[Mart Pirita]

Hi,

Compiled GCC 4.7.4 with options:
--enable-languages=c,c++ --disable-multilib

Compiled Dovecot v2.3.15 wih options:
export CC=/usr/local/gcc-4.7.4/bin/gcc
export CXX=/usr/local/gcc-4.7.4/bin/g++

./configure --prefix=/usr --with-ssl=openssl --with-ssldir=/etc/ssl 
--sysconfdir=/etc --with-pam --without-bsdauth --without-sql --without-nss 
--without-ldap --without-pgsql --without-mysql --without-sqlite 
--with-rundir=/var/run/dovecot --without-cassandra --without-lucene 
--without-solr --without-textcat --without-libcap --without-stemmer 
--disable-rpath --disable-dependency-tracking --disable-silent-rules 
--without-gssapi --without-cdb

Got error:
configure: error: fd passing is required for Dovecot to work

Added --disable-hardening and got further, but then with GCC 4.7.4, now I'm 
getting same old error, which I first got 4 years ago with version v2.2.30 and 
which Timo fixed - https://dovecot.org/list/dovecot/2017-June/108418.html 

db-checkpassword.c: In function 'sigchld_handler':
db-checkpassword.c:426:6: error: assignment of read-only member '__in'
db-checkpassword.c:427:3: error: assignment of read-only member '__in'
db-checkpassword.c:431:13: error: assignment of read-only member '__in'
db-checkpassword.c:432:26: error: assignment of read-only member '__in'
make[3]: *** [db-checkpassword.lo] Error 1

Due GCC segmentation faults during compilation, so far I'm unable to compile 
any newer GCC, but got also same result with GCC 4.6.4.

Please advise?


Mart

Timo Sirainen wrote:
> On 29. Jul 2021, at 7.21, Mart Pirita  > wrote:
>>
>> Hello.
>>
>> So far I have successfully built Dovecot until v2.3.14 on Centos 4-6 (yes I 
>> know, they are old, but as they are remote servers, distros can't upgraded), 
>> and sometimes I have also met compilation issues, but after highlighting 
>> them, Timo have fixed the code.
>>
>> Found from similar thread (Dovecot 2.3.15 compilation fails 
>> https://dovecot.org/list/dovecot/2021-June/122412.html ) that new GCC is 
>> needed. However I can't find such requirement in v2.3.15 change log.
> 
> Looks like we forgot to mention that.
> 
>> As seems that I'm not the only one with compilation issues, then @Timo - can 
>> You please fix the code so that also v2.3.15 can compiled on older distros?
> 
> Sorry, it's no longer possible. The buffer.h API had to be changed to fix 
> some real bugs: 
> https://github.com/dovecot/core/commit/1d9b4e14008b15b7a34b5c633b09b9670e866256
> 
> The original way I changed it would have made the code more complex and it 
> was also a huge change. The final method was much simpler, but it requires 
> now compiler support for anonymous unions and anonymous structs, i.e. C11. 
> Although some older GCCs should also support it, but I guess you've a too old 
> version.
> 

Re: Timo - is the v2.3.15 GCC limitation really necessarily or it's just a bug?

[Perry E. Metzger]

On 7/29/21 07:33, Mart Pirita wrote:

This is very bad news.

I don't think that disto is old, if I can compile almost every software with it.

So at the moment I have two choices, newer upgrade Dovecot or rollback the 
buffer_t changes and use latest version?


Just fyi, Centos provides an unusably old version of GCC for many 
purposes. C11 support went into GCC a decade ago. I don't know why the 
Centos GCC is so very very old, but you _can_ install a package with a 
newer one. It's been long enough that I can't remember how you do that 
but it shouldn't be too hard to learn how.


Perry

Re: Timo - is the v2.3.15 GCC limitation really necessarily or it's just a bug?

[Adi Pircalabu]

On 29-07-2021 21:33, Mart Pirita wrote:

Hi,

This is very bad news.

I don't think that disto is old, if I can compile almost every software 
with it.


If that CentOS distro is EOL and/or you can't even find the source rpms 
to compile/rebuild them to retrofit patches addressing security 
vulnerabilities, with or without devtoolset, *THIS* is very, very bad 
news.

Just saying.

--
Adi Pircalabu

Re: Timo - is the v2.3.15 GCC limitation really necessarily or it's just a bug?

[Gerald Galster]

> You can use Developer Toolset.  It comes with newer GCC versions.  I
> don't know the precise CentOS repository layout, but there is a
> devtoolset-7-gcc package somewhere.


SCL is included with CentOS, see:

https://www.softwarecollections.org/en/scls/rhscl/devtoolset-7/
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-8/

As CentOS 6 is end of life you could find packages here:
https://vault.centos.org/6.10/sclo/x86_64/rh/Packages/d/

Best regards
Gerald

Re: Timo - is the v2.3.15 GCC limitation really necessarily or it's just a bug?

[Florian Weimer]

* Mart Pirita:

> So at the moment I have two choices, newer upgrade Dovecot or rollback
> the buffer_t changes and use latest version?

You can use Developer Toolset.  It comes with newer GCC versions.  I
don't know the precise CentOS repository layout, but there is a
devtoolset-7-gcc package somewhere.

Thanks,
Florian

Re: Timo - is the v2.3.15 GCC limitation really necessarily or it's just a bug?

[Michael Orlitzky]

On Thu, 2021-07-29 at 14:33 +0300, Mart Pirita wrote:
> Hi,
> 
> 
> This is very bad news.
> 
> I don't think that disto is old, if I can compile almost every
> software with it.
> 
> So at the moment I have two choices, newer upgrade Dovecot or
> rollback the buffer_t changes and use latest version?
> 
> 

If you're willing to build dovecot from source to obtain a newer
version than CentOS provides, you could always do the same thing with
GCC or clang.

Dovecot should respect things like CC=/usr/local/bin/gcc-11

Re: Timo - is the v2.3.15 GCC limitation really necessarily or it's just a bug?

[Mart Pirita]

Hi,


This is very bad news.

I don't think that disto is old, if I can compile almost every software with it.

So at the moment I have two choices, newer upgrade Dovecot or rollback the 
buffer_t changes and use latest version?


Mart

Timo Sirainen wrote:
> On 29. Jul 2021, at 7.21, Mart Pirita  > wrote:
>>
>> Hello.
>>
>> So far I have successfully built Dovecot until v2.3.14 on Centos 4-6 (yes I 
>> know, they are old, but as they are remote servers, distros can't upgraded), 
>> and sometimes I have also met compilation issues, but after highlighting 
>> them, Timo have fixed the code.
>>
>> Found from similar thread (Dovecot 2.3.15 compilation fails 
>> https://dovecot.org/list/dovecot/2021-June/122412.html ) that new GCC is 
>> needed. However I can't find such requirement in v2.3.15 change log.
> 
> Looks like we forgot to mention that.
> 
>> As seems that I'm not the only one with compilation issues, then @Timo - can 
>> You please fix the code so that also v2.3.15 can compiled on older distros?
> 
> Sorry, it's no longer possible. The buffer.h API had to be changed to fix 
> some real bugs: 
> https://github.com/dovecot/core/commit/1d9b4e14008b15b7a34b5c633b09b9670e866256
> 
> The original way I changed it would have made the code more complex and it 
> was also a huge change. The final method was much simpler, but it requires 
> now compiler support for anonymous unions and anonymous structs, i.e. C11. 
> Although some older GCCs should also support it, but I guess you've a too old 
> version.
> 

Re: Timo - is the v2.3.15 GCC limitation really necessarily or it's just a bug?

[Timo Sirainen]

On 29. Jul 2021, at 7.21, Mart Pirita  wrote:
> 
> Hello.
> 
> So far I have successfully built Dovecot until v2.3.14 on Centos 4-6 (yes I 
> know, they are old, but as they are remote servers, distros can't upgraded), 
> and sometimes I have also met compilation issues, but after highlighting 
> them, Timo have fixed the code.
> 
> Found from similar thread (Dovecot 2.3.15 compilation fails 
> https://dovecot.org/list/dovecot/2021-June/122412.html ) that new GCC is 
> needed. However I can't find such requirement in v2.3.15 change log.

Looks like we forgot to mention that.

> As seems that I'm not the only one with compilation issues, then @Timo - can 
> You please fix the code so that also v2.3.15 can compiled on older distros?

Sorry, it's no longer possible. The buffer.h API had to be changed to fix some 
real bugs: 
https://github.com/dovecot/core/commit/1d9b4e14008b15b7a34b5c633b09b9670e866256 


The original way I changed it would have made the code more complex and it was 
also a huge change. The final method was much simpler, but it requires now 
compiler support for anonymous unions and anonymous structs, i.e. C11. Although 
some older GCCs should also support it, but I guess you've a too old version.

Timo - is the v2.3.15 GCC limitation really necessarily or it's just a bug?

[Mart Pirita]

Hello.

So far I have successfully built Dovecot until v2.3.14 on Centos 4-6 (yes I 
know, they are old, but as they are remote servers, distros can't upgraded), 
and sometimes I have also met compilation issues, but after highlighting them, 
Timo have fixed the code.

Found from similar thread (Dovecot 2.3.15 compilation fails 
https://dovecot.org/list/dovecot/2021-June/122412.html ) that new GCC is 
needed. However I can't find such requirement in v2.3.15 change log.

As seems that I'm not the only one with compilation issues, then @Timo - can 
You please fix the code so that also v2.3.15 can compiled on older distros?

Compilation options:
./configure --prefix=/usr --with-ssl=openssl --with-ssldir=/etc/ssl 
--sysconfdir=/etc --with-pam --without-bsdauth --without-sql --without-nss 
--without-ldap --without-pgsql --without-mysql --without-sqlite 
--with-rundir=/var/run/dovecot --without-cassandra --without-lucene 
--without-solr --without-textcat --without-libcap --without-stemmer 
--disable-rpath --disable-dependency-tracking --disable-silent-rules 
--without-gssapi --without-cdb

Compilation error:
builtin-strftime  -c -o test-smtp-params.o test-smtp-params.c
test-smtp-params.c:29: error: unknown field `data' specified in initializer
test-smtp-params.c:29: warning: missing braces around initializer
test-smtp-params.c:29: warning: (near initialization for 
`test_params_buffer1.')
test-smtp-params.c:30: warning: missing initializer
test-smtp-params.c:30: warning: (near initialization for 
`test_params_buffer1...used')
test-smtp-params.c:30: error: unknown field `used' specified in initializer
test-smtp-params.c:31: warning: excess elements in struct initializer
test-smtp-params.c:31: warning: (near initialization for `test_params_buffer1')
test-smtp-params.c:33: error: unknown field `data' specified in initializer
test-smtp-params.c:33: warning: missing braces around initializer
test-smtp-params.c:33: warning: (near initialization for 
`test_params_buffer2.')
test-smtp-params.c:34: warning: missing initializer
test-smtp-params.c:34: warning: (near initialization for 
`test_params_buffer2...used')
test-smtp-params.c:34: error: unknown field `used' specified in initializer
test-smtp-params.c:35: warning: excess elements in struct initializer
test-smtp-params.c:35: warning: (near initialization for `test_params_buffer2')
make[3]: *** [test-smtp-params.o] Error 1
make[3]: Leaving directory `/usr/src/redhat/BUILD/dovecot-2.3.15/src/lib-smtp'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/redhat/BUILD/dovecot-2.3.15/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/dovecot-2.3.15'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.7364 (%build)

-- 
Mart