You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Bob Rossi <bo...@cox.net> on 2006/12/02 04:10:39 UTC
building apr on cygwin for mingw
Hi,
I'm having trouble subscribing to dev-subscribe@apr.apache.org. I've
sent a half dozen subscribe emails, and haven't been added yet.
(over several days) I've also sent emails to dev-help@apr.apache.org,
and have received no response. Could someone please add me to this
mailing list?
I've successfully cross compiled apr on cygwin to mingw. I've already
had one patch go upstream to autoconf, which fixes a problem
AC_CHECK_SIZEOF.
I have two very small other problems, that need to be sent upstream, and
then trunk should work out of the box.
First, and oddly enough, the buildconf script fails for me because
build/buildcheck.sh doesn't recognize my libtool --version. I don't know
sed well enough, and thought someone here would quickly be able to spot
the problem. If not, I'll have to look deeper.
$ libtool --version 2>/dev/null
ltmain.sh (GNU libtool) 1.5.23a (1.1220.2.412 2006/10/13 14:13:30)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This command is failing by giving me no output.
$ libtool --version 2>/dev/null|sed -e 's/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q'
So, I changed it to
$ libtool --version 2>/dev/null|sed -e 's/([^)]*)//g;s/^[^0-9]*//;'
and it worked, but I don't think that is the correct fix. Any ideas?
Secondly, the APR_CHECK_SIZEOF_EXTENDED isn't working for me because the
default for the cross compiled size is 8. However, ssize_t for me is 4.
So, the configure fails. I made this change:
-APR_CHECK_SIZEOF_EXTENDED([#include <sys/types.h>], ssize_t, 8)
+AC_CHECK_SIZEOF([ssize_t], [#include <stdio.h>
+#include <sys/types.h>])
and things work nicely. Would a patch like this be acceptable? There are
5 changes I made just like this. Finally, the macro
APR_CHECK_SIZEOF_EXTENDED could probably be removed.
So, after patching autoconf, and making these two patches to apr, I was
able to cross compile on cygwin with this command,
./configure apr_cv_tcp_nodelay_with_cork=no ac_cv_func_setpgrp_void=yes
ac_cv_file__dev_zero=no --build=i686-pc-cygwin --host=i686-pc-mingw32
CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin'
I was able to take a sample program, and run it on a machine that did
not have cygwin installed, and it ran fine. It was simply a hello world
type program with apr stuff in it.
I would really appreciate if these thoughts could be considered, so I
could create a patch to send upstream.
Thanks,
Bob Rossi
Re: building apr on cygwin for mingw
Posted by John Vandenberg <ja...@gmail.com>.
On 12/6/06, Bob Rossi <bo...@cox.net> wrote:
> On Tue, Dec 05, 2006 at 12:34:36PM +0000, Joe Orton wrote:
> > On Fri, Dec 01, 2006 at 10:10:39PM -0500, Bob Rossi wrote:
> > > Secondly, the APR_CHECK_SIZEOF_EXTENDED isn't working for me because the
> > > default for the cross compiled size is 8. However, ssize_t for me is 4.
> > > So, the configure fails. I made this change:
> >
> > Can't you set ac_cv_sizeof_ssize_t=4 to get round that?
>
> Yup, but that's not going to work when I upgrade my compiler, or
> something else changes. The point is, I'm in an environment where the
> host program can run, and tell me exactly what the size is.
Sounds like you are expecting autoconf to check whether it can execute
cross-compiled binaries on the build platform. I wasnt able to find
any HOWTOs for this, but it does seem reasonable as many unix flavours
can now run linux binaries, and linux can run windows binaries.
--
John
Re: building apr on cygwin for mingw
Posted by Bob Rossi <bo...@cox.net>.
On Tue, Dec 05, 2006 at 12:34:36PM +0000, Joe Orton wrote:
> On Fri, Dec 01, 2006 at 10:10:39PM -0500, Bob Rossi wrote:
> > Secondly, the APR_CHECK_SIZEOF_EXTENDED isn't working for me because the
> > default for the cross compiled size is 8. However, ssize_t for me is 4.
> > So, the configure fails. I made this change:
>
> Can't you set ac_cv_sizeof_ssize_t=4 to get round that?
Yup, but that's not going to work when I upgrade my compiler, or
something else changes. The point is, I'm in an environment where the
host program can run, and tell me exactly what the size is.
Thanks,
Bob Rossi
Re: building apr on cygwin for mingw
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Dec 01, 2006 at 10:10:39PM -0500, Bob Rossi wrote:
> Secondly, the APR_CHECK_SIZEOF_EXTENDED isn't working for me because the
> default for the cross compiled size is 8. However, ssize_t for me is 4.
> So, the configure fails. I made this change:
Can't you set ac_cv_sizeof_ssize_t=4 to get round that?
Regards,
joe
Re: building apr on cygwin for mingw
Posted by John Vandenberg <ja...@gmail.com>.
On 12/12/06, Bob Rossi <bo...@cox.net> wrote:
> On Sun, Dec 10, 2006 at 08:42:29PM +1100, John Vandenberg wrote:
> > On 12/9/06, Bob Rossi <bo...@cox.net> wrote:
> > >On Wed, Dec 06, 2006 at 09:07:20AM +1100, John Vandenberg wrote:
> > >> We should first check whether the libtool developers intentionally
> > >> added that blank line; if they can fix the regression on their side,
> > >> it means that the next stable version of libtool will work with older
> > >> source tarballs of apr.
> > >
> > >Was i supposed to do this?
> >
> > Ralf Wildenhues has removed the offending blank line from libtool.
>
> Thanks John, for getting that done. Should I wait for the next release
> of libtool to come out, or is the regex going to be modified?
libtool 1.5.23a is an alpha release, so this problem has never made it
out into the wild, thanks to your bug report. Personally, I dont
think the sed expression in the APR needs to change -- it could be
more permissive, but I pretty sure that we wont be seeing libtool emit
a leading blank line for a very long time -- next time it will be some
other minor unintentional change, and its hard to predict what it will
be.
Did you end up with libtool 1.5.23a by doing a standard cygwin
install, or did you specifically select that version?
If it was automagically selected for you, then my guess is that
another cygwin package you installed depended on that alpha release of
libtool, and I would recommend that you discuss this with the cygwin
list.
If you specifically selected version 1.5.23a, consider rolling back to 1.5.22
Alternatively, you could "fix" the current alpha version of libtool
you have installed: edit /usr/bin/libtool and remove the blank line
(around line 838) that caused this glitch.
--
John
Re: building apr on cygwin for mingw
Posted by Bob Rossi <bo...@cox.net>.
On Sun, Dec 10, 2006 at 08:42:29PM +1100, John Vandenberg wrote:
> On 12/9/06, Bob Rossi <bo...@cox.net> wrote:
> >On Wed, Dec 06, 2006 at 09:07:20AM +1100, John Vandenberg wrote:
> >> We should first check whether the libtool developers intentionally
> >> added that blank line; if they can fix the regression on their side,
> >> it means that the next stable version of libtool will work with older
> >> source tarballs of apr.
> >
> >Was i supposed to do this?
>
> Ralf Wildenhues has removed the offending blank line from libtool.
Thanks John, for getting that done. Should I wait for the next release
of libtool to come out, or is the regex going to be modified?
Thanks,
Bob Rossi
Re: building apr on cygwin for mingw
Posted by John Vandenberg <ja...@gmail.com>.
On 12/9/06, Bob Rossi <bo...@cox.net> wrote:
> On Wed, Dec 06, 2006 at 09:07:20AM +1100, John Vandenberg wrote:
> > We should first check whether the libtool developers intentionally
> > added that blank line; if they can fix the regression on their side,
> > it means that the next stable version of libtool will work with older
> > source tarballs of apr.
>
> Was i supposed to do this?
Ralf Wildenhues has removed the offending blank line from libtool.
--
John
Re: building apr on cygwin for mingw
Posted by Bob Rossi <bo...@cox.net>.
On Wed, Dec 06, 2006 at 09:07:20AM +1100, John Vandenberg wrote:
> We should first check whether the libtool developers intentionally
> added that blank line; if they can fix the regression on their side,
> it means that the next stable version of libtool will work with older
> source tarballs of apr.
Was i supposed to do this?
Thanks,
Bob Rossi
Re: building apr on cygwin for mingw
Posted by John Vandenberg <ja...@gmail.com>.
On 12/6/06, Bob Rossi <bo...@cox.net> wrote:
> On Wed, Dec 06, 2006 at 08:30:55AM +1100, John Vandenberg wrote:
> > The problem appears to be that libtool is now emitting a blank line
> > before the line that contains the version string; try
> >
> > $ libtool --version 2>/dev/null | sed -e
> > '/^$/d;s/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q'
>
> Works like a charm.
>
> $ libtool --version 2>/dev/null | sed -e
> '/^$/d;s/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q'
> 1.5.23a
I have grabbed a copy of libtool-1.5.22 and 1.5.23a. I can confirm
that 1.5.23a is emitting a blank line first, while 1.5.22 does not.
Sounds like a bug in their development builds.
> > >> >So, after patching autoconf, and making these two patches to apr, I was
> > >> >able to cross compile on cygwin with this command,
> > >> >
> > >> > ./configure apr_cv_tcp_nodelay_with_cork=no
> > >ac_cv_func_setpgrp_void=yes
> > >> > ac_cv_file__dev_zero=no --build=i686-pc-cygwin --host=i686-pc-mingw32
> > >> > CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin'
> > >> >
> > >> >I was able to take a sample program, and run it on a machine that did
> > >> >not have cygwin installed, and it ran fine. It was simply a hello world
> > >> >type program with apr stuff in it.
> > >>
> > >> Have you tried the test suite?
> > >
> > >Nope, great idea. Attached is the results. I'm going to try a native
> > >build of mingw to make sure the results are the same. How do these
> > >results look?
> >
> > They look comparable to the last msys/MinGW test results I have seen.
> >
> > http://marc2.theaimsgroup.com/?l=apr-dev&m=114506483217503&w=2
>
> Intereseting. So everything appears to be correct? For some reason,
> testsock works now, and it didn't before.
Great! Hopefully in another few months testdso will also start
working correctly :-)
> I'd love to see the sed command go into apr.
We should first check whether the libtool developers intentionally
added that blank line; if they can fix the regression on their side,
it means that the next stable version of libtool will work with older
source tarballs of apr.
--
John
Re: building apr on cygwin for mingw
Posted by Bob Rossi <bo...@cox.net>.
On Wed, Dec 06, 2006 at 08:30:55AM +1100, John Vandenberg wrote:
> The problem appears to be that libtool is now emitting a blank line
> before the line that contains the version string; try
>
> $ libtool --version 2>/dev/null | sed -e
> '/^$/d;s/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q'
Works like a charm.
$ libtool --version 2>/dev/null | sed -e
'/^$/d;s/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q'
1.5.23a
> >> >So, after patching autoconf, and making these two patches to apr, I was
> >> >able to cross compile on cygwin with this command,
> >> >
> >> > ./configure apr_cv_tcp_nodelay_with_cork=no
> >ac_cv_func_setpgrp_void=yes
> >> > ac_cv_file__dev_zero=no --build=i686-pc-cygwin --host=i686-pc-mingw32
> >> > CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin'
> >> >
> >> >I was able to take a sample program, and run it on a machine that did
> >> >not have cygwin installed, and it ran fine. It was simply a hello world
> >> >type program with apr stuff in it.
> >>
> >> Have you tried the test suite?
> >
> >Nope, great idea. Attached is the results. I'm going to try a native
> >build of mingw to make sure the results are the same. How do these
> >results look?
>
> They look comparable to the last msys/MinGW test results I have seen.
>
> http://marc2.theaimsgroup.com/?l=apr-dev&m=114506483217503&w=2
Intereseting. So everything appears to be correct? For some reason,
testsock works now, and it didn't before.
I'd love to see the sed command go into apr. I'm still wondering what
should be done about the m4 macros.
Thanks,
Bob Rossi
Re: building apr on cygwin for mingw
Posted by John Vandenberg <ja...@gmail.com>.
On 12/6/06, Bob Rossi <bo...@cox.net> wrote:
> On Tue, Dec 05, 2006 at 10:16:52AM +1100, John Vandenberg wrote:
> > Hi Bob,
> >
> > On 12/2/06, Bob Rossi <bo...@cox.net> wrote:
> >
> > >First, and oddly enough, the buildconf script fails for me because
> > >build/buildcheck.sh doesn't recognize my libtool --version. I don't know
> > >sed well enough, and thought someone here would quickly be able to spot
> > >the problem. If not, I'll have to look deeper.
> > >
> > > $ libtool --version 2>/dev/null
> > >
> > > ltmain.sh (GNU libtool) 1.5.23a (1.1220.2.412 2006/10/13 14:13:30)
> > >
> > > Copyright (C) 2006 Free Software Foundation, Inc.
> > > This is free software; see the source for copying conditions. There is
> > > NO
> > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > > PURPOSE.
> > >
> > >This command is failing by giving me no output.
> > > $ libtool --version 2>/dev/null|sed -e 's/([^)]*)//g;s/^[^0-9]*//;s/[-
> > > ].*//g;q'
> >
> > The following worked for me on Fedora Core 3, MSYS (MINGW32_NT-5.1 -
> > 1.0.11), and Cygwin (CYGWIN_NT-5.1 - 1.5.18):
> >
> > $ cat <<EOF | sed -e 's/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q'
> > > ltmain.sh (GNU libtool) 1.5.23a (1.1220.2.412 2006/10/13 14:13:30)
> > >
> > > Copyright (C) 2006 Free Software Foundation, Inc.
> > > This is free software; see the source for copying conditions. There is NO
> > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > > PURPOSE.
> > >EOF
> > 1.5.23a
> >
> > Could you let us know which version of sed you are using.
>
> $ sed --version
> GNU sed version 4.1.5
>
> That's on Cygwin of course.
The problem appears to be that libtool is now emitting a blank line
before the line that contains the version string; try
$ libtool --version 2>/dev/null | sed -e
'/^$/d;s/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q'
> > >So, after patching autoconf, and making these two patches to apr, I was
> > >able to cross compile on cygwin with this command,
> > >
> > > ./configure apr_cv_tcp_nodelay_with_cork=no ac_cv_func_setpgrp_void=yes
> > > ac_cv_file__dev_zero=no --build=i686-pc-cygwin --host=i686-pc-mingw32
> > > CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin'
> > >
> > >I was able to take a sample program, and run it on a machine that did
> > >not have cygwin installed, and it ran fine. It was simply a hello world
> > >type program with apr stuff in it.
> >
> > Have you tried the test suite?
>
> Nope, great idea. Attached is the results. I'm going to try a native
> build of mingw to make sure the results are the same. How do these
> results look?
They look comparable to the last msys/MinGW test results I have seen.
http://marc2.theaimsgroup.com/?l=apr-dev&m=114506483217503&w=2
--
John
Re: building apr on cygwin for mingw
Posted by Bob Rossi <bo...@cox.net>.
On Tue, Dec 05, 2006 at 02:55:09PM -0600, William A. Rowe, Jr. wrote:
> > Failed Tests Total Fail Failed %
> > ===================================================
> > testdso 5 4 80.00%
> > testpipe 9 2 22.22%
>
> testpipe errors are expected. Filesystem pipes on windows do not behave
> in a socket-compatible, select()able manner.
>
> testdso is another story - perhaps it believes it's using the dlxxx flavor
> instead of windows, and some common code it causing it to throw up?
When I compile apr nativly, with mingw, I get the same test results.
Failed Tests Total Fail Failed %
===================================================
testdso 5 4 80.00%
testpipe 9 2 22.22%
make[1]: Leaving directory `/home/kelli/apr/apr/test'
Is this a regression in apr svn trunk?
Also, if I used cl to compile apr, would that make more tests pass? For
example, does cl somehow have more capabilities on windows than mingw?
Thanks,
Bob Rossi
Re: building apr on cygwin for mingw
Posted by Bob Rossi <bo...@cox.net>.
On Tue, Dec 05, 2006 at 03:35:21PM -0600, William A. Rowe, Jr. wrote:
> Bob Rossi wrote:
> > Hi,
> >
> > Well, here is the compile command.
> >
> > /bin/sh
> > /home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/libtool
> > --silent --mode=compile gcc -mno-cygwin -g -O0 -DHAVE_CONFIG_H
> > -D_LARGEFILE64_SOURCE -I./include
> > -I/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/include/arch/win32
> > -I./include/arch/unix
> > -I/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/include
> > -o dso/win32/dso.lo -c dso/win32/dso.c && touch dso/win32/dso.lo
> >
> > And yes,
> > #define APR_HAS_DSO 1
>
> Beauty. If you can share the backtrace (you said it crashed, no?) this
> too might be helpful.
It raised an assertion.
Assertion failed: rv == APR_SUCCESS, file testmutexscope.c, line 168
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Would you still like a backtrace? Can one typically get that for apr
using GDB using the standard techniques? ie. (r, bt)
Thanks,
Bob Rossi
Re: building apr on cygwin for mingw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Bob Rossi wrote:
> Hi,
>
> Well, here is the compile command.
>
> /bin/sh
> /home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/libtool
> --silent --mode=compile gcc -mno-cygwin -g -O0 -DHAVE_CONFIG_H
> -D_LARGEFILE64_SOURCE -I./include
> -I/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/include/arch/win32
> -I./include/arch/unix
> -I/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/include
> -o dso/win32/dso.lo -c dso/win32/dso.c && touch dso/win32/dso.lo
>
> And yes,
> #define APR_HAS_DSO 1
Beauty. If you can share the backtrace (you said it crashed, no?) this
too might be helpful.
Re: building apr on cygwin for mingw
Posted by Bob Rossi <bo...@cox.net>.
Hi,
Well, here is the compile command.
/bin/sh
/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/libtool
--silent --mode=compile gcc -mno-cygwin -g -O0 -DHAVE_CONFIG_H
-D_LARGEFILE64_SOURCE -I./include
-I/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/include/arch/win32
-I./include/arch/unix
-I/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/include
-o dso/win32/dso.lo -c dso/win32/dso.c && touch dso/win32/dso.lo
And yes,
#define APR_HAS_DSO 1
Thanks,
Bob Rossi
On Tue, Dec 05, 2006 at 03:11:30PM -0600, William A. Rowe, Jr. wrote:
> If you force dlopen and dlsym to 0, see what happens.
>
> dso/win32/dso.c, is the source we should be compiling, not the
> dso/unix/dso.c. Can you check that?
>
> Bob Rossi wrote:
> > On Tue, Dec 05, 2006 at 02:55:09PM -0600, William A. Rowe, Jr. wrote:
> >>> Failed Tests Total Fail Failed %
> >>> ===================================================
> >>> testdso 5 4 80.00%
> >>> testpipe 9 2 22.22%
> >> testpipe errors are expected. Filesystem pipes on windows do not behave
> >> in a socket-compatible, select()able manner.
> >>
> >> testdso is another story - perhaps it believes it's using the dlxxx flavor
> >> instead of windows, and some common code it causing it to throw up?
> >
> > Thanks for the quick response. This is the output of my configure run.
> > Is something obviously wrong here?
> >
> > Checking for DSO...
> > checking for NSLinkModule... no
> > checking for shl_load in -ldld... no
> > checking for dlopen... no
> > checking for dlopen in -ldl... yes
> > adding "-ldl" to LIBS
> > checking for dlsym... yes
> >
> > Thanks,
> > Bob Rossi
> >
Re: building apr on cygwin for mingw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
If you force dlopen and dlsym to 0, see what happens.
dso/win32/dso.c, is the source we should be compiling, not the
dso/unix/dso.c. Can you check that?
Bob Rossi wrote:
> On Tue, Dec 05, 2006 at 02:55:09PM -0600, William A. Rowe, Jr. wrote:
>>> Failed Tests Total Fail Failed %
>>> ===================================================
>>> testdso 5 4 80.00%
>>> testpipe 9 2 22.22%
>> testpipe errors are expected. Filesystem pipes on windows do not behave
>> in a socket-compatible, select()able manner.
>>
>> testdso is another story - perhaps it believes it's using the dlxxx flavor
>> instead of windows, and some common code it causing it to throw up?
>
> Thanks for the quick response. This is the output of my configure run.
> Is something obviously wrong here?
>
> Checking for DSO...
> checking for NSLinkModule... no
> checking for shl_load in -ldld... no
> checking for dlopen... no
> checking for dlopen in -ldl... yes
> adding "-ldl" to LIBS
> checking for dlsym... yes
>
> Thanks,
> Bob Rossi
>
Re: building apr on cygwin for mingw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Bob Rossi wrote:
>
> Thanks for the quick response. This is the output of my configure run.
> Is something obviously wrong here?
also - check that APR_HAS_DSO is 1.
Re: building apr on cygwin for mingw
Posted by Bob Rossi <bo...@cox.net>.
On Tue, Dec 05, 2006 at 02:55:09PM -0600, William A. Rowe, Jr. wrote:
> > Failed Tests Total Fail Failed %
> > ===================================================
> > testdso 5 4 80.00%
> > testpipe 9 2 22.22%
>
> testpipe errors are expected. Filesystem pipes on windows do not behave
> in a socket-compatible, select()able manner.
>
> testdso is another story - perhaps it believes it's using the dlxxx flavor
> instead of windows, and some common code it causing it to throw up?
Thanks for the quick response. This is the output of my configure run.
Is something obviously wrong here?
Checking for DSO...
checking for NSLinkModule... no
checking for shl_load in -ldld... no
checking for dlopen... no
checking for dlopen in -ldl... yes
adding "-ldl" to LIBS
checking for dlsym... yes
Thanks,
Bob Rossi
Re: building apr on cygwin for mingw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> Failed Tests Total Fail Failed %
> ===================================================
> testdso 5 4 80.00%
> testpipe 9 2 22.22%
testpipe errors are expected. Filesystem pipes on windows do not behave
in a socket-compatible, select()able manner.
testdso is another story - perhaps it believes it's using the dlxxx flavor
instead of windows, and some common code it causing it to throw up?
Re: building apr on cygwin for mingw
Posted by Bob Rossi <bo...@cox.net>.
On Tue, Dec 05, 2006 at 10:16:52AM +1100, John Vandenberg wrote:
> Hi Bob,
>
> On 12/2/06, Bob Rossi <bo...@cox.net> wrote:
>
> >First, and oddly enough, the buildconf script fails for me because
> >build/buildcheck.sh doesn't recognize my libtool --version. I don't know
> >sed well enough, and thought someone here would quickly be able to spot
> >the problem. If not, I'll have to look deeper.
> >
> > $ libtool --version 2>/dev/null
> >
> > ltmain.sh (GNU libtool) 1.5.23a (1.1220.2.412 2006/10/13 14:13:30)
> >
> > Copyright (C) 2006 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions. There is
> > NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
> >
> >This command is failing by giving me no output.
> > $ libtool --version 2>/dev/null|sed -e 's/([^)]*)//g;s/^[^0-9]*//;s/[-
> > ].*//g;q'
>
> The following worked for me on Fedora Core 3, MSYS (MINGW32_NT-5.1 -
> 1.0.11), and Cygwin (CYGWIN_NT-5.1 - 1.5.18):
>
> $ cat <<EOF | sed -e 's/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q'
> > ltmain.sh (GNU libtool) 1.5.23a (1.1220.2.412 2006/10/13 14:13:30)
> >
> > Copyright (C) 2006 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions. There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
> >EOF
> 1.5.23a
>
> Could you let us know which version of sed you are using.
$ sed --version
GNU sed version 4.1.5
That's on Cygwin of course.
> >So, after patching autoconf, and making these two patches to apr, I was
> >able to cross compile on cygwin with this command,
> >
> > ./configure apr_cv_tcp_nodelay_with_cork=no ac_cv_func_setpgrp_void=yes
> > ac_cv_file__dev_zero=no --build=i686-pc-cygwin --host=i686-pc-mingw32
> > CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin'
> >
> >I was able to take a sample program, and run it on a machine that did
> >not have cygwin installed, and it ran fine. It was simply a hello world
> >type program with apr stuff in it.
>
> Have you tried the test suite?
Nope, great idea. Attached is the results. I'm going to try a native
build of mingw to make sure the results are the same. How do these
results look?
Thanks,
Bob Rossi
Re: building apr on cygwin for mingw
Posted by John Vandenberg <ja...@gmail.com>.
Hi Bob,
On 12/2/06, Bob Rossi <bo...@cox.net> wrote:
> First, and oddly enough, the buildconf script fails for me because
> build/buildcheck.sh doesn't recognize my libtool --version. I don't know
> sed well enough, and thought someone here would quickly be able to spot
> the problem. If not, I'll have to look deeper.
>
> $ libtool --version 2>/dev/null
>
> ltmain.sh (GNU libtool) 1.5.23a (1.1220.2.412 2006/10/13 14:13:30)
>
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> This command is failing by giving me no output.
> $ libtool --version 2>/dev/null|sed -e 's/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q'
The following worked for me on Fedora Core 3, MSYS (MINGW32_NT-5.1 -
1.0.11), and Cygwin (CYGWIN_NT-5.1 - 1.5.18):
$ cat <<EOF | sed -e 's/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q'
> ltmain.sh (GNU libtool) 1.5.23a (1.1220.2.412 2006/10/13 14:13:30)
>
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> EOF
1.5.23a
Could you let us know which version of sed you are using.
> So, after patching autoconf, and making these two patches to apr, I was
> able to cross compile on cygwin with this command,
>
> ./configure apr_cv_tcp_nodelay_with_cork=no ac_cv_func_setpgrp_void=yes
> ac_cv_file__dev_zero=no --build=i686-pc-cygwin --host=i686-pc-mingw32
> CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin'
>
> I was able to take a sample program, and run it on a machine that did
> not have cygwin installed, and it ran fine. It was simply a hello world
> type program with apr stuff in it.
Have you tried the test suite?
--
John
Re: building apr on cygwin for mingw
Posted by Bob Rossi <bo...@cox.net>.
On Fri, Dec 01, 2006 at 10:10:39PM -0500, Bob Rossi wrote:
> Hi,
>
> I've successfully cross compiled apr on cygwin to mingw. I've already
> had one patch go upstream to autoconf, which fixes a problem
> AC_CHECK_SIZEOF.
>
> I have two very small other problems, that need to be sent upstream, and
> then trunk should work out of the box.
>
> First, and oddly enough, the buildconf script fails for me because
> build/buildcheck.sh doesn't recognize my libtool --version. I don't know
> sed well enough, and thought someone here would quickly be able to spot
> the problem. If not, I'll have to look deeper.
>
> $ libtool --version 2>/dev/null
>
> ltmain.sh (GNU libtool) 1.5.23a (1.1220.2.412 2006/10/13 14:13:30)
>
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> This command is failing by giving me no output.
> $ libtool --version 2>/dev/null|sed -e 's/([^)]*)//g;s/^[^0-9]*//;s/[- ].*//g;q'
>
> So, I changed it to
> $ libtool --version 2>/dev/null|sed -e 's/([^)]*)//g;s/^[^0-9]*//;'
>
> and it worked, but I don't think that is the correct fix. Any ideas?
>
> Secondly, the APR_CHECK_SIZEOF_EXTENDED isn't working for me because the
> default for the cross compiled size is 8. However, ssize_t for me is 4.
> So, the configure fails. I made this change:
>
> -APR_CHECK_SIZEOF_EXTENDED([#include <sys/types.h>], ssize_t, 8)
> +AC_CHECK_SIZEOF([ssize_t], [#include <stdio.h>
> +#include <sys/types.h>])
>
> and things work nicely. Would a patch like this be acceptable? There are
> 5 changes I made just like this. Finally, the macro
> APR_CHECK_SIZEOF_EXTENDED could probably be removed.
>
> So, after patching autoconf, and making these two patches to apr, I was
> able to cross compile on cygwin with this command,
>
> ./configure apr_cv_tcp_nodelay_with_cork=no ac_cv_func_setpgrp_void=yes
> ac_cv_file__dev_zero=no --build=i686-pc-cygwin --host=i686-pc-mingw32
> CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin'
>
> I was able to take a sample program, and run it on a machine that did
> not have cygwin installed, and it ran fine. It was simply a hello world
> type program with apr stuff in it.
>
> I would really appreciate if these thoughts could be considered, so I
> could create a patch to send upstream.
I'm very interested in feedback on this issue. Sorry if I'm to
impatient, I know a release was just made and everyone is probably very
busy.
Thanks,
Bob Rossi
Re: building apr on cygwin for mingw
Posted by Bob Rossi <bo...@cox.net>.
On Wed, Dec 06, 2006 at 02:24:16PM +1100, John Vandenberg wrote:
> On 12/2/06, Bob Rossi <bo...@cox.net> wrote:
> >Hi,
> >
> >...
> >
> >Secondly, the APR_CHECK_SIZEOF_EXTENDED isn't working for me because the
> >default for the cross compiled size is 8. However, ssize_t for me is 4.
> >So, the configure fails. I made this change:
> >
> > -APR_CHECK_SIZEOF_EXTENDED([#include <sys/types.h>], ssize_t, 8)
> > +AC_CHECK_SIZEOF([ssize_t], [#include <stdio.h>
> > +#include <sys/types.h>])
> >
> >and things work nicely. Would a patch like this be acceptable? There are
> >5 changes I made just like this. Finally, the macro
> >APR_CHECK_SIZEOF_EXTENDED could probably be removed.
>
> This makes sense. Apr currently depends on autoconf 2.50; in that
> release AC_CHECK_SIZEOF was enhanced to determine the size without
> using AC_TRY_RUN. In order to replace APR_CHECK_SIZEOF_EXTENDED, we
> need to verify that AC_CHECK_SIZEOF supports non-builtin types. I was
> able to successfully replace APR_CHECK_SIZEOF_EXTENDED with
> AC_CHECK_SIZEOF in conjunction with autoconf 2.53 and 2.59 on Fedora
> Core 3, however I was unable to build autoconf 2.50 or 2.52 on my FC3
> box, so further verification is needed.
OK, sounds great. There currently is a bug in AC_CHECK_SIZEOF in all
released version of autoconf. I obviously do not see this as an apr
issue. The bug was patched upstream because of the problem I found trying
to cross compile apr from cygwin to mingw. The problem is that
AC_CHECK_SIZEOF used to do
FILE *f=fopen("conftestval", "w");
if (!f) exit(1);
fprintf(f, "%d\n", sizeof($2));
exit(0);
but was modified to
FILE *f=fopen("conftestval", "w");
if (!f) exit(1);
fprintf(f, "%d", sizeof($2));
exit(0);
Basically, the \n was removed. This is because it would write a \r\n on
windows. The macro would then cat the file and get back '4\r', which
would not be an acceptable value.
I'm pretty sure this change would be acceptable to make to
APR_CHECK_SIZEOF_EXTENDED, regardless of it the macro is replaced with
AC_CHECK_SIZEOF or not.
Thanks,
Bob Rossi
Re: building apr on cygwin for mingw
Posted by John Vandenberg <ja...@gmail.com>.
On 12/2/06, Bob Rossi <bo...@cox.net> wrote:
> Hi,
>
> ...
>
> Secondly, the APR_CHECK_SIZEOF_EXTENDED isn't working for me because the
> default for the cross compiled size is 8. However, ssize_t for me is 4.
> So, the configure fails. I made this change:
>
> -APR_CHECK_SIZEOF_EXTENDED([#include <sys/types.h>], ssize_t, 8)
> +AC_CHECK_SIZEOF([ssize_t], [#include <stdio.h>
> +#include <sys/types.h>])
>
> and things work nicely. Would a patch like this be acceptable? There are
> 5 changes I made just like this. Finally, the macro
> APR_CHECK_SIZEOF_EXTENDED could probably be removed.
This makes sense. Apr currently depends on autoconf 2.50; in that
release AC_CHECK_SIZEOF was enhanced to determine the size without
using AC_TRY_RUN. In order to replace APR_CHECK_SIZEOF_EXTENDED, we
need to verify that AC_CHECK_SIZEOF supports non-builtin types. I was
able to successfully replace APR_CHECK_SIZEOF_EXTENDED with
AC_CHECK_SIZEOF in conjunction with autoconf 2.53 and 2.59 on Fedora
Core 3, however I was unable to build autoconf 2.50 or 2.52 on my FC3
box, so further verification is needed.
--
John