Compiling znc 1.6.3 using OpenSSL 1.0.2g built with the no-comp option results in the following:
Linking znc...
src/Csocket.o: In function `InitSSL(ECompType)':
/tmp/tmp.egENlxZFXa/znc-1.6.3/src/Csocket.cpp:587: undefined reference to `COMP_rle'
/tmp/tmp.egENlxZFXa/znc-1.6.3/src/Csocket.cpp:580: undefined reference to `COMP_zlib'
collect2: error: ld returned 1 exit status
make: *** [znc] Error 1
Rebuilding OpenSSL without the no-comp option results in successful znc build.
Applying the OpenBSD Csocket patch linked in #594 and using the earlier, problematic OpenSSL built with no-comp option also results in successful znc build.
Digging around, it would appear that the Csocket submodule on the 1.6.x branch is pointing to an older revision that only partially fixes the problem referred to in #594. I don't know if there is a way to specify a no-comp option in LibreSSL, but if there is then that presumably also breaks znc 1.6.3's build. A newer revision of Csocket would also bring support for BoringSSL.
Please could c6ed6b2ee4 from the master branch (or any later upstream revision) be applied to the 1.6.x branch for the next release?
Compiling znc 1.6.3 using OpenSSL 1.0.2g built with the `no-comp` option results in the following:
```
Linking znc...
src/Csocket.o: In function `InitSSL(ECompType)':
/tmp/tmp.egENlxZFXa/znc-1.6.3/src/Csocket.cpp:587: undefined reference to `COMP_rle'
/tmp/tmp.egENlxZFXa/znc-1.6.3/src/Csocket.cpp:580: undefined reference to `COMP_zlib'
collect2: error: ld returned 1 exit status
make: *** [znc] Error 1
```
- Rebuilding OpenSSL without the `no-comp` option results in successful znc build.
- Applying the OpenBSD Csocket patch linked in #594 and using the earlier, problematic OpenSSL built with `no-comp` option also results in successful znc build.
Digging around, it would appear that the Csocket submodule on the 1.6.x branch is pointing to an older revision that only partially fixes the problem referred to in #594. I don't know if there is a way to specify a `no-comp` option in LibreSSL, but if there is then that presumably also breaks znc 1.6.3's build. A newer revision of Csocket would also bring support for BoringSSL.
Please could c6ed6b2ee47fc43f40f6888c499f6143b0c8cd0f from the master branch (or any later upstream revision) be applied to the 1.6.x branch for the next release?
##
<!-- github-sync-id:144777149 -->
Probably noone tried yet to build ZNC with OpenSSL with no-comp. If the patch fixes it, the patch should be pushed to upstream Csocket, but in a way compatible with ZNC 1.6.x, if you want to see it in ZNC 1.6.x. Basically, checkout the current commit used by 1.6.x, apply the patch, and merge the result to master. Then ZNC can move its Csocket submodule by this one commit.
At some point ZNC 1.7.0 will be released with Csocket from master.
> Csocket submodule on the 1.6.x branch is pointing to an older revision
Correct. Master branch of Csocket has too many ABI-breaking changes.
> Please could c6ed6b2 from the master branch (or any later upstream revision) be applied to the 1.6.x branch for the next release?
Does ZNC build for you with this patched in? Note that the OpenBSD patch is different from https://github.com/jimloco/Csocket/pull/49 mentioned in #594
Probably noone tried yet to build ZNC with OpenSSL with `no-comp`. If the patch fixes it, the patch should be pushed to upstream Csocket, but in a way compatible with ZNC 1.6.x, if you want to see it in ZNC 1.6.x. Basically, checkout the current commit used by 1.6.x, apply the patch, and merge the result to master. Then ZNC can move its Csocket submodule by this one commit.
At some point ZNC 1.7.0 will be released with Csocket from master.
<!-- github-comment-id:204163440 -->
For what it's worth, I was even able to compile 1.6.3 using the head revision of Csocket:
sed -e 's/^#include "defines\.h"$/#include <znc\/defines.h>/' ~/Csocket.h > include/znc/Csocket.h
sed -e 's/^#include "Csocket\.h"$/#include <znc\/Csocket.h>/' ~/Csocket.cc > src/Csocket.cpp
My inexperience with C/C++ means I'm not sure at what point ABI incompatibility might be relevant, but the latter seems to be running fine for me so far (the diff showed a lot of changes related to ICU that I don't use, if that's where the compatibility issues are).
Given that my changes may have side-effects I haven't foreseen, I'm not confident enough to send anything upstream myself. My suggestion to use a later revision was based on looking at the Csocket commit log and seeing the BoringSSL support (that, deliberately or not, contains the OpenBSD patch anyway) immediately after the LibreSSL fix on the same day. Is there no way for znc 1.6.x branch to cherry-pick just jimloco/Csocket@d81a18d87d?
Either way, I'm fine with waiting for 1.7 since as you say probably nobody else tried to build with no-comp.
Ah, I was unaware of additional incompatibilities in upstream Csocket for 1.6.x.
- The [OpenBSD patch](http://openbsd.comstyle.com/cgi/cvsweb/ports/net/znc/patches/Attic/patch-src_Csocket_cpp?rev=1.1&content-type=text/x-cvsweb-markup) that simply wraps the failing section in an `#ifndef OPENSSL_NO_COMP` check compiled successfully:
```
patch src/Csocket.cpp ~/src_Csocket_cpp.patch
```
- The OpenBSD patch plus wrapping jimloco/Csocket#49 in an `#ifndef OPENSSL_NO_COMP` check also compiled successfully:
```
patch src/Csocket.cpp ~/src_Csocket_cpp.patch
sed -i'' -e '/^#include <openssl\/comp\.h>$/{i #ifndef OPENSSL_NO_COMP
;a #endif
}' src/Csocket.cpp
```
- For what it's worth, I was even able to compile 1.6.3 using the head revision of Csocket:
```
sed -e 's/^#include "defines\.h"$/#include <znc\/defines.h>/' ~/Csocket.h > include/znc/Csocket.h
sed -e 's/^#include "Csocket\.h"$/#include <znc\/Csocket.h>/' ~/Csocket.cc > src/Csocket.cpp
```
My inexperience with C/C++ means I'm not sure at what point ABI incompatibility might be relevant, but the latter seems to be running fine for me so far (the diff showed a lot of changes related to ICU that I don't use, if that's where the compatibility issues are).
Given that my changes may have side-effects I haven't foreseen, I'm not confident enough to send anything upstream myself. My suggestion to use a later revision was based on looking at the Csocket commit log and seeing the BoringSSL support (that, deliberately or not, contains the OpenBSD patch anyway) immediately after the LibreSSL fix on the same day. Is there no way for znc 1.6.x branch to cherry-pick just jimloco/Csocket@d81a18d87d15bbf54ddbd675bfa829cf7dfdce9e?
Either way, I'm fine with waiting for 1.7 since as you say probably nobody else tried to build with `no-comp`.
<!-- github-comment-id:204265522 -->
Since my upstream implementation of OpenSSL 1.1 support cherry-picked the necessary commit and the znc submodule now includes it in the 1.6.x branch, a 1.6.4 release will resolve this issue.
Since my upstream implementation of OpenSSL 1.1 support cherry-picked the necessary commit and the znc submodule now includes it in the 1.6.x branch, a 1.6.4 release will resolve this issue.
<!-- github-comment-id:261982708 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Compiling znc 1.6.3 using OpenSSL 1.0.2g built with the
no-compoption results in the following:no-compoption results in successful znc build.no-compoption also results in successful znc build.Digging around, it would appear that the Csocket submodule on the 1.6.x branch is pointing to an older revision that only partially fixes the problem referred to in #594. I don't know if there is a way to specify a
no-compoption in LibreSSL, but if there is then that presumably also breaks znc 1.6.3's build. A newer revision of Csocket would also bring support for BoringSSL.Please could
c6ed6b2ee4from the master branch (or any later upstream revision) be applied to the 1.6.x branch for the next release?Correct. Master branch of Csocket has too many ABI-breaking changes.
Does ZNC build for you with this patched in? Note that the OpenBSD patch is different from https://github.com/jimloco/Csocket/pull/49 mentioned in #594
Probably noone tried yet to build ZNC with OpenSSL with
no-comp. If the patch fixes it, the patch should be pushed to upstream Csocket, but in a way compatible with ZNC 1.6.x, if you want to see it in ZNC 1.6.x. Basically, checkout the current commit used by 1.6.x, apply the patch, and merge the result to master. Then ZNC can move its Csocket submodule by this one commit.At some point ZNC 1.7.0 will be released with Csocket from master.
Ah, I was unaware of additional incompatibilities in upstream Csocket for 1.6.x.
#ifndef OPENSSL_NO_COMPcheck compiled successfully:#ifndef OPENSSL_NO_COMPcheck also compiled successfully:My inexperience with C/C++ means I'm not sure at what point ABI incompatibility might be relevant, but the latter seems to be running fine for me so far (the diff showed a lot of changes related to ICU that I don't use, if that's where the compatibility issues are).
Given that my changes may have side-effects I haven't foreseen, I'm not confident enough to send anything upstream myself. My suggestion to use a later revision was based on looking at the Csocket commit log and seeing the BoringSSL support (that, deliberately or not, contains the OpenBSD patch anyway) immediately after the LibreSSL fix on the same day. Is there no way for znc 1.6.x branch to cherry-pick just jimloco/Csocket@d81a18d87d?
Either way, I'm fine with waiting for 1.7 since as you say probably nobody else tried to build with
no-comp.Since my upstream implementation of OpenSSL 1.1 support cherry-picked the necessary commit and the znc submodule now includes it in the 1.6.x branch, a 1.6.4 release will resolve this issue.