You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@gmail.com> on 2011/03/21 14:58:04 UTC
FYI on "my" MinGW goals
* ensure it is viable to use the MinGW toolchain to build APR on
1.4.x-trunk for the purpose of (at least) me testing simple fixes and
running the test suite and using gcc as another perspective on the
Windows code
* provide at least some help in the area of reviewing/testing to those
willing to do the heavy lifting to make this a properly supported
toolchain
As part of that I anticipate backporting some fixes for MinGW to
1.4.x/1.5.x to support this, but with no implication that any code
line fully/properly supports MinGW. More people will have to continue
to help (and perhaps with it in somewhat better shape it will be more
practical).
Re: FYI on "my" MinGW goals
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/29/2011 11:40 AM, Guenter Knauf wrote:
> Am 28.03.2011 20:24, schrieb Guenter Knauf:
>> and that seems to work - it skips the useless testing for *mingw* and
>> sets the right typedef in apr.h, and the warning is then also gone;
>> but not sure if its the right patch ...
> with this one and all the other recent fixes apr-1.4.x looks now pretty good - only 3
> warnings remain now with misc/win32/start.c;
> I've just build a round with clang to make the issues a bit more clear:
> http://people.apache.org/~fuankg/mingw/build_w32_msys_clang.txt.gz
Cool - will review.
> if whe want to avoid further casts then we probably need to change wchar_t to apr_wchar_t
> - but that cant be done unconditionally because the presense of apr_wchar_t depends on an
> unicode_fs define ...
>
> Bill, are you in the mood to take a look at this?
I don't mind looking at this at all, but it will be a few days before my plate
is clear enough to really dig deeply into it.
> regarding the DLL prob:
> when I look into the created Makefile then I dont see any target for a shared library at
> all - only a target for the static lib exists ...
Probably a side-effect from libtool and our libtool arguments. Which rev?
> also I think the whole stuff with creating export*.c files + arp.exp is nonsense for MingW
> - instead we should build with the proper defines for APR_DECLARE* and just link the DLL
> .. - but unfortunately I am not the right one to fix it this way with my still limited
> configure knowledge :-(
Of course, you realize much of that same garbage is present on win32 builds
(.exp files etc) and we simply need to dodge -installing- these. This is
again probably in part an artifact of various libtool flags, consider that
the compiler, linker, and libtool authors are rarely on the same page and
don't agree on mechanics. The various -export* flags probably affect this.
Re: FYI on "my" MinGW goals
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/29/2011 7:46 PM, Guenter Knauf wrote:
>
> well, there's a huge scope for enhancement as it seems .......
> also our configure is at best 'unusual'; f.e. I have already compiled a couple of things
> successfully on MinGW/MSYS, f.e. such things like bintuils, libcurl, ...; and I did never
> come over any other configure stuff that depends on Python (yet) ...
Point made, but the USER will NEVER do this. They will not invoke
buildconf. It's not unreasonable to expect svn based developers to
do provision this. A lot easier than a whole toolchain.
> also I miss a bit good old times 10 years back with the first httpd 2.0 versions when I
> compiled them on Linux, and just only needed to call ./configure in httpd, and that
> configure found itself apr, and apr found itself apr-util, and all went without manual
> interaction ...
> but seems that these times are gone ...
I think maybe you are raising an httpd issue, then, so perhaps
that's not on topic for this list?
> f.e. when I have:
> base
> /apr
> /apr-util
>
> why the heck cant apr automatically look for and find ../apr-util if it depends on it?
Because apr does not and never did depend on apr-util. apr-util
depends on apr. And we won't be shipping apr-util anymore at 2.0
anyways. So perhaps that's the end of that discussion?
Re: FYI on "my" MinGW goals
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/29/2011 7:46 PM, Guenter Knauf wrote:
> just the minute done a fresh build - at same link:
> http://people.apache.org/~fuankg/mingw/build_w32_cross.txt.gz
Apparently, still --silent
Re: FYI on "my" MinGW goals
Posted by Guenter Knauf <fu...@apache.org>.
Bill,
Am 30.03.2011 02:19, schrieb Guenter Knauf:
> Am 30.03.2011 01:59, schrieb William A. Rowe Jr.:
>> One more thought, I am very curious how your results differ if
>> ./buildconf
>> is done on unix rather than in the wild west universe of mingw.
>>
> pretty much same ...
> http://people.apache.org/~fuankg/mingw/build_w32_cross.txt.gz
> not a recent one (few days back) but same - no DLLs
just the minute done a fresh build - at same link:
http://people.apache.org/~fuankg/mingw/build_w32_cross.txt.gz
and as you can see there now almost all warnings gone, but th eonlyx DDL
build is expat; and that result is 100% same as wih MSYS on Windows ...
seems that those who did the expat configure knew better than those who
did apr/apu ...
well, there's a huge scope for enhancement as it seems .......
also our configure is at best 'unusual'; f.e. I have already compiled a
couple of things successfully on MinGW/MSYS, f.e. such things like
bintuils, libcurl, ...; and I did never come over any other configure
stuff that depends on Python (yet) ...
also I miss a bit good old times 10 years back with the first httpd 2.0
versions when I compiled them on Linux, and just only needed to call
./configure in httpd, and that configure found itself apr, and apr found
itself apr-util, and all went without manual interaction ...
but seems that these times are gone ...
f.e. when I have:
base
/apr
/apr-util
why the heck cant apr automatically look for and find ../apr-util if it
depends on it?
Gün.
Re: FYI on "my" MinGW goals
Posted by Guenter Knauf <fu...@apache.org>.
Am 30.03.2011 01:59, schrieb William A. Rowe Jr.:
> On 3/29/2011 6:56 PM, William A. Rowe Jr. wrote:
>> On 3/29/2011 6:24 PM, Guenter Knauf wrote:
>>> Am 30.03.2011 01:20, schrieb Guenter Knauf:
>>>> Hi,
>>>> Am 30.03.2011 01:14, schrieb William A. Rowe Jr.:
>>>>> 1 error generated.
>>>>>
>>>>> What is *that* about? :)
>>>>>
>>>> un-important;
>>> with un-important I mean here that also with gcc where the includes are fine and
>>> pre-preocessing and compile of export*.c work still no DDL - and no DLL target in Makefile.
>>
>> This bit looks more important;
>>
>> checking if libtool supports shared libraries... yes
>> checking whether to build shared libraries... yes
>> checking whether to build static libraries... yes
>> grep: /home/Administrator/apr/bldapr-1.4.x/libtool: No such file or directory
>
> One more thought, I am very curious how your results differ if ./buildconf
> is done on unix rather than in the wild west universe of mingw.
>
pretty much same ...
http://people.apache.org/~fuankg/mingw/build_w32_cross.txt.gz
not a recent one (few days back) but same - no DLLs
Gün.
Re: FYI on "my" MinGW goals
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/29/2011 6:56 PM, William A. Rowe Jr. wrote:
> On 3/29/2011 6:24 PM, Guenter Knauf wrote:
>> Am 30.03.2011 01:20, schrieb Guenter Knauf:
>>> Hi,
>>> Am 30.03.2011 01:14, schrieb William A. Rowe Jr.:
>>>> 1 error generated.
>>>>
>>>> What is *that* about? :)
>>>>
>>> un-important;
>> with un-important I mean here that also with gcc where the includes are fine and
>> pre-preocessing and compile of export*.c work still no DDL - and no DLL target in Makefile.
>
> This bit looks more important;
>
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... yes
> grep: /home/Administrator/apr/bldapr-1.4.x/libtool: No such file or directory
One more thought, I am very curious how your results differ if ./buildconf
is done on unix rather than in the wild west universe of mingw.
Re: FYI on "my" MinGW goals
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/29/2011 7:54 PM, Guenter Knauf wrote:
> Am 30.03.2011 01:56, schrieb William A. Rowe Jr.:
>> This bit looks more important;
>>
>> checking if libtool supports shared libraries... yes
>> checking whether to build shared libraries... yes
>> checking whether to build static libraries... yes
>> grep: /home/Administrator/apr/bldapr-1.4.x/libtool: No such file or directory
> $ ll bldapr-1.4.x/libtool
> -rwxr-xr-x 1 Administrator Administratoren 289K Mar 29 15:55 bldapr-1.4.x/libtool
>
> so this message seems un-important as well since later on all sources are compiled with
> libtool ...
That grep might possibly be based on manipulating libtool, and since
it didn't exist at the right time, the resulting libtool is incorrect?
Re: FYI on "my" MinGW goals
Posted by Guenter Knauf <fu...@apache.org>.
Am 30.03.2011 01:56, schrieb William A. Rowe Jr.:
> This bit looks more important;
>
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... yes
> grep: /home/Administrator/apr/bldapr-1.4.x/libtool: No such file or directory
$ ll bldapr-1.4.x/libtool
-rwxr-xr-x 1 Administrator Administratoren 289K Mar 29 15:55
bldapr-1.4.x/libtool
so this message seems un-important as well since later on all sources
are compiled with libtool ...
Gün.
Re: FYI on "my" MinGW goals
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/29/2011 6:24 PM, Guenter Knauf wrote:
> Am 30.03.2011 01:20, schrieb Guenter Knauf:
>> Hi,
>> Am 30.03.2011 01:14, schrieb William A. Rowe Jr.:
>>> 1 error generated.
>>>
>>> What is *that* about? :)
>>>
>> un-important;
> with un-important I mean here that also with gcc where the includes are fine and
> pre-preocessing and compile of export*.c work still no DDL - and no DLL target in Makefile.
This bit looks more important;
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
grep: /home/Administrator/apr/bldapr-1.4.x/libtool: No such file or directory
Re: FYI on "my" MinGW goals
Posted by Guenter Knauf <fu...@apache.org>.
Am 30.03.2011 01:20, schrieb Guenter Knauf:
> Hi,
> Am 30.03.2011 01:14, schrieb William A. Rowe Jr.:
>> 1 error generated.
>>
>> What is *that* about? :)
>>
> un-important;
with un-important I mean here that also with gcc where the includes are
fine and pre-preocessing and compile of export*.c work still no DDL -
and no DLL target in Makefile.
Gün.
Re: FYI on "my" MinGW goals
Posted by Guenter Knauf <fu...@apache.org>.
Hi,
Am 30.03.2011 01:14, schrieb William A. Rowe Jr.:
> 1 error generated.
>
> What is *that* about? :)
>
> On the wargs, I believe we are replacing that code; I'm creating a VC10environment for
> validation right now so I can better understand if the proposed fix forenviron allocs
> is going to be the solution to all of the msvcrXXX flavors. Provided it does, I'll get
> that committed very shortly.
un-important; I saw it ans its because my clang installation is probably
wrong; I had to add the mingw includes to CFLAGS, but when export.c is
compiled it does only take CPPFLAGS into sccount - thereofre missing
headers ...
the clang build was just to see the remaining warnings better since
clang is much more verbose than gcc and explains more detailed what goes
wrong ...
Gün.
Re: FYI on "my" MinGW goals
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/29/2011 11:40 AM, Guenter Knauf wrote:
> Am 28.03.2011 20:24, schrieb Guenter Knauf:
>> and that seems to work - it skips the useless testing for *mingw* and
>> sets the right typedef in apr.h, and the warning is then also gone;
>> but not sure if its the right patch ...
> with this one and all the other recent fixes apr-1.4.x looks now pretty good - only 3
> warnings remain now with misc/win32/start.c;
> I've just build a round with clang to make the issues a bit more clear:
> http://people.apache.org/~fuankg/mingw/build_w32_msys_clang.txt.gz
>
> if whe want to avoid further casts then we probably need to change wchar_t to apr_wchar_t
> - but that cant be done unconditionally because the presense of apr_wchar_t depends on an
> unicode_fs define ...
>
> Bill, are you in the mood to take a look at this?
Quick observations...
clang -E -DHAVE_CONFIG_H -DWIN32 -D__MSVCRT__ -D_LARGEFILE64_SOURCE -I./include
-I/home/Administrator/apr/apr-1.4.x/apr/include/arch/win32 -I./include/arch/unix
-I/home/Administrator/apr/apr-1.4.x/apr/include/arch/unix
-I/home/Administrator/apr/apr-1.4.x/apr/include exports.c | grep "ap_hack_" | sed -e
's/^.*[)]\(.*\);$/\1/' >> apr.exp
In file included from exports.c:12:
In file included from
D:/MinGW/msys/1.0/home/Administrator/apr/apr-1.4.x/apr/include/apr_allocator.h:25:
./include/apr.h:150:10: fatal error: 'windows.h' file not found
#include <windows.h>
^
1 error generated.
What is *that* about? :)
On the wargs, I believe we are replacing that code; I'm creating a VC10 environment for
validation right now so I can better understand if the proposed fix for environ allocs
is going to be the solution to all of the msvcrXXX flavors. Provided it does, I'll get
that committed very shortly.
Re: FYI on "my" MinGW goals
Posted by Guenter Knauf <fu...@apache.org>.
Am 28.03.2011 20:24, schrieb Guenter Knauf:
> and that seems to work - it skips the useless testing for *mingw* and
> sets the right typedef in apr.h, and the warning is then also gone;
> but not sure if its the right patch ...
with this one and all the other recent fixes apr-1.4.x looks now pretty
good - only 3 warnings remain now with misc/win32/start.c;
I've just build a round with clang to make the issues a bit more clear:
http://people.apache.org/~fuankg/mingw/build_w32_msys_clang.txt.gz
if whe want to avoid further casts then we probably need to change
wchar_t to apr_wchar_t - but that cant be done unconditionally because
the presense of apr_wchar_t depends on an unicode_fs define ...
Bill, are you in the mood to take a look at this?
regarding the DLL prob:
when I look into the created Makefile then I dont see any target for a
shared library at all - only a target for the static lib exists ...
also I think the whole stuff with creating export*.c files + arp.exp is
nonsense for MingW - instead we should build with the proper defines for
APR_DECLARE* and just link the DLL .. - but unfortunately I am not the
right one to fix it this way with my still limited configure knowledge :-(
Gün.
Re: FYI on "my" MinGW goals
Posted by Guenter Knauf <fu...@apache.org>.
Jeff,
I found another serious prob with MinGW APR ....
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking target system type... i686-pc-mingw32
Configuring APR library
Platform: i686-pc-mingw32
checking for working mkdir -p... yes
APR Version: 1.4.3
.....
checking size of ino_t... 2
configure: using ino_t for ino_t
argh!! And later of course:
D:/MinGW/msys/1.0/home/Administrator/apr/apr-1.4.x/apr/file_io/win32/filestat.c:
In function 'apr_file_info_get':
D:/MinGW/msys/1.0/home/Administrator/apr/apr-1.4.x/apr/file_io/win32/filestat.c:466:19:
warning: left shift count >= width of type
and in apr.h I find:
typedef ino_t apr_ino_t;
this should be an unsigned __int64 -> apr.hw has:
typedef apr_uint64_t apr_ino_t;
configure.in has at line 1845:
ino_t_value=ino_t
APR_CHECK_SIZEOF_EXTENDED(AC_INCLUDES_DEFAULT, ino_t, $ac_cv_sizeof_long)
if test $ac_cv_sizeof_ino_t = 4; then
if test $ac_cv_sizeof_long = 4; then
ino_t_value="unsigned long"
else
ino_t_value="unsigned int"
fi
fi
AC_MSG_NOTICE([using $ino_t_value for ino_t])
how can we properly convince configure to use a 64-bit for MinGW here?
I've hacked this:
Index: apr/branches/1.4.x/configure.in
===================================================================
--- apr/branches/1.4.x/configure.in (Revision 1085987)
+++ apr/branches/1.4.x/configure.in (Arbeitskopie)
@@ -1842,15 +1842,24 @@
# releases did. To be correct, apr_ino_t should have been made an
# ino64_t as apr_off_t is off64_t, but this can't be done now without
# breaking ABI.
-ino_t_value=ino_t
-APR_CHECK_SIZEOF_EXTENDED(AC_INCLUDES_DEFAULT, ino_t, $ac_cv_sizeof_long)
-if test $ac_cv_sizeof_ino_t = 4; then
- if test $ac_cv_sizeof_long = 4; then
- ino_t_value="unsigned long"
- else
- ino_t_value="unsigned int"
+
+# Per OS tuning...
+case $host in
+*mingw*)
+ ino_t_value=apr_int64_t
+ ;;
+*)
+ ino_t_value=ino_t
+ APR_CHECK_SIZEOF_EXTENDED(AC_INCLUDES_DEFAULT, ino_t,
$ac_cv_sizeof_long)
+ if test $ac_cv_sizeof_ino_t = 4; then
+ if test $ac_cv_sizeof_long = 4; then
+ ino_t_value="unsigned long"
+ else
+ ino_t_value="unsigned int"
+ fi
fi
-fi
+ ;;
+esac
AC_MSG_NOTICE([using $ino_t_value for ino_t])
# Checks for endianness
and that seems to work - it skips the useless testing for *mingw* and
sets the right typedef in apr.h, and the warning is then also gone;
but not sure if its the right patch ...
Gün.
Re: FYI on "my" MinGW goals
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Mar 21, 2011 at 1:29 PM, Guenter Knauf <fu...@apache.org> wrote:
> Jeff,
> Am 21.03.2011 14:58, schrieb Jeff Trawick:
>>
>> * ensure it is viable to use the MinGW toolchain to build APR on
>> 1.4.x-trunk for the purpose of (at least) me testing simple fixes and
>> running the test suite and using gcc as another perspective on the
>> Windows code
>> * provide at least some help in the area of reviewing/testing to those
>> willing to do the heavy lifting to make this a properly supported
>> toolchain
>>
>> As part of that I anticipate backporting some fixes for MinGW to
>> 1.4.x/1.5.x to support this, but with no implication that any code
>> line fully/properly supports MinGW. More people will have to continue
>> to help (and perhaps with it in somewhat better shape it will be more
>> practical).
>
> how do you call configure? Separately in apr / apr-util, or in apr with some
> params?
>
> when I do it separately in apr-util I still get:
>
> Looking for apr source in /home/Administrator/apr-1.4.x/apr
> Creating include/private/apu_config.h ...
> Creating configure ...
> Generating 'make' outputs ...
> Traceback (most recent call last):
> File
> "D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py",
> line 230, in <module>
> main()
> File
> "D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py",
> line 135, in main
> objects, _unused = write_objects(f, legal_deps, h_deps, files)
> File
> "D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py",
> line 172, in write_objects
> assert file[-2:] == '.c'
> AssertionError
sadly this had to be debugged again though it was fixed in trunk :(
see r1084287 (1.3.x)
Re: FYI on "my" MinGW goals
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Mar 21, 2011 at 5:23 PM, Guenter Knauf <fu...@apache.org> wrote:
> Am 21.03.2011 20:51, schrieb Jeff Trawick:
>>
>> On Mon, Mar 21, 2011 at 3:12 PM, William A. Rowe Jr.
>> <wr...@rowe-clan.net> wrote:
>>>
>>> On 3/21/2011 12:56 PM, Jeff Trawick wrote:
>>>>
>>>> apr 1.4 doesn't link for me (undefined reference to CreateHardLinkW),
>>>
>>> That's odd, it's in kernel32.dll. A broken kernel32.dll.a/kernel32.lib
>>> file,
>>> perhaps?
>>>
>>
>> part of it was a missing define to say we're on NT>= some value (a
>> commit from you ~1.5 years ago); without it, we skip over the defs in
>> winbase.h)
>>
>> that may be all, but it is mixed in with a bunch of other backports to
>> 1.4.x
>>
> I wonder how you convince APR to link DLLs at all - for me that doesnt work,
> I only get a static lib ...
I don't get DLLs. Check recent activity for bug 46175 for an update about that.
> what version are you using? I tried with relative new one:
> $ msysinfo
> msysinfo-1.3: Send this to the MSYS support list:
>
> MSYS 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 unknown; targ=MINGW32
> GNU bash, version 3.1.17(1)-release (i686-pc-msys); ENV=.profile
> GNU Make 3.81This program built for i686-pc-msys; MAKE_MODE=unix
> gcc.exe (GCC) 4.5.2; targ=MINGW32
I have those versions.
>
> and also with mingw32-cross on SuSE 11.1 Linux:
> $ i686-pc-mingw32-gcc -v
> Using built-in specs.
> Target: i686-pc-mingw32
> Configured with: ../configure --prefix=/usr --bindir=/usr/bin
> --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib64
> --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
> --build=x86_64-suse-linux-gnu --host=x86_64-suse-linux-gnu
> --target=i686-pc-mingw32 --with-gnu-as --with-gnu-ld --verbose
> --without-newlib --disable-multilib --with-system-zlib --disable-nls
> --without-included-gettext --disable-win32-registry
> --enable-version-specific-runtime-libs
> --with-sysroot=/usr/i686-pc-mingw32/sys-root
> --enable-languages=c,c++,java,fortran,objc,obj-c++ --enable-libgcj
> --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug
> --enable-hash-synchronization
> Thread model: win32
> gcc version 4.3.3 (GCC)
>
> the build logs look similar, and both build no DLLs ...
> here are the build logs and the script I used:
> http://people.apache.org/~fuankg/mingw/
>
> Gün.
Re: FYI on "my" MinGW goals
Posted by Guenter Knauf <fu...@apache.org>.
Am 21.03.2011 20:51, schrieb Jeff Trawick:
> On Mon, Mar 21, 2011 at 3:12 PM, William A. Rowe Jr.
> <wr...@rowe-clan.net> wrote:
>> On 3/21/2011 12:56 PM, Jeff Trawick wrote:
>>>
>>> apr 1.4 doesn't link for me (undefined reference to CreateHardLinkW),
>>
>> That's odd, it's in kernel32.dll. A broken kernel32.dll.a/kernel32.lib file,
>> perhaps?
>>
>
> part of it was a missing define to say we're on NT>= some value (a
> commit from you ~1.5 years ago); without it, we skip over the defs in
> winbase.h)
>
> that may be all, but it is mixed in with a bunch of other backports to 1.4.x
>
I wonder how you convince APR to link DLLs at all - for me that doesnt
work, I only get a static lib ...
what version are you using? I tried with relative new one:
$ msysinfo
msysinfo-1.3: Send this to the MSYS support list:
MSYS 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 unknown; targ=MINGW32
GNU bash, version 3.1.17(1)-release (i686-pc-msys); ENV=.profile
GNU Make 3.81This program built for i686-pc-msys; MAKE_MODE=unix
gcc.exe (GCC) 4.5.2; targ=MINGW32
and also with mingw32-cross on SuSE 11.1 Linux:
$ i686-pc-mingw32-gcc -v
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin
--includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib64
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--build=x86_64-suse-linux-gnu --host=x86_64-suse-linux-gnu
--target=i686-pc-mingw32 --with-gnu-as --with-gnu-ld --verbose
--without-newlib --disable-multilib --with-system-zlib --disable-nls
--without-included-gettext --disable-win32-registry
--enable-version-specific-runtime-libs
--with-sysroot=/usr/i686-pc-mingw32/sys-root
--enable-languages=c,c++,java,fortran,objc,obj-c++ --enable-libgcj
--disable-java-awt --without-x --enable-java-gc=boehm
--disable-libgcj-debug --enable-hash-synchronization
Thread model: win32
gcc version 4.3.3 (GCC)
the build logs look similar, and both build no DLLs ...
here are the build logs and the script I used:
http://people.apache.org/~fuankg/mingw/
Gün.
Re: FYI on "my" MinGW goals
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Mar 21, 2011 at 3:12 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 3/21/2011 12:56 PM, Jeff Trawick wrote:
>>
>> apr 1.4 doesn't link for me (undefined reference to CreateHardLinkW),
>
> That's odd, it's in kernel32.dll. A broken kernel32.dll.a/kernel32.lib file,
> perhaps?
>
part of it was a missing define to say we're on NT >= some value (a
commit from you ~1.5 years ago); without it, we skip over the defs in
winbase.h)
that may be all, but it is mixed in with a bunch of other backports to 1.4.x
Re: FYI on "my" MinGW goals
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/21/2011 12:56 PM, Jeff Trawick wrote:
>
> apr 1.4 doesn't link for me (undefined reference to CreateHardLinkW),
That's odd, it's in kernel32.dll. A broken kernel32.dll.a/kernel32.lib file,
perhaps?
Re: FYI on "my" MinGW goals
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Mar 21, 2011 at 1:29 PM, Guenter Knauf <fu...@apache.org> wrote:
> Jeff,
> Am 21.03.2011 14:58, schrieb Jeff Trawick:
>>
>> * ensure it is viable to use the MinGW toolchain to build APR on
>> 1.4.x-trunk for the purpose of (at least) me testing simple fixes and
>> running the test suite and using gcc as another perspective on the
>> Windows code
>> * provide at least some help in the area of reviewing/testing to those
>> willing to do the heavy lifting to make this a properly supported
>> toolchain
>>
>> As part of that I anticipate backporting some fixes for MinGW to
>> 1.4.x/1.5.x to support this, but with no implication that any code
>> line fully/properly supports MinGW. More people will have to continue
>> to help (and perhaps with it in somewhat better shape it will be more
>> practical).
>
> how do you call configure? Separately in apr / apr-util, or in apr with some
> params?
apr trunk:
make extraclean ; ./buildconf && ./configure --prefix=/c/Users/Trawick/aprinst
--without-iconv --with-expat=/c/MinGW --enable-maintainer-mode >cfgout
2>&1 && ma
ke 2>stderr && (cd test && make 2>>../stderr) ; cat stderr
apr-1.4.x:
similar, but no "--without-iconv" or "--with-expat"
apr 1.4 doesn't link for me (undefined reference to CreateHardLinkW),
and I haven't tried apr-util yet
>
> when I do it separately in apr-util I still get:
hopefully I'll get that far before long
>
> Looking for apr source in /home/Administrator/apr-1.4.x/apr
> Creating include/private/apu_config.h ...
> Creating configure ...
> Generating 'make' outputs ...
> Traceback (most recent call last):
> File
> "D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py",
> line 230, in <module>
> main()
> File
> "D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py",
> line 135, in main
> objects, _unused = write_objects(f, legal_deps, h_deps, files)
> File
> "D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py",
> line 172, in write_objects
> assert file[-2:] == '.c'
> AssertionError
>
> this is the same prob which I posted some days back already ...
> the assertion happens because the loop gets 2 times an empty value ...
> I think I could fix that with copying the whole autostuff from apr-HEAD into
> apr-1.4.x (though not sure, its been soem days, and was then otherwise
> busy).
>
> Gün.
Re: FYI on "my" MinGW goals
Posted by Guenter Knauf <fu...@apache.org>.
Jeff,
Am 21.03.2011 14:58, schrieb Jeff Trawick:
> * ensure it is viable to use the MinGW toolchain to build APR on
> 1.4.x-trunk for the purpose of (at least) me testing simple fixes and
> running the test suite and using gcc as another perspective on the
> Windows code
> * provide at least some help in the area of reviewing/testing to those
> willing to do the heavy lifting to make this a properly supported
> toolchain
>
> As part of that I anticipate backporting some fixes for MinGW to
> 1.4.x/1.5.x to support this, but with no implication that any code
> line fully/properly supports MinGW. More people will have to continue
> to help (and perhaps with it in somewhat better shape it will be more
> practical).
how do you call configure? Separately in apr / apr-util, or in apr with
some params?
when I do it separately in apr-util I still get:
Looking for apr source in /home/Administrator/apr-1.4.x/apr
Creating include/private/apu_config.h ...
Creating configure ...
Generating 'make' outputs ...
Traceback (most recent call last):
File
"D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py",
line 230, in <module>
main()
File
"D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py",
line 135, in main
objects, _unused = write_objects(f, legal_deps, h_deps, files)
File
"D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py",
line 172, in write_objects
assert file[-2:] == '.c'
AssertionError
this is the same prob which I posted some days back already ...
the assertion happens because the loop gets 2 times an empty value ...
I think I could fix that with copying the whole autostuff from apr-HEAD
into apr-1.4.x (though not sure, its been soem days, and was then
otherwise busy).
Gün.