You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Branko Čibej <br...@xbc.nu> on 2003/09/29 02:55:34 UTC
Re: cvs commit: apr/memory/unix apr_pools.c
striker@apache.org wrote:
>striker 2003/09/27 16:51:46
>
> Modified: misc/unix start.c
> memory/unix apr_pools.c
> Log:
> * misc/unix/start.c
>
> (apr_initialize): Remove atomics initialization from this function. Due
> to circular dependency, doing it here is too late.
>
> * memory/unix/apr_pools.c
>
> (apr_pool_initialize): Add atomics initialization to the release and debug
> versions. This has to happen here, since pools rely on mutexes, which
> can be backed by atomics. Atomics initialization requires a pool.
>
>
[snip]
I can't believe we don't have a Win32 implementation of the atomics. So
right now, HEAD doesn't compile on Windows. :-(
Is the implementation in unix/ generic enough to work anywhere? If it
is, I'll temporarily add it to apr.dsp.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: cvs commit: apr/memory/unix apr_pools.c
Posted by Branko Čibej <br...@xbc.nu>.
Cliff Woolley wrote:
>On Mon, 29 Sep 2003, [UTF-8] Branko ?^Libej wrote:
>
>
>
>>>>Huh, not surprising. apr_atomic.h does _not_ define apr_atomic_init on
>>>>Win32, Netware, FreeBSD, Linux, MVS and djgpp; no wonder there are
>>>>dangling references to it in apr_pools.obj.
>>>>
>>>>
>>Uh -- I said HEAD, not the 0.9 branch.
>>
>>
>
>As a data point, the test builds I ran earlier today where I caught the
>missing #include "apr_atomic.h" in apr_pools.c were run on Linux. After
>including that, the warning about having no definition of
>apr_atomic_init() went away, so it must be getting _something_.
>
>
The linux build (probably) uses atomic/unix/apr_atomic.c. The Windows
build doesn't. Since I've been building the static library, this missing
reference isn't noticed until the library is actually used in a link.
Anyway, I'll wait until the author of the new atomics API can give me a
hint about the genericity of unix/apr_atomic.c. Looks O.K. to me, but I
can live on the branch for now and 4 a.m. isn't exactly the best time to
start experimenting.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: cvs commit: apr/memory/unix apr_pools.c
Posted by Cliff Woolley <jw...@virginia.edu>.
On Mon, 29 Sep 2003, [UTF-8] Branko �^Libej wrote:
> >>Huh, not surprising. apr_atomic.h does _not_ define apr_atomic_init on
> >>Win32, Netware, FreeBSD, Linux, MVS and djgpp; no wonder there are
> >>dangling references to it in apr_pools.obj.
>
> Uh -- I said HEAD, not the 0.9 branch.
As a data point, the test builds I ran earlier today where I caught the
missing #include "apr_atomic.h" in apr_pools.c were run on Linux. After
including that, the warning about having no definition of
apr_atomic_init() went away, so it must be getting _something_.
--Cliff
RE: cvs commit: apr/memory/unix apr_pools.c
Posted by Sander Striker <st...@apache.org>.
> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: Monday, September 29, 2003 3:31 AM
[...]
> >Looks like a definition to me... Why doesn't this work?
> >
> >
> Uh -- I said HEAD, not the 0.9 branch.
Doh.
>>> Since there's a whole bunch of atomics that do _not_ have a
>>> Win32-specific implementation in apr_atomic.h, my guess is that we need
>>> to build apr_atomic.c on Windows.
Worth a shot. It looks generic enough.
Sander
Re: cvs commit: apr/memory/unix apr_pools.c
Posted by Branko Čibej <br...@xbc.nu>.
Sander Striker wrote:
>>From: Branko Cibej [mailto:brane@xbc.nu]
>>Sent: Monday, September 29, 2003 3:22 AM
>>
>>
>
>
>
>>Branko Čibej wrote:
>>
>>
>>
>>>Also, I'm being double stupid because it's not APR that doesn't compile,
>>>it's APR-iconv. Ho hum. Now how can that happen?
>>>
>>>/me grumbles and looks
>>>
>>>
>>>
>>>
>>Huh, not surprising. apr_atomic.h does _not_ define apr_atomic_init on
>>Win32, Netware, FreeBSD, Linux, MVS and djgpp; no wonder there are
>>dangling references to it in apr_pools.obj.
>>
>>
>
>Huh?
>
>#if defined(WIN32)
>
>#define apr_atomic_t LONG
>
>#define apr_atomic_add(mem, val) InterlockedExchangeAdd(mem,val)
>#define apr_atomic_dec(mem) InterlockedDecrement(mem)
>#define apr_atomic_inc(mem) InterlockedIncrement(mem)
>#define apr_atomic_set(mem, val) InterlockedExchange(mem, val)
>#define apr_atomic_read(mem) (*mem)
>#define apr_atomic_cas(mem,with,cmp) InterlockedCompareExchange(mem,with,cmp)
>#define apr_atomic_init(pool) APR_SUCCESS
>#define apr_atomic_casptr(mem,with,cmp) InterlockedCompareExchangePointer(mem,with,cmp)
>
>Looks like a definition to me... Why doesn't this work?
>
>
Uh -- I said HEAD, not the 0.9 branch.
>
>
>
>>Since there's a whole bunch of atomics that do _not_ have a
>>Win32-specific implementation in apr_atomic.h, my guess is that we need
>>to build apr_atomic.c on Windows.
>>
>>
>
>Isn't the above the full atomics API?
>
>
>Sander 'getting confused now'
>
>
>
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
RE: cvs commit: apr/memory/unix apr_pools.c
Posted by Sander Striker <st...@apache.org>.
> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: Monday, September 29, 2003 3:22 AM
> Branko Čibej wrote:
>
> >Also, I'm being double stupid because it's not APR that doesn't compile,
> >it's APR-iconv. Ho hum. Now how can that happen?
> >
> >/me grumbles and looks
> >
> >
>
> Huh, not surprising. apr_atomic.h does _not_ define apr_atomic_init on
> Win32, Netware, FreeBSD, Linux, MVS and djgpp; no wonder there are
> dangling references to it in apr_pools.obj.
Huh?
#if defined(WIN32)
#define apr_atomic_t LONG
#define apr_atomic_add(mem, val) InterlockedExchangeAdd(mem,val)
#define apr_atomic_dec(mem) InterlockedDecrement(mem)
#define apr_atomic_inc(mem) InterlockedIncrement(mem)
#define apr_atomic_set(mem, val) InterlockedExchange(mem, val)
#define apr_atomic_read(mem) (*mem)
#define apr_atomic_cas(mem,with,cmp) InterlockedCompareExchange(mem,with,cmp)
#define apr_atomic_init(pool) APR_SUCCESS
#define apr_atomic_casptr(mem,with,cmp) InterlockedCompareExchangePointer(mem,with,cmp)
Looks like a definition to me... Why doesn't this work?
> Since there's a whole bunch of atomics that do _not_ have a
> Win32-specific implementation in apr_atomic.h, my guess is that we need
> to build apr_atomic.c on Windows.
Isn't the above the full atomics API?
Sander 'getting confused now'
Re: cvs commit: apr/memory/unix apr_pools.c
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
>Also, I'm being double stupid because it's not APR that doesn't compile,
>it's APR-iconv. Ho hum. Now how can that happen?
>
>/me grumbles and looks
>
>
Huh, not surprising. apr_atomic.h does _not_ define apr_atomic_init on
Win32, Netware, FreeBSD, Linux, MVS and djgpp; no wonder there are
dangling references to it in apr_pools.obj.
Since there's a whole bunch of atomics that do _not_ have a
Win32-specific implementation in apr_atomic.h, my guess is that we need
to build apr_atomic.c on Windows.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: cvs commit: apr/memory/unix apr_pools.c
Posted by Branko Čibej <br...@xbc.nu>.
Sander Striker wrote:
>>From: Branko Cibej [mailto:brane@xbc.nu]
>>Sent: Monday, September 29, 2003 2:56 AM
>>
>>
>
>
>
>>[snip]
>>
>>I can't believe we don't have a Win32 implementation of the atomics. So
>>right now, HEAD doesn't compile on Windows. :-(
>>
>>
>
>Sure we do. Take a look at include/apr_atomic.h
>
>
Hm, right, ouch, sorry, silly me.
>Is the implementation in unix/ generic enough to work anywhere? If it
>is, I'll temporarily add it to apr.dsp.
>
>
>
>No need. The include file redefines about everything AFAICT.
>
>
Also, I'm being double stupid because it's not APR that doesn't compile,
it's APR-iconv. Ho hum. Now how can that happen?
/me grumbles and looks
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
RE: cvs commit: apr/memory/unix apr_pools.c
Posted by Sander Striker <st...@apache.org>.
> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: Monday, September 29, 2003 2:56 AM
> [snip]
>
> I can't believe we don't have a Win32 implementation of the atomics. So
> right now, HEAD doesn't compile on Windows. :-(
Sure we do. Take a look at include/apr_atomic.h
> Is the implementation in unix/ generic enough to work anywhere? If it
> is, I'll temporarily add it to apr.dsp.
No need. The include file redefines about everything AFAICT.
Sander