You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by tr...@apache.org on 2011/04/02 15:50:07 UTC
svn commit: r1088023 - in /apr/apr/trunk: CHANGES build/apr_rules.mk.in
configure.in include/apr.h.in test/Makefile.in
Author: trawick
Date: Sat Apr 2 13:50:07 2011
New Revision: 1088023
URL: http://svn.apache.org/viewvc?rev=1088023&view=rev
Log:
MinGW/MSYS: Support shared builds of APR, other general improvements
to support of this toolchain.
PR: 46175
Submitted by: Carlo Bramini <carlo.bramix libero.it>
Modified:
apr/apr/trunk/CHANGES
apr/apr/trunk/build/apr_rules.mk.in
apr/apr/trunk/configure.in
apr/apr/trunk/include/apr.h.in
apr/apr/trunk/test/Makefile.in
Modified: apr/apr/trunk/CHANGES
URL: http://svn.apache.org/viewvc/apr/apr/trunk/CHANGES?rev=1088023&r1=1088022&r2=1088023&view=diff
==============================================================================
--- apr/apr/trunk/CHANGES [utf-8] (original)
+++ apr/apr/trunk/CHANGES [utf-8] Sat Apr 2 13:50:07 2011
@@ -1,6 +1,10 @@
-*- coding: utf-8 -*-
Changes for APR 2.0.0
+ *) MinGW/MSYS: Support shared builds of APR, other general improvements
+ to support of this toolchain. PR 46175. [Carlo Bramini
+ <carlo.bramix libero.it>]
+
*) Support libxml2 as an alternative XML parser to expat [Nick Kew]
*) Hide apr_wait_for_io_or_timeout() from public view and add instead
Modified: apr/apr/trunk/build/apr_rules.mk.in
URL: http://svn.apache.org/viewvc/apr/apr/trunk/build/apr_rules.mk.in?rev=1088023&r1=1088022&r2=1088023&view=diff
==============================================================================
--- apr/apr/trunk/build/apr_rules.mk.in (original)
+++ apr/apr/trunk/build/apr_rules.mk.in Sat Apr 2 13:50:07 2011
@@ -55,6 +55,10 @@ EXTRA_LDFLAGS=@EXTRA_LDFLAGS@
EXTRA_LIBS=@EXTRA_LIBS@
EXTRA_INCLUDES=@EXTRA_INCLUDES@
+# CPPFLAGS which are used only while building APR itself
+#
+INTERNAL_CPPFLAGS=@INTERNAL_CPPFLAGS@
+
# NOTEST_* are flags and libraries that can be added by the user without
# causing them to be used in configure tests (necessary for things like
# -Werror and other strict warnings that maintainers like to use).
@@ -70,7 +74,7 @@ NOTEST_LIBS=@NOTEST_LIBS@
# left-to-right precedence and CPPFLAGS may include user-defined overrides.
#
ALL_CFLAGS = $(EXTRA_CFLAGS) $(NOTEST_CFLAGS) $(CFLAGS)
-ALL_CPPFLAGS = $(DEFS) $(EXTRA_CPPFLAGS) $(NOTEST_CPPFLAGS) $(CPPFLAGS)
+ALL_CPPFLAGS = $(DEFS) $(INTERNAL_CPPFLAGS) $(EXTRA_CPPFLAGS) $(NOTEST_CPPFLAGS) $(CPPFLAGS)
ALL_LDFLAGS = $(EXTRA_LDFLAGS) $(NOTEST_LDFLAGS) $(LDFLAGS)
ALL_LIBS = $(LIBS) $(NOTEST_LIBS) $(EXTRA_LIBS)
ALL_INCLUDES = $(INCLUDES) $(EXTRA_INCLUDES)
Modified: apr/apr/trunk/configure.in
URL: http://svn.apache.org/viewvc/apr/apr/trunk/configure.in?rev=1088023&r1=1088022&r2=1088023&view=diff
==============================================================================
--- apr/apr/trunk/configure.in (original)
+++ apr/apr/trunk/configure.in Sat Apr 2 13:50:07 2011
@@ -293,7 +293,7 @@ AC_ARG_WITH(libtool, [ --without-libtoo
if test "x$use_libtool" = "xyes"; then
lt_compile='$(LIBTOOL) $(LTFLAGS) --mode=compile $(COMPILE) -o $@ -c $< && touch $@'
LT_VERSION="-version-info `$get_version libtool $version_hdr APR`"
- link="\$(LIBTOOL) \$(LTFLAGS) --mode=link \$(LT_LDFLAGS) \$(COMPILE) \$(LT_VERSION) \$(ALL_LDFLAGS) -o \$@"
+ link="\$(LIBTOOL) \$(LTFLAGS) --mode=link \$(COMPILE) \$(LT_LDFLAGS) \$(LT_VERSION) \$(ALL_LDFLAGS) -o \$@"
so_ext='lo'
lib_target='-rpath $(libdir) $(OBJECTS)'
export_lib_target='-rpath \$(libdir) \$(OBJECTS)'
@@ -309,6 +309,9 @@ case $host in
*-solaris2*)
apr_platform_runtime_link_flag="-R"
;;
+ *-mingw* | *-cygwin*)
+ LT_LDFLAGS="$LT_LDFLAGS -no-undefined"
+ ;;
*)
;;
esac
@@ -443,6 +446,20 @@ case "$host:$CC" in
APR_SETVAR(CC,mwcc)
APR_SETVAR(AR,ar)
;;
+
+dnl If building static APR, both the APR build and the app build
+dnl need -DAPR_DECLARE_STATIC to generate the right linkage from
+dnl APR_DECLARE et al.
+dnl If building dynamic APR, the APR build needs APR_DECLARE_EXPORT
+dnl and the app build should have neither define.
+
+ *-mingw* | *-cygwin*)
+ if test "$enable_shared" = "yes"; then
+ APR_ADDTO(INTERNAL_CPPFLAGS, -DAPR_DECLARE_EXPORT)
+ else
+ APR_ADDTO(CPPFLAGS, -DAPR_DECLARE_STATIC)
+ fi
+ ;;
esac
AC_CACHE_CHECK([whether the compiler provides atomic builtins], [ap_cv_atomic_builtins],
@@ -679,14 +696,8 @@ dnl without the extra " " in that case,
dnl end up LIBS="-lm -lcrypt -lnsl -ldl" which is an annoyance.
case $host in
*-mingw*)
- AC_CHECK_LIB(msvcrt, getpid)
- APR_CHECK_DLL_FUNC(kernel32, SetErrorMode@4)
- APR_CHECK_DLL_FUNC(advapi32, GetSecurityInfo@32)
- APR_CHECK_DLL_FUNC(ws2_32, gethostbyname@4)
- APR_CHECK_DLL_FUNC(shell32, CommandLineToArgvW@8)
- APR_CHECK_DLL_FUNC(kernel32,[CreateFileMappingA@24],
- [ac_cv_func_CreateFileMapping=$ac_cv_lib_kernel32_CreateFileMappingA])
- APR_CHECK_DLL_FUNC(rpcrt4,[UuidCreate@4])
+ APR_ADDTO(LIBS,[-lshell32 -ladvapi32 -lws2_32 -lrpcrt4 -lmswsock])
+ ac_cv_func_CreateFileMapping=yes
;;
*)
AC_SEARCH_LIBS(gethostbyname, nsl)
@@ -2668,6 +2679,7 @@ AC_SUBST(NOTEST_INCLUDES)
dnl ----------------------------- Construct the files
+AC_SUBST(INTERNAL_CPPFLAGS)
AC_SUBST(LDLIBS)
AC_SUBST(INCLUDES)
AC_SUBST(AR)
Modified: apr/apr/trunk/include/apr.h.in
URL: http://svn.apache.org/viewvc/apr/apr/trunk/include/apr.h.in?rev=1088023&r1=1088022&r2=1088023&view=diff
==============================================================================
--- apr/apr/trunk/include/apr.h.in (original)
+++ apr/apr/trunk/include/apr.h.in Sat Apr 2 13:50:07 2011
@@ -472,6 +472,8 @@ typedef apr_uint32_t apr_uin
*/
#define APR_THREAD_FUNC @apr_thread_func@
+#if defined(DOXYGEN) || !defined(WIN32)
+
/**
* The public APR functions are declared with APR_DECLARE(), so they may
* use the most appropriate calling convention. Public APR functions with
@@ -524,6 +526,20 @@ typedef apr_uint32_t apr_uin
*/
#define APR_DECLARE_DATA
+#elif defined(APR_DECLARE_STATIC)
+#define APR_DECLARE(type) type __stdcall
+#define APR_DECLARE_NONSTD(type) type __cdecl
+#define APR_DECLARE_DATA
+#elif defined(APR_DECLARE_EXPORT)
+#define APR_DECLARE(type) __declspec(dllexport) type __stdcall
+#define APR_DECLARE_NONSTD(type) __declspec(dllexport) type __cdecl
+#define APR_DECLARE_DATA __declspec(dllexport)
+#else
+#define APR_DECLARE(type) __declspec(dllimport) type __stdcall
+#define APR_DECLARE_NONSTD(type) __declspec(dllimport) type __cdecl
+#define APR_DECLARE_DATA __declspec(dllimport)
+#endif
+
#if !defined(WIN32) || defined(APU_MODULE_DECLARE_STATIC)
/**
* Declare a dso module's exported module structure as APR_MODULE_DECLARE_DATA.
Modified: apr/apr/trunk/test/Makefile.in
URL: http://svn.apache.org/viewvc/apr/apr/trunk/test/Makefile.in?rev=1088023&r1=1088022&r2=1088023&view=diff
==============================================================================
--- apr/apr/trunk/test/Makefile.in (original)
+++ apr/apr/trunk/test/Makefile.in Sat Apr 2 13:50:07 2011
@@ -74,7 +74,7 @@ INCLUDES=-I$(INCDIR) -I$(srcdir)/../incl
# link programs using -no-install to get real executables not
# libtool wrapper scripts which link an executable when first run.
-LINK_PROG = $(LIBTOOL) $(LTFLAGS) --mode=link $(LT_LDFLAGS) $(COMPILE) \
+LINK_PROG = $(LIBTOOL) $(LTFLAGS) --mode=link $(COMPILE) $(LT_LDFLAGS) \
@LT_NO_INSTALL@ $(ALL_LDFLAGS) -o $@
# STDTEST_PORTABLE;
@@ -126,10 +126,10 @@ mod_test.lo: $(srcdir)/mod_test.c
-c $(srcdir)/mod_test.c
OBJECTS_mod_test = mod_test.lo
-mod_test.la: $(OBJECTS_mod_test)
+mod_test.la: $(OBJECTS_mod_test) $(LOCAL_LIBS)
$(LIBTOOL) $(LTFLAGS) --mode=link $(COMPILE) -rpath `pwd` -module \
-avoid-version $(LT_LDFLAGS) $(ALL_LDFLAGS) -o $@ \
- $(OBJECTS_mod_test)
+ $(OBJECTS_mod_test) $(LOCAL_LIBS)
OBJECTS_libmod_test = mod_test.lo $(LOCAL_LIBS)
libmod_test.la: $(OBJECTS_libmod_test)
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES
build/apr_rules.mk.in configure.in include/apr.h.in test/Makefile.in
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Apr 2, 2011 at 9:50 AM, <tr...@apache.org> wrote:
> Author: trawick
> Date: Sat Apr 2 13:50:07 2011
> New Revision: 1088023
>
> URL: http://svn.apache.org/viewvc?rev=1088023&view=rev
> Log:
> MinGW/MSYS: Support shared builds of APR, other general improvements
> to support of this toolchain.
>
> PR: 46175
> Submitted by: Carlo Bramini <carlo.bramix libero.it>
>
> Modified:
> apr/apr/trunk/CHANGES
> apr/apr/trunk/build/apr_rules.mk.in
> apr/apr/trunk/configure.in
> apr/apr/trunk/include/apr.h.in
> apr/apr/trunk/test/Makefile.in
>
> Modified: apr/apr/trunk/CHANGES
> URL: http://svn.apache.org/viewvc/apr/apr/trunk/CHANGES?rev=1088023&r1=1088022&r2=1088023&view=diff
> ==============================================================================
> --- apr/apr/trunk/CHANGES [utf-8] (original)
> +++ apr/apr/trunk/CHANGES [utf-8] Sat Apr 2 13:50:07 2011
> @@ -1,6 +1,10 @@
> -*- coding: utf-8 -*-
> Changes for APR 2.0.0
>
> + *) MinGW/MSYS: Support shared builds of APR, other general improvements
> + to support of this toolchain. PR 46175. [Carlo Bramini
> + <carlo.bramix libero.it>]
The MinGW support has been built up over a very, very long time. (I
see at least jerenkrantz, wrowe, fuankg, and myself among the commits
of different pieces.) If there are non-committers among that group
besides Carlo it would be good to add their name to CHANGES as well.
Does anyone recall other non-committers with related contributions in
the past?
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES
build/apr_rules.mk.in configure.in include/apr.h.in test/Makefile.in
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Apr 2, 2011 at 11:17 AM, Guenter Knauf <fu...@apache.org> wrote:
> Am 02.04.2011 16:59, schrieb Guenter Knauf:
>>
>> no, something which is kinda /me giving up on teaching configure to do
>> it right .....
>> http://people.apache.org/~fuankg/mingw/MWGNUmakefile
>> http://people.apache.org/~fuankg/mingw/MWGNUmakefile.inc
>> with that makefile you have both static and dynamic within less the time
>> than what configure only needs .... :-)
>> and honestly I'm thinking this is brobably a better approach since what
>> we now did while wasting countless hours is basically exactly same:
>> overwrite configure tests manually :-(
>
> pros:
> - fast
> - build is 100% in sync with MSVC build (uses same apr.hw etc.)
We do have some sync issues in the short term, but in the long term I
much prefer --disable-feature/--enable-feature/--with-supportlib and
being able to autodetect some variations to messing around with the
.hw file (or creating some other UI for manipulating apr.hw).
> - easy to maintain for everyone who's familar with GNU make
> - no dependency on Python
> - no dependency on MSYS / bash / configure / m4 / ...
>
> cons:
> - extra maintenance of MWGNUmakefile.inc when source files are added or
> removed
>
Negative vibe warning :)
Does this create the application build support? (apr-2-config?) Are
apr consumers left with adjusting to the third build system to pick up
build tools/flags?
This use of another build system doesn't bring much happiness here. I
see a tremendous value down the road with exactly one build system I
can use across all platforms of interest and be able to select feature
sets, integrate third-party libraries, point to alternate tools, set
custom build flags, or even patch in customizations (okay, hacks) and
not have to understand two build systems in order to do that, or have
significant work remaining after getting customizations to work on
Linux.
> the cons can be axed if we would use separate makefile.inc for the configure
> builds as well where we list the source files and include these into the
> created Makefile ... - then we would in future only maintain changes at one
> place = makefile.inc
>
> one point which made me hack this makefile was to see how long it would take
> to create a working makefile which does the job, and that was done within
> ~2.5 hours;
> the other point is that I see not much sense in letting configure waste a
> huge amount of time for various tests which then finally get anyway
> overwritten - and if I look at our branches this becomes even worse because
> configure runs then twice (once for APR, once for APU) ...
It is definitely unfortunate that much of the time consumed by
configure is wasted for Windows. But then I guess a lot is wasted for
any particular environment. A set of ac_cv_* envvars comes to mind as
a nice time saver, whatever the platform.
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES build/apr_rules.mk.in
configure.in include/apr.h.in test/Makefile.in
Posted by Guenter Knauf <fu...@apache.org>.
Am 02.04.2011 16:59, schrieb Guenter Knauf:
> no, something which is kinda /me giving up on teaching configure to do
> it right .....
> http://people.apache.org/~fuankg/mingw/MWGNUmakefile
> http://people.apache.org/~fuankg/mingw/MWGNUmakefile.inc
> with that makefile you have both static and dynamic within less the time
> than what configure only needs .... :-)
> and honestly I'm thinking this is brobably a better approach since what
> we now did while wasting countless hours is basically exactly same:
> overwrite configure tests manually :-(
pros:
- fast
- build is 100% in sync with MSVC build (uses same apr.hw etc.)
- easy to maintain for everyone who's familar with GNU make
- no dependency on Python
- no dependency on MSYS / bash / configure / m4 / ...
cons:
- extra maintenance of MWGNUmakefile.inc when source files are added or
removed
the cons can be axed if we would use separate makefile.inc for the
configure builds as well where we list the source files and include
these into the created Makefile ... - then we would in future only
maintain changes at one place = makefile.inc
one point which made me hack this makefile was to see how long it would
take to create a working makefile which does the job, and that was done
within ~2.5 hours;
the other point is that I see not much sense in letting configure waste
a huge amount of time for various tests which then finally get anyway
overwritten - and if I look at our branches this becomes even worse
because configure runs then twice (once for APR, once for APU) ...
Gün.
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES build/apr_rules.mk.in
configure.in include/apr.h.in test/Makefile.in
Posted by Guenter Knauf <fu...@apache.org>.
Am 02.04.2011 23:54, schrieb William A. Rowe Jr.:
> When the compiler has the insight that it is binding against relocatable,
> loadable sections, it has a chance to change all references to a vtable
> in mutable heap, and leave the actual binary images alone. Failure to do
> this for data pointers is usually lethal.
>
> The inverse of what you suggest, compiling it all export whether it will be
> used statically or dynamically works out a bit better, but it's still worth
> performing two compilations.
and that cant be forced by compiler switches like -fPIC and -msep-data ?
Gün.
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES build/apr_rules.mk.in
configure.in include/apr.h.in test/Makefile.in
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 4/2/2011 4:35 PM, Guenter Knauf wrote:
> Am 02.04.2011 20:29, schrieb William A. Rowe Jr.:
>> On 4/2/2011 10:27 AM, Guenter Knauf wrote:
>>> *if* we want to do it 'right' in one pass then I believe we would need to build with
>>> APR_DECLARE_STATIC and then get the DDL linked with a .def file (which is close to what is
>>> done on Linux with the export*.c hacks);
>>> I would volunteer to modify our make_nw_exports.awk to be able to write a Windows .def
>>> file, but I would fail to integrate this into a configure build process ... :-(
>>
>> You know that leads to segfaults, and per-process modification of what are otherwise
>> constant/shared .text pages, right?
> nope - I didnt yet ...
When the compiler has the insight that it is binding against relocatable,
loadable sections, it has a chance to change all references to a vtable
in mutable heap, and leave the actual binary images alone. Failure to do
this for data pointers is usually lethal.
The inverse of what you suggest, compiling it all export whether it will be
used statically or dynamically works out a bit better, but it's still worth
performing two compilations.
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES build/apr_rules.mk.in
configure.in include/apr.h.in test/Makefile.in
Posted by Guenter Knauf <fu...@apache.org>.
Am 02.04.2011 20:29, schrieb William A. Rowe Jr.:
> On 4/2/2011 10:27 AM, Guenter Knauf wrote:
>> *if* we want to do it 'right' in one pass then I believe we would need to build with
>> APR_DECLARE_STATIC and then get the DDL linked with a .def file (which is close to what is
>> done on Linux with the export*.c hacks);
>> I would volunteer to modify our make_nw_exports.awk to be able to write a Windows .def
>> file, but I would fail to integrate this into a configure build process ... :-(
>
> You know that leads to segfaults, and per-process modification of what are otherwise
> constant/shared .text pages, right?
nope - I didnt yet ...
Gün.
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES build/apr_rules.mk.in
configure.in include/apr.h.in test/Makefile.in
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 4/2/2011 10:27 AM, Guenter Knauf wrote:
> *if* we want to do it 'right' in one pass then I believe we would need to build with
> APR_DECLARE_STATIC and then get the DDL linked with a .def file (which is close to what is
> done on Linux with the export*.c hacks);
> I would volunteer to modify our make_nw_exports.awk to be able to write a Windows .def
> file, but I would fail to integrate this into a configure build process ... :-(
You know that leads to segfaults, and per-process modification of what are otherwise
constant/shared .text pages, right?
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES build/apr_rules.mk.in
configure.in include/apr.h.in test/Makefile.in
Posted by Guenter Knauf <fu...@apache.org>.
Am 02.04.2011 16:59, schrieb Guenter Knauf:
> Am 02.04.2011 16:39, schrieb Jeff Trawick:
>> If you want both static and dynamic:
>>
>> * two builds in two passes of APR
>> * further hacks to allow the two builds to be co-resident in the
>> install location, since apr-2-config needs to know whether or not to
>> spit out APR_DECLARE_STATIC in CPPFLAGS (and possibly other,
>> uninvestigated glitches to resolved)
>>
>> So yes, at present you get a dynamic build by default, and if you want
>> a static build you need to add --disabled-shared as well to avoid
>> current glitches.
> k, thats what I thought ...
*if* we want to do it 'right' in one pass then I believe we would need
to build with APR_DECLARE_STATIC and then get the DDL linked with a .def
file (which is close to what is done on Linux with the export*.c hacks);
I would volunteer to modify our make_nw_exports.awk to be able to write
a Windows .def file, but I would fail to integrate this into a configure
build process ... :-(
Gün.
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES build/apr_rules.mk.in
configure.in include/apr.h.in test/Makefile.in
Posted by Guenter Knauf <fu...@apache.org>.
Am 02.04.2011 16:39, schrieb Jeff Trawick:
> If you want both static and dynamic:
>
> * two builds in two passes of APR
> * further hacks to allow the two builds to be co-resident in the
> install location, since apr-2-config needs to know whether or not to
> spit out APR_DECLARE_STATIC in CPPFLAGS (and possibly other,
> uninvestigated glitches to resolved)
>
> So yes, at present you get a dynamic build by default, and if you want
> a static build you need to add --disabled-shared as well to avoid
> current glitches.
k, thats what I thought ...
> I'm not sure what you mean by that static makefile. Something that
> drives the configure+make+make-install twice?
no, something which is kinda /me giving up on teaching configure to do
it right .....
http://people.apache.org/~fuankg/mingw/MWGNUmakefile
http://people.apache.org/~fuankg/mingw/MWGNUmakefile.inc
with that makefile you have both static and dynamic within less the time
than what configure only needs .... :-)
and honestly I'm thinking this is brobably a better approach since what
we now did while wasting countless hours is basically exactly same:
overwrite configure tests manually :-(
here's the build log with this makefile:
http://people.apache.org/~fuankg/mingw/build_mingw32-trunk.txt.gz
Gün.
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES
build/apr_rules.mk.in configure.in include/apr.h.in test/Makefile.in
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Apr 2, 2011 at 10:30 AM, Guenter Knauf <fu...@apache.org> wrote:
> Hi Jeff,
> Am 02.04.2011 15:50, schrieb trawick@apache.org:
>>
>> +dnl If building static APR, both the APR build and the app build
>> +dnl need -DAPR_DECLARE_STATIC to generate the right linkage from
>> +dnl APR_DECLARE et al.
>> +dnl If building dynamic APR, the APR build needs APR_DECLARE_EXPORT
>> +dnl and the app build should have neither define.
>> +
>> + *-mingw* | *-cygwin*)
>> + if test "$enable_shared" = "yes"; then
>> + APR_ADDTO(INTERNAL_CPPFLAGS, -DAPR_DECLARE_EXPORT)
>> + else
>> + APR_ADDTO(CPPFLAGS, -DAPR_DECLARE_STATIC)
>> + fi
>> + ;;
>> esac
>
> hmmmm; without having this tested yet - wouldnt this require that the whole
> build uses two passes? What if you use:
> ./configure --shared --static
If you want both static and dynamic:
* two builds in two passes of APR
* further hacks to allow the two builds to be co-resident in the
install location, since apr-2-config needs to know whether or not to
spit out APR_DECLARE_STATIC in CPPFLAGS (and possibly other,
uninvestigated glitches to resolved)
So yes, at present you get a dynamic build by default, and if you want
a static build you need to add --disabled-shared as well to avoid
current glitches.
> I've meanwhile created a static makefile which does exactly this, and
> therefore needs compile go with -DAPR_DECLARE_STATIC for creating the static
> lib, and another with -DAPR_DECLARE_EXPORT for creating the DLL ...
I'm not sure what you mean by that static makefile. Something that
drives the configure+make+make-install twice?
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES build/apr_rules.mk.in
configure.in include/apr.h.in test/Makefile.in
Posted by Guenter Knauf <fu...@apache.org>.
Hi Jeff,
Am 02.04.2011 15:50, schrieb trawick@apache.org:
> +dnl If building static APR, both the APR build and the app build
> +dnl need -DAPR_DECLARE_STATIC to generate the right linkage from
> +dnl APR_DECLARE et al.
> +dnl If building dynamic APR, the APR build needs APR_DECLARE_EXPORT
> +dnl and the app build should have neither define.
> +
> + *-mingw* | *-cygwin*)
> + if test "$enable_shared" = "yes"; then
> + APR_ADDTO(INTERNAL_CPPFLAGS, -DAPR_DECLARE_EXPORT)
> + else
> + APR_ADDTO(CPPFLAGS, -DAPR_DECLARE_STATIC)
> + fi
> + ;;
> esac
hmmmm; without having this tested yet - wouldnt this require that the
whole build uses two passes? What if you use:
./configure --shared --static
??
I've meanwhile created a static makefile which does exactly this, and
therefore needs compile go with -DAPR_DECLARE_STATIC for creating the
static lib, and another with -DAPR_DECLARE_EXPORT for creating the DLL ...
Gün.