From: Matthias Andree <matthias.andree@gmx.de>
Subject: Re: Bug: several databases' pkg-config .pc files lack -lpthread
To: ports@openbsd.org
Date: Mon, 14 Jul 2025 23:18:42 +0200

Am 14.07.25 um 12:59 schrieb Stuart Henderson:
> On 2025/07/14 10:40, Matthias Andree wrote:
>> It is conventional for OpenBSD to open bug reports for ports through
>> sendbug(1) or via bugs@?  I skimmed a bit through the ports FAQ and
>> "Reporting problems" and a few messages randomly picked from the June and
>> July 2025 ports mailing list archives, and it doesn't look so.
> email to ports@ and/or the person listed as maintainer of the relevant port.
>
>> The issue is that at least these two ports guys
>>
>> - databases/lmdb
>> - databases/sqlite3
>>
>> link against pthread these days, but their pkg-config file does not list
>> -lpthread when queried via pkgconfig --libs <database>.
> I'd expect
>
>> Consequence: bogofilter itself is single-threaded and does not use
>> material from the POSIX threads library itself, so won't add -pthreads,
>> -lpthreads or similar.  It does use the respective pkg-config file of lmdb
>> or sqlite3 for --libs and --cflags, and then fails to link any of the
>> database-related programs constituting bogofilter, because neither
>>
>> pkg-config --libs lmdb
>>
>> nor
>>
>> pkg-config --libs sqlite3
>>
>> gives me -lpthreads on the output.  Excerpt from linker error:
>>
>>> ld: error: undefined symbol: pthread_mutexattr_init
>>>>>> referenced by sqlite3.c:29857
>>>>>> sqlite3.o:(pthreadMutexAlloc) in archive /usr/local/lib/libsqlite3.a
>>> $ pkg-config --libs sqlite3
>>> -L/usr/local/lib -lsqlite3
>> What I find confusing about this is that there was some effort to fix that
>> for sqlite3 - and I haven't built the sqlite3 from source but just used
>> "pkg_add sqlite3" on my OpenBSD 7.7 VM. (Which itself got updated through
>> several releases by way of sysupgrade followed by syspatch and pkg_add
>> -u):
>>
>> https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/databases/sqlite3/Makefile#rev1.134
> That was "libs.private" as used for static linking. I wouldn't normally
> expect pthread to be listed in "libs" if the .so has a NEEDED pointing
> at libpthread as ld.so would normally resolve that itself at runtime.

Hm. I did not intentionally...

>>> ld: error: undefined symbol: pthread_mutexattr_init
>>> referenced by sqlite3.c:29857
>>> sqlite3.o:(pthreadMutexAlloc) in archive /usr/local/lib/libsqlite3.a

switch to linking this statically, so need to find up what in the 
autotools macro set chose that over the .so file because that's involved 
in either lmdb- or sqlite3-based links.

The intention is of course to use shared libraries for databases where 
available so they can update independently for non-breaking bug fixes 
without relinking the apps that use either.

> Here you're linking the static library, so you need to tell pkg-config
> that's what you're doing:
>
> $ pkg-config --libs sqlite3
> -L/usr/local/lib -lsqlite3
>
> $ pkg-config --static --libs sqlite3
> -L/usr/local/lib -lsqlite3 -lz -lm -lpthread
>
> I don't think there's a problem with the sqlite port, but it looks like
> -lpthread is indeed missing from lmdb's libs.private.

Thanks to you and Jeremie for the quick action and Otto for his 2nd pair 
of eyeballs.

Best regards,
Matthias