At 02:31 AM 3/2/2005, Maxim wrote:
>Has anyone use APR library (http://apr.apache.org) with your application for Win32 with MinGW?
>First, I tried compiling APR library with MinGW but got the same error about shared memory allocation support:
>./configure:Error: decision on anonymous shared memory allocation method failed
This sort of check means that no decision can be made.
The reason that it can't be made is that APR is only designed
to be compiled native (the foo/win32/ source trees), and the
foo/unix/ trees won't be ported to provide faux-unix support.
APR is designed to take advantage of the environment, should
we transpose apr concepts into unix concepts into win32 through
two proxies (apr and unix compat layers such as mingw/cygwin)
we will get this wrong and lose any potential benefit of a
Obviously, for this to work on mingw or cygwin, the appropriate
autoconf and code elections must be programmed into configure.in
and the included macros in build/.
One hassle, certain modules are used from win32/, but when the
sources are common, they are built from unix/, and our build
schema doesn't support this mix-n-match today.
>Second, I tried use binary files from APR and Apache tarballs for Win32 (compiled with MSVC).
>I followed by instructions on this page http://mingw.org/mingwfaq.shtml#faq-msvcdll , but they can't help me, linking proccess continue issue "undefined reference to ..."
>My decision of this problem was extract import library (.a) from
>libapr.dll and link it in my application. My steps:
>- Create two .def files (One with __cdecl functions and second
>with __stdcall functions). They are:
> 1. libapr-c.def
> LIBRARY libapr.dll
> apr_app_init_complete DATA
> apr_day_snames DATA
> apr_month_snames DATA
> 2. libapr-s.def
> LIBRARY libapr.dll
> -Create two import libs , using these commands:
> dlltool -U --input-def libapr-s.def -l libapr-s.a
> dlltool --input-def libapr-c.def -l libapr-c.a
>-Then, i link these libs to my app. Linking finished well without errors. But,there were errors at runtime.
>After recompiling libapr-c.a (with __stdcall funcs) with new
>def file (i add alias for every function):
>apr_accept = _apr_accept@...
>_apr_accept@... = _apr_accept@...
>there are'n runtime errors , but only for __stdcall function. :(
>__cdecl functions continue call errors at runtime.
>And a can't to solve this problem.
I humbly suggest that the build you are creating is essentially
invalid, but if you would like to help us put together appropriate
patches, we should be able to convince our configure and libtool
schema to do the right things.
If you try to use the Win32 headers and link to apr.lib (instead
of libapr.lib) you simply define APR_EXPORT_STATIC, and there are
no dynamic library issues to contend with.