diff mbox series

[1/1] package/apr: link with -lm

Message ID 20251005123246.1165560-1-bernd@kuhls.net
State New
Headers show
Series [1/1] package/apr: link with -lm | expand

Commit Message

Bernd Kuhls Oct. 5, 2025, 12:32 p.m. UTC
Fixes Apache runtime error:

    /usr/bin/httpd: Relink `/usr/lib64/libapr-1.so.0' with `/lib64/libm.so.6' for IFUNC symbol `modf'

caused by glibc bump to 2.42 with buildroot commit
fb6256c0efbc93d242e9ae2aa2d3b4a2e7fd149c.

Configure check of apr does not detect the need for -lm:
    checking for library containing modf... none required

Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
---
 package/apr/apr.mk | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Thomas Petazzoni Jan. 2, 2026, 3:39 p.m. UTC | #1
Hello Bernd,

On Sun,  5 Oct 2025 14:32:46 +0200
Bernd Kuhls <bernd@kuhls.net> wrote:

> Fixes Apache runtime error:
> 
>     /usr/bin/httpd: Relink `/usr/lib64/libapr-1.so.0' with `/lib64/libm.so.6' for IFUNC symbol `modf'
> 
> caused by glibc bump to 2.42 with buildroot commit
> fb6256c0efbc93d242e9ae2aa2d3b4a2e7fd149c.
> 
> Configure check of apr does not detect the need for -lm:
>     checking for library containing modf... none required
> 
> Signed-off-by: Bernd Kuhls <bernd@kuhls.net>

Thanks for this patch, however I believe the investigation is not
really sufficient/convincing.

Why is the configure.ac check not detecting that it should link with
-lm? I did build apr, and the configure.ac check indeed detects that
linking with -lm is not needed to use modf(), and a simple test with a
trivial program calling modf() confirms that.

So why does that work, while apache complains at runtime about libapr
having to be linked with libm?

Also, what changed in glibc 2.42 that causes a difference here? Did you
indeed confirm that the problem doesn't exist with glibc 2.41, and
exists with glibc 2.42 ?

Thanks!

Thomas
Bernd Kuhls Jan. 2, 2026, 4:07 p.m. UTC | #2
Hi Thomas,

Am Fri, 2 Jan 2026 16:39:27 +0100 schrieb Thomas Petazzoni via buildroot:

> Hello Bernd,
> 
> On Sun,  5 Oct 2025 14:32:46 +0200 Bernd Kuhls
> <bernd@kuhls.net> wrote:
> 
>> Fixes Apache runtime error:
>> 
>>     /usr/bin/httpd: Relink `/usr/lib64/libapr-1.so.0' with
>>     `/lib64/libm.so.6' for IFUNC symbol `modf'
>> 
>> caused by glibc bump to 2.42 with buildroot commit
>> fb6256c0efbc93d242e9ae2aa2d3b4a2e7fd149c.
>> 
>> Configure check of apr does not detect the need for -lm:
>>     checking for library containing modf... none required
>> 
> 
> Thanks for this patch, however I believe the investigation is not really
> sufficient/convincing.

due to my limited knowledge this does not surprise me ;)

> So why does that work, while apache complains at runtime about libapr
> having to be linked with libm?

I do not know.

> Also, what changed in glibc 2.42 that causes a difference here? Did you
> indeed confirm that the problem doesn't exist with glibc 2.41, and
> exists with glibc 2.42 ?

Yes, the error occured after I updated glibc from 2.41 to 2.42. After 
buildroot initially bumped glibc (Jul 30th, 2025) I immediately reverted 
that commit after the first boot seeing Apache crash. This glibc revert 
alone fixed the Apache crash so I am 100% sure that glibc 2.42 caused the 
error.

In October I found some time to re-visit the topic and, based on the error 
message to link with libm, I came up with this patch (and removed the 
glibc-2.42 revert at the same time) and Apache does not crash anymore.

Regards, Bernd
diff mbox series

Patch

diff --git a/package/apr/apr.mk b/package/apr/apr.mk
index 1c7553a501..98a7ece620 100644
--- a/package/apr/apr.mk
+++ b/package/apr/apr.mk
@@ -50,6 +50,10 @@  APR_CONF_ENV = \
 	apr_preload_done=yes
 APR_CONFIG_SCRIPTS = apr-1-config
 
+ifeq ($(BR2_PACKAGE_GLIBC),y)
+APR_CONF_ENV += LIBS=-lm
+endif
+
 # Doesn't even try to guess when cross compiling
 ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
 APR_CONF_ENV += apr_cv_pthreads_lib="-lpthread"