You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "Pier P. Fumagalli" <pi...@betaversion.org> on 2001/06/30 03:53:44 UTC
[PATCH] Can't build locks...
On Darwin 1.3.7 I had an error building locks/unix/crossproc.c
>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.
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? :)
Pier
--- crossproc.c.old Sat Jun 30 02:33:16 2001
+++ crossproc.c Sat Jun 30 02:51:23 2001
@@ -59,7 +59,7 @@
-#if APR_HAS_SYSVSEM_SERIALIZE
+#if APR_USE_SYSVSEM_SERIALIZE
static struct sembuf op_on;
static struct sembuf op_off;
@@ -162,7 +162,7 @@
#endif /* SysV sem implementation */
-#if APR_HAS_PROC_PTHREAD_SERIALIZE
+#if APR_USE_PROC_PTHREAD_SERIALIZE
static void proc_pthread_setup(void)
{
@@ -296,7 +296,7 @@
#endif
-#if APR_HAS_FCNTL_SERIALIZE
+#if APR_USE_FCNTL_SERIALIZE
static struct flock lock_it;
static struct flock unlock_it;
@@ -405,7 +405,7 @@
#endif /* fcntl implementation */
-#if APR_HAS_FLOCK_SERIALIZE
+#if APR_USE_FLOCK_SERIALIZE
static apr_status_t flock_release(apr_lock_t *);
@@ -515,16 +515,16 @@
void apr_unix_setup_lock(void)
{
-#if APR_HAS_SYSVSEM_SERIALIZE
+#if APR_USE_SYSVSEM_SERIALIZE
sysv_setup();
#endif
-#if APR_HAS_PROC_PTHREAD_SERIALIZE
+#if APR_USE_PROC_PTHREAD_SERIALIZE
proc_pthread_setup();
#endif
-#if APR_HAS_FCNTL_SERIALIZE
+#if APR_USE_FCNTL_SERIALIZE
fcntl_setup();
#endif
-#if APR_HAS_FLOCK_SERIALIZE
+#if APR_USE_FLOCK_SERIALIZE
flock_setup();
#endif
}
Re: [PATCH] Can't build locks...
Posted by Justin Erenkrantz <je...@ebuilt.com>.
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
>
> >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.
>
> 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? :)
FWIW, I re-ran buildconf and configure with the current CVS and the
APR_HAS_*_SERIALIZE macros magically appeared in apr.h. See if that
works. I guess I hadn't ran buildconf/configure in a while.
As Aaron said, APR_HAS_*_SERIALIZE and APR_USE_*_SERIALIZE are different
beasts. (I know that he was looking at that exact code today.)
-- justin
Re: [PATCH] Can't build locks...
Posted by 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/
Re: [PATCH] Can't build locks...
Posted by "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...
Posted by Aaron Bannert <aa...@ebuilt.com>.
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?
> >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?
> 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_*.
-aaron
Re: [PATCH] Can't build locks...
Posted by Justin Erenkrantz <je...@ebuilt.com>.
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
>
> >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.
>
> 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? :)
Not from what I can tell. Over here, the APR_HAS_*_SERIALIZE lines
never actually make it into apr.h (even though they are in apr.h.in).
GNU m4 seems to strip the lines where the values are undefined.
This patch seems to be legitimate. I might commit this tomorrow if
no one beats me to it. I can't see how the current code even
works. =) -- justin