apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pier P. Fumagalli" <p...@betaversion.org>
Subject Re: [PATCH] Can't build locks...
Date Sun, 01 Jul 2001 10:46:59 GMT
Aaron Bannert at aaron@ebuilt.com wrote:

> On Sat, Jun 30, 2001 at 02:53:44AM +0100, Pier P. Fumagalli wrote:
>> On Darwin 1.3.7 I had an error building locks/unix/crossproc.c
> What was the error? Maybe autoconf is incorrectly detecting some
> headers or library functions on Darwin that aren't really there?

It was trying to compile the SYSV code but darwin doesn't have the sembuf
structure defined...

>>> From what it seems in the configure.in AutoConf source, the locking
>> mechanism is determined in lines around 950-980 and defines some
>> APR_USE_*_SERIALIZE, those are copied over to apr.h.in in lines 60-70, but
>> the onther following four (APR_HAS_*_SERIALIZE) are initialized randomly.
> Your evaluation seems correct to me. What do the various APR_USE_*_SERIALIZE
> and APR_HAS_*_SERIALIZE lines end up as in your apr.h file?

#define APR_USE_FLOCK_SERIALIZE           0
#define APR_USE_FCNTL_SERIALIZE           1

#define APR_HAS_FLOCK_SERIALIZE           1
#define APR_HAS_FCNTL_SERIALIZE           1

>> Crossproc.c uses the APR_HAS ones while configure sets the APR_USE group. I
>> replaced the APR_HAS with APR_USE and the whole thing went thru...
>> Am I missing something? :)
> The functions in crossproc.c don't actually define which lock
> implementation gets *used*, but intead is just a conditional compile
> for that functionality if you have it on your system. For that reason
> I believe crossproc.c is using APR_HAS_* correctly.
> The implementation is actually chosen at runtime, for example in
> locks/unix/locks.c's chose_method() function. OTOH, I think this part
> may be incorrect. I would expect the part that (at runtime) choses which
> implementation to use would be defined by autoconf's APR_USE_*_SERIALIZE
> symbols, but instead it is using APR_HAS_*.

So, configure is actually detecting the wrong kind of locking mechanism
supported by darwin (is that what you're saying, because coming from Java
land all those weirdnesses of cross-platform compatibility don't sound very
familiar :)

I'll dump log of what actually went wrong within the build later this


View raw message