You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Patrik Husfloen <pa...@student.liu.se> on 2002/05/29 17:17:16 UTC
build error on win32
I'm getting an error building svn on win32 using VC6.
I've got the latest version of apr, apr-util and svn (just got them from
cvs/svn)
if anyone can confirm this it would be great.
libsvn_subr.lib(svn_error.obj) : error LNK2001: unresolved external
symbol _apr_allocator_set_mutex@8
Release/svn.exe : fatal error LNK1120: 1 unresolved externals
/patrik husfloen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: build error on win32
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 04:09 PM 5/29/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>Branko Äibej wrote:
>Ho hum. I think there's also a bug in apr_pool_initialize. The sequence
>there is
>
> apr_allocator_create(&global_allocator)
> apr_pool_create_ex(&global_pool, ...., global_allocator)
> apr_thread_mutex_create(&mutex, ...)
> apr_allocator_set_mutex(global_allocator, mutex)
>
>But apr_pool_create_ex will call apr_allocator_alloc on the provided
>allocator, and that will call apr_thread_mutex_lock ... on an
>uninitialized mutex, no less.
>
>At least, I /think/ that's the problem. Definitely all SVN tests on
>Windows are crashing in the mutex lock in apr_allocator_alloc, and that
>mutex definitely hasn't been initialized.
Well, if it helps, I've significantly overhauled the code for Win32 to
allow 'try'
semantics on Win32, which returned ENOTIMPL before. Possible this is
part of your headache.
We will now have a mutex object on 9x, a critical section on NT, unless we
explicitly request an APR_THREAD_MUTEX_UNNESTED flag to _create().
In that case, I've written an event-based model that's guaranteed to deadlock
on the same thread... maybe these issues are part of the problem you observed?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: build error on win32
Posted by Sander Striker <st...@apache.org>.
Thanks for all the reactions.
My head is clearing up and I will commit the appropiate fixes ;)
Sander
RE: build error on win32
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:14 PM 5/29/2002, Sander wrote:
> > While we're at it, apr_allocator_alloc and apr_allocator_free are also
> > defined inline. I don't think that makes much sense, given the size of
> > those functions.
>
>Hmm, so windows isn't smart enough to do both inlining and exporting?
>I'd like the stuff inlined in apr_pools.c (for performance), but need
>them exported for other callers than apr_pools.c.
Ummm... no. Nor do I believe that the inline c language spec calls for it.
>Suggestions?
Yes. First, drop the use of external inlines.
Second, map out a strategy that will work across inline and non-inlining
compilers. Map out a strategy for building said fn's as exports as well
as inlines.
The typical win32 model on this stuff is;
foo.h
#ifndef INLINE
void EXPORT somefn(void);
#else
void INLINE somefn(void)
{
return;
}
Now #define INLINE inline before including foo.h and you have the
inlined functions.
If you write a simple module that is linked in;
foo.c
/* Toggle inline to include function bodies, but use
* the EXPORT keywords instead to compile as fn's.
*/
#define INLINE EXPORT
#include "foo.h"
You now have both flavors.
Question of the hour is, WTF? It's inline or it's not. Why add the additional
complexity? And remember that inlining will clobber us on binary compatibility
on otherwise perfectly safe changes to the internal guts of opaque structures.
Bill
Re: build error on win32
Posted by Branko Čibej <br...@xbc.nu>.
Sander Striker wrote:
>>From: Branko Cibej [mailto:brane@xbc.nu]
>>Sent: 29 May 2002 21:58
>>
>>
>
>
>
>>Branko Čibej wrote:
>>
>>
>>
>>>Patrik Husfloen wrote:
>>>
>>>
>>>
>>>>I'm getting an error building svn on win32 using VC6.
>>>>I've got the latest version of apr, apr-util and svn (just got them
>>>>from cvs/svn)
>>>>if anyone can confirm this it would be great.
>>>>
>>>>libsvn_subr.lib(svn_error.obj) : error LNK2001: unresolved external
>>>>symbol _apr_allocator_set_mutex@8
>>>>Release/svn.exe : fatal error LNK1120: 1 unresolved externals
>>>>
>>>>
>>>This looks like a bug in APR. Both apr_allocator_set_mutex and
>>>apr_allocator_get_mutex are defined with APR_INLINE in apr_pools.c,
>>>which is clearly major bogosity. Either that APR_INLINE shoudl go
>>>away, or the inline definitions should move to a header (probably
>>>apr_allocator.h, where they're declared now), and made static.
>>>
>>>Sander, looks like you're the culprit here (the rev 1.159 commit).
>>>Comments?
>>>
>>>
>>While we're at it, apr_allocator_alloc and apr_allocator_free are also
>>defined inline. I don't think that makes much sense, given the size of
>>those functions.
>>
>>
>
>Hmm, so windows isn't smart enough to do both inlining and exporting?
>I'd like the stuff inlined in apr_pools.c (for performance), but need
>them exported for other callers than apr_pools.c.
>
That (extern inline) a C99 feature, which most compilers don't
understand. GCC had something similar before the new standard.
>Suggestions?
>
I'm pretty sure _alloc and _free don't have to be inlined (measurements
rule here, of course).
Are _set_mutex and _get_mutex really that sensitive? If yes, they're so
trivial that you can easily inline them by hand inside apr_pools.c.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: build error on win32
Posted by Branko Čibej <br...@xbc.nu>.
Sander Striker wrote:
>>From: Branko Cibej [mailto:brane@xbc.nu]
>>Sent: 29 May 2002 21:58
>>
>>
>
>
>
>>Branko Čibej wrote:
>>
>>
>>
>>>Patrik Husfloen wrote:
>>>
>>>
>>>
>>>>I'm getting an error building svn on win32 using VC6.
>>>>I've got the latest version of apr, apr-util and svn (just got them
>>>>from cvs/svn)
>>>>if anyone can confirm this it would be great.
>>>>
>>>>libsvn_subr.lib(svn_error.obj) : error LNK2001: unresolved external
>>>>symbol _apr_allocator_set_mutex@8
>>>>Release/svn.exe : fatal error LNK1120: 1 unresolved externals
>>>>
>>>>
>>>This looks like a bug in APR. Both apr_allocator_set_mutex and
>>>apr_allocator_get_mutex are defined with APR_INLINE in apr_pools.c,
>>>which is clearly major bogosity. Either that APR_INLINE shoudl go
>>>away, or the inline definitions should move to a header (probably
>>>apr_allocator.h, where they're declared now), and made static.
>>>
>>>Sander, looks like you're the culprit here (the rev 1.159 commit).
>>>Comments?
>>>
>>>
>>While we're at it, apr_allocator_alloc and apr_allocator_free are also
>>defined inline. I don't think that makes much sense, given the size of
>>those functions.
>>
>>
>
>Hmm, so windows isn't smart enough to do both inlining and exporting?
>I'd like the stuff inlined in apr_pools.c (for performance), but need
>them exported for other callers than apr_pools.c.
>
That (extern inline) a C99 feature, which most compilers don't
understand. GCC had something similar before the new standard.
>Suggestions?
>
I'm pretty sure _alloc and _free don't have to be inlined (measurements
rule here, of course).
Are _set_mutex and _get_mutex really that sensitive? If yes, they're so
trivial that you can easily inline them by hand inside apr_pools.c.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: build error on win32
Posted by Cliff Woolley <jw...@virginia.edu>.
On Wed, 29 May 2002, Sander Striker wrote:
> > While we're at it, apr_allocator_alloc and apr_allocator_free are also
> > defined inline. I don't think that makes much sense, given the size of
> > those functions.
>
> Hmm, so windows isn't smart enough to do both inlining and exporting?
> I'd like the stuff inlined in apr_pools.c (for performance), but need
> them exported for other callers than apr_pools.c.
>
> Suggestions?
Do the actual work in an APR_INLINE static function and have
apr_allocator_set/get_mutex be exported wrapper functions?
PS: The names should be apr_allocator_mutex_set/get and not
apr_allocator_set/get_mutex for consistency with APR's naming convention.
--Cliff
RE: build error on win32
Posted by Cliff Woolley <jw...@virginia.edu>.
On Wed, 29 May 2002, Sander Striker wrote:
> > While we're at it, apr_allocator_alloc and apr_allocator_free are also
> > defined inline. I don't think that makes much sense, given the size of
> > those functions.
>
> Hmm, so windows isn't smart enough to do both inlining and exporting?
> I'd like the stuff inlined in apr_pools.c (for performance), but need
> them exported for other callers than apr_pools.c.
>
> Suggestions?
Do the actual work in an APR_INLINE static function and have
apr_allocator_set/get_mutex be exported wrapper functions?
PS: The names should be apr_allocator_mutex_set/get and not
apr_allocator_set/get_mutex for consistency with APR's naming convention.
--Cliff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: build error on win32
Posted by Sander Striker <st...@apache.org>.
> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: 29 May 2002 21:58
> Branko Čibej wrote:
>
>> Patrik Husfloen wrote:
>>
>>> I'm getting an error building svn on win32 using VC6.
>>> I've got the latest version of apr, apr-util and svn (just got them
>>> from cvs/svn)
>>> if anyone can confirm this it would be great.
>>>
>>> libsvn_subr.lib(svn_error.obj) : error LNK2001: unresolved external
>>> symbol _apr_allocator_set_mutex@8
>>> Release/svn.exe : fatal error LNK1120: 1 unresolved externals
>>
>>
>> This looks like a bug in APR. Both apr_allocator_set_mutex and
>> apr_allocator_get_mutex are defined with APR_INLINE in apr_pools.c,
>> which is clearly major bogosity. Either that APR_INLINE shoudl go
>> away, or the inline definitions should move to a header (probably
>> apr_allocator.h, where they're declared now), and made static.
>>
>> Sander, looks like you're the culprit here (the rev 1.159 commit).
>> Comments?
>
> While we're at it, apr_allocator_alloc and apr_allocator_free are also
> defined inline. I don't think that makes much sense, given the size of
> those functions.
Hmm, so windows isn't smart enough to do both inlining and exporting?
I'd like the stuff inlined in apr_pools.c (for performance), but need
them exported for other callers than apr_pools.c.
Suggestions?
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: build error on win32
Posted by Sander Striker <st...@apache.org>.
> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: 29 May 2002 21:58
> Branko Čibej wrote:
>
>> Patrik Husfloen wrote:
>>
>>> I'm getting an error building svn on win32 using VC6.
>>> I've got the latest version of apr, apr-util and svn (just got them
>>> from cvs/svn)
>>> if anyone can confirm this it would be great.
>>>
>>> libsvn_subr.lib(svn_error.obj) : error LNK2001: unresolved external
>>> symbol _apr_allocator_set_mutex@8
>>> Release/svn.exe : fatal error LNK1120: 1 unresolved externals
>>
>>
>> This looks like a bug in APR. Both apr_allocator_set_mutex and
>> apr_allocator_get_mutex are defined with APR_INLINE in apr_pools.c,
>> which is clearly major bogosity. Either that APR_INLINE shoudl go
>> away, or the inline definitions should move to a header (probably
>> apr_allocator.h, where they're declared now), and made static.
>>
>> Sander, looks like you're the culprit here (the rev 1.159 commit).
>> Comments?
>
> While we're at it, apr_allocator_alloc and apr_allocator_free are also
> defined inline. I don't think that makes much sense, given the size of
> those functions.
Hmm, so windows isn't smart enough to do both inlining and exporting?
I'd like the stuff inlined in apr_pools.c (for performance), but need
them exported for other callers than apr_pools.c.
Suggestions?
Sander
Re: build error on win32
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
> Patrik Husfloen wrote:
>
>> I'm getting an error building svn on win32 using VC6.
>> I've got the latest version of apr, apr-util and svn (just got them
>> from cvs/svn)
>> if anyone can confirm this it would be great.
>>
>> libsvn_subr.lib(svn_error.obj) : error LNK2001: unresolved external
>> symbol _apr_allocator_set_mutex@8
>> Release/svn.exe : fatal error LNK1120: 1 unresolved externals
>
>
> This looks like a bug in APR. Both apr_allocator_set_mutex and
> apr_allocator_get_mutex are defined with APR_INLINE in apr_pools.c,
> which is clearly major bogosity. Either that APR_INLINE shoudl go
> away, or the inline definitions should move to a header (probably
> apr_allocator.h, where they're declared now), and made static.
>
> Sander, looks like you're the culprit here (the rev 1.159 commit).
> Comments?
>
While we're at it, apr_allocator_alloc and apr_allocator_free are also
defined inline. I don't think that makes much sense, given the size of
those functions.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
RE: build error on win32
Posted by Sander Striker <st...@apache.org>.
I'm on it.
Expect fixes tonight.
Sander
> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: 29 May 2002 23:10
> Ho hum. I think there's also a bug in apr_pool_initialize. The sequence
> there is
>
> apr_allocator_create(&global_allocator)
> apr_pool_create_ex(&global_pool, ...., global_allocator)
> apr_thread_mutex_create(&mutex, ...)
> apr_allocator_set_mutex(global_allocator, mutex)
>
> But apr_pool_create_ex will call apr_allocator_alloc on the provided
> allocator, and that will call apr_thread_mutex_lock ... on an
> uninitialized mutex, no less.
>
> At least, I /think/ that's the problem. Definitely all SVN tests on
> Windows are crashing in the mutex lock in apr_allocator_alloc, and that
> mutex definitely hasn't been initialized.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: build error on win32
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 04:09 PM 5/29/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>Branko Äibej wrote:
>Ho hum. I think there's also a bug in apr_pool_initialize. The sequence
>there is
>
> apr_allocator_create(&global_allocator)
> apr_pool_create_ex(&global_pool, ...., global_allocator)
> apr_thread_mutex_create(&mutex, ...)
> apr_allocator_set_mutex(global_allocator, mutex)
>
>But apr_pool_create_ex will call apr_allocator_alloc on the provided
>allocator, and that will call apr_thread_mutex_lock ... on an
>uninitialized mutex, no less.
>
>At least, I /think/ that's the problem. Definitely all SVN tests on
>Windows are crashing in the mutex lock in apr_allocator_alloc, and that
>mutex definitely hasn't been initialized.
Well, if it helps, I've significantly overhauled the code for Win32 to
allow 'try'
semantics on Win32, which returned ENOTIMPL before. Possible this is
part of your headache.
We will now have a mutex object on 9x, a critical section on NT, unless we
explicitly request an APR_THREAD_MUTEX_UNNESTED flag to _create().
In that case, I've written an event-based model that's guaranteed to deadlock
on the same thread... maybe these issues are part of the problem you observed?
RE: build error on win32
Posted by Sander Striker <st...@apache.org>.
I'm on it.
Expect fixes tonight.
Sander
> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: 29 May 2002 23:10
> Ho hum. I think there's also a bug in apr_pool_initialize. The sequence
> there is
>
> apr_allocator_create(&global_allocator)
> apr_pool_create_ex(&global_pool, ...., global_allocator)
> apr_thread_mutex_create(&mutex, ...)
> apr_allocator_set_mutex(global_allocator, mutex)
>
> But apr_pool_create_ex will call apr_allocator_alloc on the provided
> allocator, and that will call apr_thread_mutex_lock ... on an
> uninitialized mutex, no less.
>
> At least, I /think/ that's the problem. Definitely all SVN tests on
> Windows are crashing in the mutex lock in apr_allocator_alloc, and that
> mutex definitely hasn't been initialized.
Re: build error on win32
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
> Patrik Husfloen wrote:
>
>> I'm getting an error building svn on win32 using VC6.
>> I've got the latest version of apr, apr-util and svn (just got them
>> from cvs/svn)
>> if anyone can confirm this it would be great.
>>
>> libsvn_subr.lib(svn_error.obj) : error LNK2001: unresolved external
>> symbol _apr_allocator_set_mutex@8
>> Release/svn.exe : fatal error LNK1120: 1 unresolved externals
>
>
> This looks like a bug in APR. Both apr_allocator_set_mutex and
> apr_allocator_get_mutex are defined with APR_INLINE in apr_pools.c,
> which is clearly major bogosity. Either that APR_INLINE shoudl go
> away, or the inline definitions should move to a header (probably
> apr_allocator.h, where they're declared now), and made static.
>
> Sander, looks like you're the culprit here (the rev 1.159 commit).
> Comments?
>
Ho hum. I think there's also a bug in apr_pool_initialize. The sequence
there is
apr_allocator_create(&global_allocator)
apr_pool_create_ex(&global_pool, ...., global_allocator)
apr_thread_mutex_create(&mutex, ...)
apr_allocator_set_mutex(global_allocator, mutex)
But apr_pool_create_ex will call apr_allocator_alloc on the provided
allocator, and that will call apr_thread_mutex_lock ... on an
uninitialized mutex, no less.
At least, I /think/ that's the problem. Definitely all SVN tests on
Windows are crashing in the mutex lock in apr_allocator_alloc, and that
mutex definitely hasn't been initialized.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: build error on win32
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
> Patrik Husfloen wrote:
>
>> I'm getting an error building svn on win32 using VC6.
>> I've got the latest version of apr, apr-util and svn (just got them
>> from cvs/svn)
>> if anyone can confirm this it would be great.
>>
>> libsvn_subr.lib(svn_error.obj) : error LNK2001: unresolved external
>> symbol _apr_allocator_set_mutex@8
>> Release/svn.exe : fatal error LNK1120: 1 unresolved externals
>
>
> This looks like a bug in APR. Both apr_allocator_set_mutex and
> apr_allocator_get_mutex are defined with APR_INLINE in apr_pools.c,
> which is clearly major bogosity. Either that APR_INLINE shoudl go
> away, or the inline definitions should move to a header (probably
> apr_allocator.h, where they're declared now), and made static.
>
> Sander, looks like you're the culprit here (the rev 1.159 commit).
> Comments?
>
While we're at it, apr_allocator_alloc and apr_allocator_free are also
defined inline. I don't think that makes much sense, given the size of
those functions.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: build error on win32
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
> Patrik Husfloen wrote:
>
>> I'm getting an error building svn on win32 using VC6.
>> I've got the latest version of apr, apr-util and svn (just got them
>> from cvs/svn)
>> if anyone can confirm this it would be great.
>>
>> libsvn_subr.lib(svn_error.obj) : error LNK2001: unresolved external
>> symbol _apr_allocator_set_mutex@8
>> Release/svn.exe : fatal error LNK1120: 1 unresolved externals
>
>
> This looks like a bug in APR. Both apr_allocator_set_mutex and
> apr_allocator_get_mutex are defined with APR_INLINE in apr_pools.c,
> which is clearly major bogosity. Either that APR_INLINE shoudl go
> away, or the inline definitions should move to a header (probably
> apr_allocator.h, where they're declared now), and made static.
>
> Sander, looks like you're the culprit here (the rev 1.159 commit).
> Comments?
>
Ho hum. I think there's also a bug in apr_pool_initialize. The sequence
there is
apr_allocator_create(&global_allocator)
apr_pool_create_ex(&global_pool, ...., global_allocator)
apr_thread_mutex_create(&mutex, ...)
apr_allocator_set_mutex(global_allocator, mutex)
But apr_pool_create_ex will call apr_allocator_alloc on the provided
allocator, and that will call apr_thread_mutex_lock ... on an
uninitialized mutex, no less.
At least, I /think/ that's the problem. Definitely all SVN tests on
Windows are crashing in the mutex lock in apr_allocator_alloc, and that
mutex definitely hasn't been initialized.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: build error on win32
Posted by Branko Čibej <br...@xbc.nu>.
Patrik Husfloen wrote:
> I'm getting an error building svn on win32 using VC6.
> I've got the latest version of apr, apr-util and svn (just got them
> from cvs/svn)
> if anyone can confirm this it would be great.
>
> libsvn_subr.lib(svn_error.obj) : error LNK2001: unresolved external
> symbol _apr_allocator_set_mutex@8
> Release/svn.exe : fatal error LNK1120: 1 unresolved externals
This looks like a bug in APR. Both apr_allocator_set_mutex and
apr_allocator_get_mutex are defined with APR_INLINE in apr_pools.c,
which is clearly major bogosity. Either that APR_INLINE shoudl go away,
or the inline definitions should move to a header (probably
apr_allocator.h, where they're declared now), and made static.
Sander, looks like you're the culprit here (the rev 1.159 commit). Comments?
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: build error on win32
Posted by Branko Čibej <br...@xbc.nu>.
Patrik Husfloen wrote:
> I'm getting an error building svn on win32 using VC6.
> I've got the latest version of apr, apr-util and svn (just got them
> from cvs/svn)
> if anyone can confirm this it would be great.
>
> libsvn_subr.lib(svn_error.obj) : error LNK2001: unresolved external
> symbol _apr_allocator_set_mutex@8
> Release/svn.exe : fatal error LNK1120: 1 unresolved externals
This looks like a bug in APR. Both apr_allocator_set_mutex and
apr_allocator_get_mutex are defined with APR_INLINE in apr_pools.c,
which is clearly major bogosity. Either that APR_INLINE shoudl go away,
or the inline definitions should move to a header (probably
apr_allocator.h, where they're declared now), and made static.
Sander, looks like you're the culprit here (the rev 1.159 commit). Comments?
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/