On Sat, Apr 2, 2011 at 10:30 AM, Guenter Knauf <fua...@apache.org> wrote: > Hi Jeff, > Am 02.04.2011 15:50, schrieb traw...@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?
