1.6.3 build broken using OpenSSL built with no-comp option #692

Closed
opened 2026-10-05 04:39:04 +02:00 by adam · 3 comments
Owner

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 -->
adam closed this issue 2026-10-05 04:39:04 +02:00
Author
Owner

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.

> 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 -->
Author
Owner

Ah, I was unaware of additional incompatibilities in upstream Csocket for 1.6.x.

  • The OpenBSD patch 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@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 -->
Author
Owner

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 -->
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/znc#692