[Buildroot] [PATCH] package/civetweb: fix underlinked shared library

[Buildroot] [PATCH] package/civetweb: fix underlinked shared library

[Alexander Sverdlin]

The install steps re-link libcivetweb.so but do not pass LIBS, so the link
falls back to the upstream Makefile defaults and loses the OpenSSL flags
added by the package. The correctly linked library produced by the build
step is then overwritten by an underlinked one, leaving SSL_CTX_free,
EVP_Digest and friends undefined and breaking any package linking against
-lcivetweb.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
 package/civetweb/civetweb.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/civetweb/civetweb.mk b/package/civetweb/civetweb.mk
index af221e9133..4fdd94ecc7 100644
--- a/package/civetweb/civetweb.mk
+++ b/package/civetweb/civetweb.mk
@@ -93,7 +93,7 @@ define CIVETWEB_INSTALL_STAGING_CMDS
 		PREFIX="$(STAGING_DIR)/usr" \
 		$(CIVETWEB_INSTALL_OPTS) \
 		$(CIVETWEB_CONF_OPTS) \
-		COPT='$(CIVETWEB_COPT)'
+		COPT='$(CIVETWEB_COPT)' LIBS="$(CIVETWEB_LIBS)"
 endef
 
 define CIVETWEB_INSTALL_TARGET_CMDS
@@ -102,7 +102,7 @@ define CIVETWEB_INSTALL_TARGET_CMDS
 		PREFIX="$(TARGET_DIR)/usr" \
 		$(CIVETWEB_INSTALL_OPTS) \
 		$(CIVETWEB_CONF_OPTS) \
-		COPT='$(CIVETWEB_COPT)'
+		COPT='$(CIVETWEB_COPT)' LIBS="$(CIVETWEB_LIBS)"
 endef
 
 $(eval $(generic-package))
-- 
2.55.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/civetweb: fix underlinked shared library

[Thomas Petazzoni via buildroot]

Hello Alexander,

On Sun, Aug 30, 2026 at 08:07:13PM +0200, Alexander Sverdlin wrote:
> The install steps re-link libcivetweb.so but do not pass LIBS, so the link
> falls back to the upstream Makefile defaults and loses the OpenSSL flags
> added by the package. The correctly linked library produced by the build
> step is then overwritten by an underlinked one, leaving SSL_CTX_free,
> EVP_Digest and friends undefined and breaking any package linking against
> -lcivetweb.
> 
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>

Thanks a lot for your patch. Do you have a defconfig that reproduces
the issue? The only in-tree user of civetweb is rsyslog, so I built:

BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_GLIBC_STABLE=y
BR2_PACKAGE_OPENSSL=y
BR2_PACKAGE_CIVETWEB=y
BR2_PACKAGE_CIVETWEB_LIB=y
BR2_PACKAGE_RSYSLOG=y

which builds fine. However, I agree that libcivetweb.so.1.16.0 uses
SSL symbols but is not linked against libcrypto.

What's mostly missing from your commit is an indication of what
introduced the problem. Is this a recent issue? Does it exist since
civetweb was added in Buildroot?

Or perhaps since LIBS was started being used in commit
3cf5b3019118cdc980666d7a1ccfd29f658d0261 ?

>  package/civetweb/civetweb.mk | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/package/civetweb/civetweb.mk b/package/civetweb/civetweb.mk
> index af221e9133..4fdd94ecc7 100644
> --- a/package/civetweb/civetweb.mk
> +++ b/package/civetweb/civetweb.mk
> @@ -93,7 +93,7 @@ define CIVETWEB_INSTALL_STAGING_CMDS
>  		PREFIX="$(STAGING_DIR)/usr" \
>  		$(CIVETWEB_INSTALL_OPTS) \
>  		$(CIVETWEB_CONF_OPTS) \
> -		COPT='$(CIVETWEB_COPT)'
> +		COPT='$(CIVETWEB_COPT)' LIBS="$(CIVETWEB_LIBS)"

And I assume fixing the build system so that it doesn't re-link at
install time is not doable? :-)

Small nit: for me "underlinked" is a bit hard to understand. Perhaps
"fix linking against dependant shared libraries" or something like
that?

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/civetweb: fix underlinked shared library

[Alexander Sverdlin]

Hi Thomas,

On Wed, 2026-09-16 at 23:33 +0200, Thomas Petazzoni wrote:
> > The install steps re-link libcivetweb.so but do not pass LIBS, so the link
> > falls back to the upstream Makefile defaults and loses the OpenSSL flags
> > added by the package. The correctly linked library produced by the build
> > step is then overwritten by an underlinked one, leaving SSL_CTX_free,
> > EVP_Digest and friends undefined and breaking any package linking against
> > -lcivetweb.
> > 
> > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> 
> Thanks a lot for your patch. Do you have a defconfig that reproduces
> the issue? The only in-tree user of civetweb is rsyslog, so I built:

I'm working on a new package which builds an executable against -lcivetweb...

> BR2_aarch64=y
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
> BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_GLIBC_STABLE=y
> BR2_PACKAGE_OPENSSL=y
> BR2_PACKAGE_CIVETWEB=y
> BR2_PACKAGE_CIVETWEB_LIB=y
> BR2_PACKAGE_RSYSLOG=y
> 
> which builds fine. However, I agree that libcivetweb.so.1.16.0 uses
> SSL symbols but is not linked against libcrypto.

There seem to be two independent reasons why rsyslog can be built successfully:

configure.ac:2101 uses AC_SEARCH_LIBS(mg_version, civetweb) with no
action-if-not-found. The test link is an executable and does fail (undefined
reference to SSL_CTX_free, …), but the failure is silently swallowed;
CIVETWEB_LIBS=-lcivetweb is hardcoded right after regardless.

contrib/imhttp/Makefile.am builds imhttp.la as a libtool -module, i.e. a shared
object. GNU ld only errors on undefined symbols pulled in from shared libraries
when producing an executable; for a shared object it allows them.

So nothing in-tree ever links an executable against -lcivetweb, which is why
the bug is invisible in the autobuilders. It is still a latent runtime bug:
rsyslogd dlopen'ing imhttp.so only works because rsyslog itself drags
libssl/libcrypto into the global scope.

> What's mostly missing from your commit is an indication of what
> introduced the problem. Is this a recent issue? Does it exist since
> civetweb was added in Buildroot?
> 
> Or perhaps since LIBS was started being used in commit
> 3cf5b3019118cdc980666d7a1ccfd29f658d0261 ?

It seems to be db47bc99976c2d4ffb509620a76cfdd369b30559
("package/civetweb: bump version to 1.11"), which introduced
CIVETWEB_BUILD_TARGETS/CIVETWEB_INSTALL_TARGETS, the slib/install-slib targets
and CIVETWEB_INSTALL_STAGING_CMDS — all without LIBS.

> >  package/civetweb/civetweb.mk | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/package/civetweb/civetweb.mk b/package/civetweb/civetweb.mk
> > index af221e9133..4fdd94ecc7 100644
> > --- a/package/civetweb/civetweb.mk
> > +++ b/package/civetweb/civetweb.mk
> > @@ -93,7 +93,7 @@ define CIVETWEB_INSTALL_STAGING_CMDS
> >  		PREFIX="$(STAGING_DIR)/usr" \
> >  		$(CIVETWEB_INSTALL_OPTS) \
> >  		$(CIVETWEB_CONF_OPTS) \
> > -		COPT='$(CIVETWEB_COPT)'
> > +		COPT='$(CIVETWEB_COPT)' LIBS="$(CIVETWEB_LIBS)"
> 
> And I assume fixing the build system so that it doesn't re-link at
> install time is not doable? :-)

It turns to be a oneliner in their Makefile, so I'll pursue an upstream
fix! 

> Small nit: for me "underlinked" is a bit hard to understand. Perhaps
> "fix linking against dependant shared libraries" or something like
> that?
> 
> Thanks a lot!

Thanks for the review!

-- 
Alexander Sverdlin.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot