You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Maxim <ma...@red-pyramid.com> on 2005/03/02 09:31:53 UTC
Cannot link APR library with MinGW
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:
checking for mmap... no
checking for munmap... no
checking for shm_open... no
checking for shm_unlink... no
checking for shmget... no
checking for shmat... no
checking for shmdt... no
checking for shmctl... no
checking for create_area... no
checking for MAP_ANON in sys/mman.h... no
checking for /dev/zero... yes
./configure:Error: decision on anonymous shared memory allocation method
failed
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
-------Content---------
LIBRARY libapr.dll
EXPORTS
apr_app_init_complete DATA
apr_day_snames DATA
apr_dbg_log
apr_file_printf
apr_month_snames DATA
...
-----------------------
2. libapr-s.def
-------Content---------
LIBRARY libapr.dll
EXPORTS
_apr_accept@12
_apr_allocator_alloc@8
_apr_allocator_create@4
_apr_allocator_destroy@4
_apr_allocator_free@8
...
-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):
------------------
LIBRARY libapr.dll
EXPORTS
apr_accept = _apr_accept@12
_apr_accept@12 = _apr_accept@12
...
------------------
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.
Re: Cannot link APR library with MinGW
Posted by Curt Arnold <ca...@apache.org>.
> *Big* difference between mingw and cygwin.
>
> For mingw, yes, the win32 code needs to be selected in appropriately,
> because mingw isn't really a compat layer - rather it's the GNU
> toolchain running on undisguised Windows.
>
> On Cygwin, however, apr works very nicely built in unix mode - both
> Apache 2 and Subversion both work on Cygwin with minimal tweaking -
> and indeed it would be fatal to try and make apr use the win32 code on
> cygwin, since it would break cygwin's unixy abstractions for apr's
> client programs.
>
I've got APR building using Ant + cpptasks for both MS and Borland
compilers since those compilers are of interest to log4cxx users and
log4cxx now uses APR. The build files are in the log4cxx CVS
(apr-build.xml etc). MinGW is next on my list. I haven't attempted it
but it might work out of the box. You could try:
Install ant-1.6.2 (http://ant.apache.org)
Build cpptasks and ant-contrib from CVS HEAD
(http://sf.net/projects/ant-contrib)
Place cpptasks.jar and ant-contrib.jar on classpath
checkout logging-log4cxx from Apache CVS
cd logging-log4cxx
Place MinGW toolkit on path
ant -Dcompiler=gcc
which will attempt to download APR 1.1.0 from a mirror, apply patches
to allow it to compile with the Borland toolchain, build apr,
apr-iconv, apr-util and log4cxx.
If you are just interested in APR and don't want to apply the Borland
fixes, copy apr-build.xml to build.xml in the APR directory and run
"ant -Dcompiler=gcc"
Re: Cannot link APR library with MinGW
Posted by Max Bowsher <ma...@ukf.net>.
William A. Rowe, Jr. wrote:
> 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
> portability layer.
>
> 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/.
*Big* difference between mingw and cygwin.
For mingw, yes, the win32 code needs to be selected in appropriately,
because mingw isn't really a compat layer - rather it's the GNU toolchain
running on undisguised Windows.
On Cygwin, however, apr works very nicely built in unix mode - both Apache 2
and Subversion both work on Cygwin with minimal tweaking - and indeed it
would be fatal to try and make apr use the win32 code on cygwin, since it
would break cygwin's unixy abstractions for apr's client programs.
Max.
Re: Cannot link APR library with MinGW
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
portability layer.
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
> -------Content---------
> LIBRARY libapr.dll
> EXPORTS
> apr_app_init_complete DATA
> apr_day_snames DATA
> apr_dbg_log
> apr_file_printf
> apr_month_snames DATA
> ...
> -----------------------
> 2. libapr-s.def
> -------Content---------
> LIBRARY libapr.dll
> EXPORTS
> _apr_accept@12
> _apr_allocator_alloc@8
> _apr_allocator_create@4
> _apr_allocator_destroy@4
> _apr_allocator_free@8
> ...
>
> -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):
>------------------
>LIBRARY libapr.dll
>EXPORTS
>apr_accept = _apr_accept@12
>_apr_accept@12 = _apr_accept@12
>...
>------------------
>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.
Bill
Re: Cannot link APR library with MinGW
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
portability layer.
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
> -------Content---------
> LIBRARY libapr.dll
> EXPORTS
> apr_app_init_complete DATA
> apr_day_snames DATA
> apr_dbg_log
> apr_file_printf
> apr_month_snames DATA
> ...
> -----------------------
> 2. libapr-s.def
> -------Content---------
> LIBRARY libapr.dll
> EXPORTS
> _apr_accept@12
> _apr_allocator_alloc@8
> _apr_allocator_create@4
> _apr_allocator_destroy@4
> _apr_allocator_free@8
> ...
>
> -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):
>------------------
>LIBRARY libapr.dll
>EXPORTS
>apr_accept = _apr_accept@12
>_apr_accept@12 = _apr_accept@12
>...
>------------------
>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.
Bill
Re: Cannot link APR library with MinGW
Posted by Maxim <ma...@red-pyramid.com>.
William A. Rowe, Jr. wrote:
>
> I humbly suggest that the build you are creating is essentially
> invalid,
It's obviously, because i don't see stable version of my project too :).
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.
From this place, may with details? In my previous experience i use
binary and headers files from Apache 2 tarball (for win32).