On 02/01/22 05:24 AM, Lewis G Rosenthal wrote:

Hi, Dave...

On 02/01/22 12:52 am, Dave Yeo wrote:

On 01/31/22 09:12 PM, Steven Levine wrote:

In <list-3012143@2rosenthals.com>, on 02/01/22
   at 03:07 PM, "Paul Smedley" <gnuports@2rosenthals.com> said:

Hi guys,

Im assuming that on some platforms, adding -pthreads to the gcc command
line causes -lpthreads to be added by gcc automatically.

See:

https://stackoverflow.com/questions/2127797/significance-of-pthread-flag-when-compiling It would appear that even though our built-in specs understand
pthread, we
don't understand it quite as fully as gcc on other platforms.

I see some configure scripts doing 3 or 4 pthread checks before
deciding on the one to use for us.
BTW, doesn't privoxy have native OS/2 threads support or was it removed?
Dave

Hmmm... Using the configure option:

--disable-pthread

configure gives me the following ominous message:

checking pthread.h presence... yes
checking for pthread.h... yes
configure: WARNING: pthreads seem to be available but you are using
--disable-pthread.
configure: WARNING: This is almost always a mistake and can render
Privoxy unacceptable slow.
configure: WARNING: Also various Privoxy features only work when using
threads and won't even compile
 without them.

Compiling, I get (as a start):

gcc.exe -c -pipe -g -O2 -Zexe -DNDEBUG    -Wall  cgisimple.c -o cgisimple.o
cgisimple.c: In function 'cgi_show_client_tags':
cgisimple.c:376:10: warning: implicit declaration of function
'privoxy_mutex_lock' \
 [-Wimplicit-function-declaration]
  376 |          privoxy_mutex_lock(&client_tags_mutex);

I'm not sure what else might need to be done to use native threads vs
POSIX. I'll re-read configure as time permits.

Thanks for the suggestion.

PS - I'll bet this just builds fine with EMX. LOL

Actually, it used to build fine with VACPP and was the supported way. OK, looking, Version 3.0.29 removed OS/2 support, from the changelog,

  - Removed OS/2 support. We haven't provided OS/2 packages in years,
    it complicated the code and it depended on a fallback snprintf()
    implementation which is GPLv2 only.
  - Remove the fallback snprintf() implementation
    Now that OS/2 support is gone we no longer need it.

Could probably find the commit that removed it and restore or at least see if the warpin script was in the tree.