You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2006/07/14 21:31:07 UTC
Re: [patch 00/17] successful msys/mingw build
On 4/14/06, John Mark Vandenberg <ja...@gmail.com> wrote:
> This series of patches allows apr to be built using MSYS and MinGW, but only with CFLAGS=" -O0 ". Compared with tests using MS VC++ builds, only the dso functions appear to have problems specific to msys builds.
>
> Failed Tests Total Fail Failed %
> ===================================================
> testdso 5 4 80.00%
> testpipe 9 2 22.22%
> testsock 7 1 14.29%
Okay. Trunk now matches this behavior on mingw. =)
A few minor things left:
- testatomic aborts(); so you have to do 'testall -x testatomic' to
get the above
- gen-build.py script needs to do two things:
- ignore apr_app.c from the build. (it's not meant to be compiled -
only as an example;
removing it from OBJECTS_misc_win32 in build-outputs.mk is sufficient.)
- emit '/' instead of '\' as msys make doesn't like that. (a simple
sed works for now.)
- jlibtool (--enable-experimental-libtool=yes to configure)
- GNU libtool refuses to create DLLs, but jlibtool can create them.
(I stopped caring about GNU libtool once it failed to create DLLs;
so if it works, good;
but I don't care to play their silly games...use jlibtool instead...)
- jlibtool compiles and links about 6x faster than GNU libtool (duh)
- As with all jlibtool builds, you need to install the DLLs in the
PATH to run apps
- However, -module isn't working yet; so the libmod_test.la doesn't link
(removing it from testall.exe's Makefile dependencies seems to do ok.)
If anyone else wants to jump in at this point, the big nasty stuff
should be in the tree now. I'll be working on these to-do items with
a slightly lesser priority now.
For the record, here's a quick dump of what I downloaded/installed
from mingw.sf.net:
- MinGW 5.0.3
- MSYS-1.0.11-2004.04-30-1
- msysDTK-1.0.1
- msys-autoconf-2.5.9.tar.bz2 (extract to /usr)
- msys-libtool-1.5.tar.bz2 (extract to /usr)
If you install those in that order, you should be able to reproduce
the necessary dev setup.
Many thanks to John for these patches! -- justin
Re: [patch 00/17] successful msys/mingw build
Posted by Paul Querna <ch...@force-elite.com>.
Justin Erenkrantz wrote:
> On 7/14/06, Paul Querna <ch...@force-elite.com> wrote:
....
>> Is this the correct way to do it, or is something wrong in my setup?
>
> That patch should be fine. This is due to Python being a 'true' Win32
> build - so it has path delimiters of '\' which the msys make doesn't
> accept (I referred to this in my earlier post, FWIW - perhaps too
> cryptically though). In a perfect world, we would conditionalize this
> mapping to only be done on Win32 too; but it's essentially a no-op on
> Unix platforms. So, +1.
Committed in r422146.
> BTW, I saw on #apr that you were having an issue with:
>
> /mingw/lib/libmingw32.a(main.o)(.text+0x106):main.c: undefined
> reference to `WinMain@16'
>
> This is caused by apr_app.c being pulled in incorrectly (also
> mentioned before too). It defines main() and should not be linked
> with the APR DLL. We need to teach gen-build to ignore that one file.
> (Ideally, we should delete it from the tree, but the test programs
> use it and doing so would cause us to have to tweak MSVC++'s build
> system and I really don't want to do that...)
Thanks, killed it, and it works.
I also got apr-util to compile -- I tried using the bundled expat, but
it broke due to autoconf sillyness -- So I built it using an external
Expart 2.0.0 and everything built great.
-Paul
Re: [patch 00/17] successful msys/mingw build
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 7/14/06, Paul Querna <ch...@force-elite.com> wrote:
> Justin Erenkrantz wrote:
> > For the record, here's a quick dump of what I downloaded/installed
> > from mingw.sf.net:
> > - MinGW 5.0.3
> > - MSYS-1.0.11-2004.04-30-1
> > - msysDTK-1.0.1
> > - msys-autoconf-2.5.9.tar.bz2 (extract to /usr)
> > - msys-libtool-1.5.tar.bz2 (extract to /usr)
> >
>
> I also needed:
> Python-2.5b2 (to run buildconf)
> TortoiseSVN
>
> So that I could run buildconf.
>
> Steps:
> 1) checkout source
> 2) open msys
> 3) run buildconf
> 4) run ./configure with:
> --enable-experimental-libtool CFLAGS="-O0"
> 5) go get a beer (configure is really slow...)
> 6) run make
>
> Then I ran into problems:
> make[1]: Entering directory `/c/work/asf/apr'
> /c/work/asf/apr/libtool --silent --mode=compile gcc -O0
> -DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE -I./include
> -I/c/work/asf/apr/include/arch/win32 -I./include/arch/unix
> -I/c/work/asf/apr/include -o passwd\apr_getpass.lo -c
> passwd\apr_getpass.c && touch passwd\apr_getpass.lo
> gcc.exe: passwdapr_getpass.c: No such file or directory
> gcc.exe: no input files
> make[1]: *** [passwd\apr_getpass.lo] Error 1
> make[1]: Leaving directory `/c/work/asf/apr'
> make: *** [all-recursive] Error 1
>
> If I manually changed the libtool line, to use / as path deliminators,
> it works.
>
> So, attached is a patch to modify buildconf to generate a 'correct'
> build-rules.mk on win32.
>
> Is this the correct way to do it, or is something wrong in my setup?
That patch should be fine. This is due to Python being a 'true' Win32
build - so it has path delimiters of '\' which the msys make doesn't
accept (I referred to this in my earlier post, FWIW - perhaps too
cryptically though). In a perfect world, we would conditionalize this
mapping to only be done on Win32 too; but it's essentially a no-op on
Unix platforms. So, +1.
BTW, I saw on #apr that you were having an issue with:
/mingw/lib/libmingw32.a(main.o)(.text+0x106):main.c: undefined
reference to `WinMain@16'
This is caused by apr_app.c being pulled in incorrectly (also
mentioned before too). It defines main() and should not be linked
with the APR DLL. We need to teach gen-build to ignore that one file.
(Ideally, we should delete it from the tree, but the test programs
use it and doing so would cause us to have to tweak MSVC++'s build
system and I really don't want to do that...)
Thanks! -- justin
Re: [patch 00/17] successful msys/mingw build
Posted by Paul Querna <ch...@force-elite.com>.
Justin Erenkrantz wrote:
> For the record, here's a quick dump of what I downloaded/installed
> from mingw.sf.net:
> - MinGW 5.0.3
> - MSYS-1.0.11-2004.04-30-1
> - msysDTK-1.0.1
> - msys-autoconf-2.5.9.tar.bz2 (extract to /usr)
> - msys-libtool-1.5.tar.bz2 (extract to /usr)
>
I also needed:
Python-2.5b2 (to run buildconf)
TortoiseSVN
So that I could run buildconf.
Steps:
1) checkout source
2) open msys
3) run buildconf
4) run ./configure with:
--enable-experimental-libtool CFLAGS="-O0"
5) go get a beer (configure is really slow...)
6) run make
Then I ran into problems:
make[1]: Entering directory `/c/work/asf/apr'
/c/work/asf/apr/libtool --silent --mode=compile gcc -O0
-DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE -I./include
-I/c/work/asf/apr/include/arch/win32 -I./include/arch/unix
-I/c/work/asf/apr/include -o passwd\apr_getpass.lo -c
passwd\apr_getpass.c && touch passwd\apr_getpass.lo
gcc.exe: passwdapr_getpass.c: No such file or directory
gcc.exe: no input files
make[1]: *** [passwd\apr_getpass.lo] Error 1
make[1]: Leaving directory `/c/work/asf/apr'
make: *** [all-recursive] Error 1
If I manually changed the libtool line, to use / as path deliminators,
it works.
So, attached is a patch to modify buildconf to generate a 'correct'
build-rules.mk on win32.
Is this the correct way to do it, or is something wrong in my setup?
-Paul