Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES build/apr_rules.mk.in configure.in include/apr.h.in test/Makefile.in
On Sat, Apr 2, 2011 at 9:50 AM, traw...@apache.org wrote: Author: trawick Date: Sat Apr 2 13:50:07 2011 New Revision: 1088023 URL: http://svn.apache.org/viewvc?rev=1088023view=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=1088023r1=1088022r2=1088023view=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
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 h; 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.
Re: svn commit: r1088023 - in /apr/apr/trunk: CHANGES build/apr_rules.mk.in configure.in include/apr.h.in test/Makefile.in
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
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
On Sat, Apr 2, 2011 at 11:17 AM, Guenter Knauf fua...@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
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
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
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
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.
