Re: [PATCH] Can't build locks...

["Pier P. Fumagalli" <pi...@betaversion.org>]

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_SYSVSEM_SERIALIZE         0
#define APR_USE_FCNTL_SERIALIZE           1
#define APR_USE_PROC_PTHREAD_SERIALIZE    0
#define APR_USE_PTHREAD_SERIALIZE         0

#define APR_HAS_FLOCK_SERIALIZE           1
#define APR_HAS_SYSVSEM_SERIALIZE         1
#define APR_HAS_FCNTL_SERIALIZE           1
#define APR_HAS_PROC_PTHREAD_SERIALIZE    0

>> 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
afternoon...

    Pier

Re: [PATCH] Can't build locks...

[Chuck Murcko <ch...@topsail.org>]

On Sunday, July 1, 2001, at 06:46 AM, Pier P. Fumagalli wrote:

> 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...

Well, whoever said autoconf is incorrectly detecting was right:

/bin/sh /usr/local/src/httpd-2.0/srclib/apr/libtool --silent 
--mode=compile /usr/bin/cc -g -O2   -DHAVE_CONFIG_H -DDARWIN   
-I../../include -I../../include/arch -I../../include/arch/unix  -c 
crossproc.c && touch crossproc.lo
crossproc.c: In function `sysv_setup':
crossproc.c:67: invalid use of undefined type `struct sembuf'
crossproc.c:68: invalid use of undefined type `struct sembuf'
crossproc.c:69: invalid use of undefined type `struct sembuf'
crossproc.c:69: `SEM_UNDO' undeclared (first use in this function)
crossproc.c:69: (Each undeclared identifier is reported only once
crossproc.c:69: for each function it appears in.)
crossproc.c:70: invalid use of undefined type `struct sembuf'
crossproc.c:71: invalid use of undefined type `struct sembuf'
crossproc.c:72: invalid use of undefined type `struct sembuf'
crossproc.c: In function `sysv_cleanup':
crossproc.c:82: `IPC_RMID' undeclared (first use in this function)
crossproc.c: In function `sysv_create':
crossproc.c:91: `IPC_PRIVATE' undeclared (first use in this function)
crossproc.c:91: `IPC_CREAT' undeclared (first use in this function)
crossproc.c:98: `SETVAL' undeclared (first use in this function)
crossproc.c: At top level:
crossproc.c:62: storage size of `op_on' isn't known
crossproc.c:63: storage size of `op_off' isn't known
make[4]: *** [crossproc.lo] Error 1

Disabling SYSV semaphores lets the build continue. It breaks later in 
apr_sms_trivial.c, but that looks easy to fix.

Chuck Murcko
Topsail Group
http://www.topsail.org/