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

[Alexander Sverdlin <alexander.sverdlin@gmail.com>]

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