Message #18 des archives de la Liste gnuports@2rosenthals.com

De: "Lewis G Rosenthal" <gnuports@2rosenthals.com> En-têtes complèts
Message brut
Sujet: Re: [GNU Ports] Building privoxy - need to specify PTHREAD_LIB - why?
Date: Tue, 1 Feb 2022 16:25:30 -0500
À: GNU Ports for eCS Mailing List <gnuports@2rosenthals.com>

On 02/01/22 11:18 am, Dave Yeo wrote:
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.

There's a lot of stuff still left over which refers to OS/2, which is why I didn't think anything had really been changed.

That said, is pthread so bad vs native threads? I'm still just getting started testing this build, so I can't really comment on performance, yet. I was just surprised that I can generally find all other libs for building things, but this seemed to need an explicit pointer with a full path.

--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA
Rosenthal & Rosenthal, LLC                www.2rosenthals.com
visit my IT blog                www.2rosenthals.net/wordpress
-------------------------------------------------------------


Abonner: Direct, Résumé, Index.
Désabonner
Écrire au gestionnaire de la liste