[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: build error on win32

From: Branko Čibej <brane_at_xbc.nu>
Date: 2002-05-29 22:16:57 CEST

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   <brane_at_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
Received on Sat Jun 1 14:23:39 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.