# [Bug] Unrealiable threading support detection (on HP-UX)

1 messages from 2025-09-16 to 2025-09-16. Participants: Osipov, Michael (IN IT IN).
Thread: https://gitlist.dev/t/64154

## Osipov, Michael (IN IT IN), 2025-09-16 20:12

Subject: [Bug] Unrealiable threading support detection (on HP-UX)
Message-ID: <93cee8d0-0c1d-4329-ae93-7f900601995e@innomotics.com>
URL: https://gitlist.dev/e/93cee8d0-0c1d-4329-ae93-7f900601995e%40innomotics.com

```
Hi folks,

I have stumbled upon an issue on HP-UX where the detection of threading 
(pthreads) is incorrect or unreliable. There are actually two issues: 
incorrect display and incorrect detection.

Consider:
> root@deblndw001x:/var/tmp/ports/work/git-2.51.0
> # CPPFLAGS="$CPPFLAGS -D_XOPEN_SOURCE=600" $CONFIGURE --with-editor=vim --with-zlib=$PREFIX   --with-perl=/usr/bin/perl --with-iconv=$PREFIX --with-libpcre2=$PREFIX   --with-gitconfig=$SYSCONFDIR/gitconfig --with-gitattributes=$SYSCONFDIR/gitattributes --without-tcltk --with-lib=lib/hpux32
> configure: Setting lib to 'lib/hpux32'
> configure: Will try -pthread then -lpthread to enable POSIX Threads.
> ...
> checking for POSIX Threads with ''... yes
> configure: creating ./config.status
> config.status: creating config.mak.autogen
> config.status: executing config.mak.autogen commands

Looking at configure.ac the message "Will try..." is not correct because 
much more is tried:
> for opt in -mt -pthread -lpthread; do

So either the message needs to be extended *or* the values removed from 
the message to avoid updating both.

The output tells us that pthread support is in libc since no library is 
required. Let's try:
> # git clone https://github.com/freebsd/freebsd-src.git
> Cloning into 'freebsd-src'...
> error: cannot create async thread: Function is not available
> fatal: fetch-pack: unable to fork off sideband demultiplexer

Doesn't work. HP-UX requires either -lphtread or better -mt.

> # diff configure.ac.orig configure.ac
> --- configure.ac.orig   2025-09-16 18:05:44 +0200
> +++ configure.ac        2025-09-16 18:05:55 +0200
> @@ -1272,7 +1272,7 @@
>    # trigger a warning about an unused flag). Hence if we checked for
>    # "-mt" before "" we would end up picking it. But unfortunately this
>    # would then trigger compiler warnings on every single file we compile.
> -  for opt in "" -mt -pthread -lpthread; do
> +  for opt in -mt -pthread -lpthread; do
>       old_CFLAGS="$CFLAGS"
>       old_LIBS="$LIBS"
>       case "$opt" in

does the trick. But why did it apparently work during configuration?.. 
and here is now the bug:
> configure:8609: checking for POSIX Threads with ''
> configure:8639: /opt/aCC/bin/aCC -AC99 -AC99 -o conftest  +We901 -I/opt/ports/include -D_XOPEN_SOURCE=600 -L/opt/ports/lib/hpux32 conftest.c  -lintl >&5
> "conftest.c", line 45: warning #2111-D: statement is unreachable
>     return 0;
>     ^
> 
> configure:8639: $? = 0
> configure:8641: result: yes

$LIBS is passed and libs contain -lintl. GNU gettext nowaways (since 
0.23) links by default against libpthread, so it is a transitive 
dependency and goes unnoticed. The manpage for pthread says the following:
>       A multithreaded application must define the appropriate POSIX revision
>       level (199506) at compile time and link against the pthread library
>       with -lpthread.  For example:
> 
>            cc -D_POSIX_C_SOURCE=199506L -o myapp myapp.c -lpthread
> 
>       All program sources must also include the header file <pthread.h>.
> 
>       Note: If -lc is explicitly specified in the link line, then it must be
>       after the -lpthread.  Refer to pthread_stubs(5) for more details.

So, git and everything in libexec *must* be linked with -mt otherwise it 
will fail at runtime.

To sum up, we have two bugs:
* Incorrect display of the values to tried (./configure --help is 
incorrect as well)
* Incorrect detection during configuration

As a workaround I can pass "--enable-pthreads=-mt", but I'd rather 
either have no threading or correct threading by default, but not 
something broken at runtime.

Let me know what you think!

Michael

PS: FWIW, I have reported a similar issue for MIT Kerberos with GNU 
gettext and Cyrus SASL today: 
https://mailman.mit.edu/pipermail/kerberos/2025-September/023286.html

```