Hello, at the moment, ngircd fails to build against openssl 1.1 since the configure check probes for the SSL_library_init symbol which was removed. Since however ngircd does not use that symbol (and appearently this did not break execution), probing for a different function availabe in both version solves that problem. Was tested (./autogen.sh && ./configure --with-openssl && make) on both Debian jessie (openssl 1.0.2) and stretch with openssl 1.1 installed. Cheers, Christoph
Hi Christoph! Am 16.11.2016 um 19:49 schrieb Christoph Biedl <ngircd.anoy@manchmal.in-ulm.de>:
at the moment, ngircd fails to build against openssl 1.1 since the configure check probes for the SSL_library_init symbol which was removed. Since however ngircd does not use that symbol (and appearently this did not break execution), probing for a different function availabe in both version solves that problem. Was tested (./autogen.sh && ./configure --with-openssl && make) on both Debian jessie (openssl 1.0.2) and stretch with openssl 1.1 installed.
Thanks for the patch, but sadly this doesn’t apply cleanly to the current Git master, because there is no „if AC_CHECK_LIB(ssl, SSL_new)“ in the code, most probably you did this agains an internal branch? And because of ngIRCd actually _using_ SSL_library_init (see src/ngircd/conn-ssl.c, line 287), I’m not sure if a simple „s/SSL_library_init/SSL_new/g“ in configure.ng is really sufficient? Probably you changed that in your branch as well? Thanks! Alex
Alexander Barton wrote...
Thanks for the patch, but sadly this doesn’t apply cleanly to the current Git master, because there is no „if AC_CHECK_LIB(ssl, SSL_new)“ in the code, most probably you did this agains an internal branch?
The patch was incomplete, sorry about that.
And because of ngIRCd actually _using_ SSL_library_init (see src/ngircd/conn-ssl.c, line 287), I’m not sure if a simple „s/SSL_library_init/SSL_new/g“ in configure.ng is really sufficient? Probably you changed that in your branch as well?
Some other things fooled me here. However I have reason to believe things can be solved much easier as SSL_library_init is no longer needed. Then the patch boils down to (still) probing SSL_new to assert libssl is available, and disabling the SSL_library_init invokation from openssl 1.1 on. Updated patch attached, see also another application[1] that did pretty much the same. However I cannot test this with certaincy since AFAICT I'd need an pretty old auto* to make the change actually work. I patched configure manually and things seemed to work. In case of doubt, just stash this somewhere and wait until somebody else complains. Christoph [1] https://www.nsca-ng.org/cgi-bin/repository/nsca-ng/commit/?id=8afc22031ff174...
Hey Christoph! Am 05.12.2016 um 20:26 schrieb Christoph Biedl <ngircd.anoy@manchmal.in-ulm.de>:
Alexander Barton wrote...
Thanks for the patch, but sadly this doesn’t apply cleanly to the current Git master, because there is no „if AC_CHECK_LIB(ssl, SSL_new)“ in the code, most probably you did this agains an internal branch?
The patch was incomplete, sorry about that.
And because of ngIRCd actually _using_ SSL_library_init (see src/ngircd/conn-ssl.c, line 287), I’m not sure if a simple „s/SSL_library_init/SSL_new/g“ in configure.ng is really sufficient? Probably you changed that in your branch as well?
Some other things fooled me here.
However I have reason to believe things can be solved much easier as SSL_library_init is no longer needed. Then the patch boils down to (still) probing SSL_new to assert libssl is available, and disabling the SSL_library_init invokation from openssl 1.1 on. Updated patch attached, see also another application[1] that did pretty much the same.
However I cannot test this with certaincy since AFAICT I'd need an pretty old auto* to make the change actually work. I patched configure manually and things seemed to work. In case of doubt, just stash this somewhere and wait until somebody else complains.
Applied to Git master branch (daa88b765111b1). Thanks! Alex
Teilnehmer (2)
-
Alexander Barton -
Christoph Biedl