Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (asf.osuosl.org: local policy)
To: Jeff Trawick <trawick@gmail.com>
Cc: dev@apr.apache.org
Subject: Re: Reducing #ifdef burden on APR applications
References: <43071434.8070802@webthing.com>
	<20050820125919.GB14357@redhat.com> <43073611.1000309@webthing.com>
	<cc67648e050820072942749964@mail.gmail.com>
From: Philip Martin <philip@codematters.co.uk>
Date: Wed, 24 Aug 2005 18:10:09 +0100
In-Reply-To: <cc67648e050820072942749964@mail.gmail.com> (Jeff Trawick's
 message of "Sat, 20 Aug 2005 10:29:55 -0400")
Message-ID: <87vf1vjm6m.fsf@debian2.lan>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Jeff Trawick <trawick@gmail.com> writes:

> Solaris will link in APR_SUCCESS-style no-op pthread functions if your
> application isn't built  thread-capable.

Glibc on Linux does the same for things like pthread_mutex_lock:

$ cat z.c
#include <pthread.h>
int main()
{
  if (pthread_mutex_lock(NULL))
    return 1;
  return 0;
}
$ gcc z.c              # build without threads
$ ./a.out
$ echo $?
0
$ gcc -pthread z.c     # with threads
$ ./a.out
Segmentation fault

> If APR always provides such APIs and acts like they work, what is to
> signal to a threaded APR app that they are picking up a non-threaded
> libapr?

Glibc doesn't provide no-op functions for things like
pthread_mutex_create, those are only available when the full threading
library replaces all the no-op functions.

-- 
Philip Martin