Hi, If we are using apr in multi threaded environment, what is a better choice? Static libs or dlls?
Regards, Prakash Bande Director - Hyperworks Enterprise Software Altair Eng. Inc. Troy MI Ph: 248-614-2400 ext 489 Cell: 248-404-0292 -----Original Message----- From: William A. Rowe Jr. [mailto:[email protected]] Sent: Thursday, July 26, 2012 6:26 PM To: [email protected] Subject: Re: Build of libapritil-1.lib failed on Windows using VS2008 On 7/18/2012 5:40 AM, Jeff Trawick wrote: > On Mon, Jul 16, 2012 at 1:27 PM, Alona Rossen <[email protected]> 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.
