apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: Build of libapritil-1.lib failed on Windows using VS2008
Date Thu, 26 Jul 2012 22:26:05 GMT
On 7/18/2012 5:40 AM, Jeff Trawick wrote:
> On Mon, Jul 16, 2012 at 1:27 PM, Alona Rossen <arossen@opentext.com> wrote:
>>
>>
>> Hello,
>>
>>
>>
>> Build of libapritil-1.lib failed on Windows using VS2008:
>>
>>
>>
>> 1>Linking...
>>
>> 1>   Creating library Debug\libaprutil-1.lib and object
>> Debug\libaprutil-1.exp
>>
>> 1>apr_dbd.obj : error LNK2001: unresolved external symbol
>> __imp__apr_pool_cleanup_kill@12
>>
>> 1>apr_reslist.obj : error LNK2019: unresolved external symbol
>> __imp__apr_pool_cleanup_kill@12 referenced in function _reslist_cleanup
> 
> I don't have much experience with debugging problems building apr*
> with Visual Studio, but I see that all these unresolved external
> symbols are from libapr.
> 
> Please explain the steps you followed to build apr and apr-util, and
> hopefully someone will have an idea of what was missed.

There are two modes of compiling and linking against apr.

In the first, you MUST -D'efine APR_STATIC (APU_STATIC) upon compile and
then link to apr-1.lib (aprutil-1.lib).  This frees you from shipping
libapr-1.dll (and libaprutil-1.dll) but means the functions are present
in each compiled binary you create, you must not reexport them, and some
thread related init/destructor logic isn't present.

In the second, you MUST NOT add APR_/APU_ defines for the model, importing
the dynamic library is the default behavior of the header files.  You must
then link to libapr-1.lib / libaprutil-1.lib which are the .dll export
bindings you need to run against the .dll files from apr/apu.

You appear to be mixing models.




Mime
View raw message