You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2008/06/03 03:10:32 UTC
Summary of win32 build issues
First note, there is an error I uncovered in apr-iconv-1.2.1's generated dll
.mak file, so an -r2 is on it's way.
Secondly, the sqlite3, oracle and pgsql binaries do build, against the
current official binaries. Which modules may we distribute under the
AL from w.a.o/dist/apr/binaries/win32/? (I have no plan to distribute
the binary of the client itself, only the apr_dbd_*-1.dll's bound to them).
There is no distributed sqlite2 binary that I can find, and I presume that
supporting it would be silly. The MySQL connector which I believe we can't
ship also will not build;
apr_dbd_mysql.c(142) : warning C4244: 'function' : conversion from '__int64
' to 'unsigned long ', possible loss of data
apr_dbd_mysql.c(256) : warning C4018: '>=' : signed/unsigned mismatch
apr_dbd_mysql.c(416) : warning C4244: '=' : conversion from 'double ' to
'float ', possible loss of data
apr_dbd_mysql.c(486) : warning C4244: '=' : conversion from 'double ' to
'float ', possible loss of data
apr_dbd_mysql.c(536) : warning C4244: '=' : conversion from 'unsigned
__int64 ' to 'int ', possible loss of data
apr_dbd_mysql.c(642) : warning C4244: '=' : conversion from 'unsigned
__int64 ' to 'int ', possible loss of data
apr_dbd_mysql.c(868) : error C2632: 'long' followed by 'long' is illegal
apr_dbd_mysql.c(872) : error C2632: 'long' followed by 'long' is illegal
apr_dbd_mysql.c(873) : error C2632: 'long' followed by 'long' is illegal
apr_dbd_mysql.c(873) : warning C4244: '=' : conversion from '__int64 ' to
'long ', possible loss of data
apr_dbd_mysql.c(879) : error C2632: 'long' followed by 'long' is illegal
apr_dbd_mysql.c(883) : error C2632: 'long' followed by 'long' is illegal
apr_dbd_mysql.c(884) : error C2632: 'long' followed by 'long' is illegal
apr_dbd_mysql.c(884) : warning C4244: '=' : conversion from 'unsigned
__int64 ' to 'unsigned long ', possible loss of data
Bottom line, "long long" is just not portable. What's up with that?
FreeTDS also does not build (had to compile this m'self as there are no
official binaries);
apr_dbd_freetds.c(42) : fatal error C1083: Cannot open include file:
'regex.h': No such file or directory
Now, we have a well supported pcre implementation that we already trust;
why is this still using regex by default? Feels very apache1.3 to me :)
Otherwise, posted up the build log for your amusement.
http://apr.apache.org/dev/dist/build-win32-results.log
Of these, the failures map to...
testipsub 5 1 20.00%
testsock 7 1 14.29%
I'm running with the IPv6 stack installed and compiled in, but no configured
IPv6 adapter (very similar to other reports this weekend :-)
testpass 4 2 50.00%
no crypt() support for win32.
testxlate 1 1 100.00%
apr-iconv exhibits strange "end of shift-state" behavior for utf-7
That's the story. Vote forthcoming.
Bill
Re: Summary of win32 build [licensing] issues
Posted by Bojan Smojver <bo...@rexursive.com>.
On Mon, 2008-06-02 at 21:17 -0500, William A. Rowe, Jr. wrote:
> In any case, there is nothing stopping us from shipping these three driver
> connectors that I can find. Thoughts or comments?
Given that this is a Windows specific, I have no idea (just so you know
I'm not ignoring your question).
--
Bojan
Re: Summary of win32 build [licensing] issues
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
I pose this to you all, does anyone have a concern? If not, the oracle,
pgsql and sqlite3 driver connectors will ship. The mysql driver connector
simply will not ship (even once apr-util-1.3.1 is released, now that it
builds), although perhaps from an external site this .dll could be found.
Suggestions welcome.
freetds awaits a windows alternative mssql client connector once someone
has energy to write one.
Bill
> William A. Rowe, Jr. wrote:
>>
>> Secondly, the sqlite3, oracle and pgsql binaries do build, against the
>> current official binaries. Which modules may we distribute under the
>> AL from w.a.o/dist/apr/binaries/win32/? (I have no plan to distribute
>> the binary of the client itself, only the apr_dbd_*-1.dll's bound to
>> them).
>
> My analysis indiciates that there is nothing noxious in the Oracle Instant
> Client license which would encumber us from distributing a binding to it,
> provided that we do not ship it ourselves. GPL packagers might have their
> own concerns with the license.
>
> http://www.oracle.com/technology/software/popup-license/instant_client_lic.html
>
>
> The SQLite libraries are Public Domain. In fact it appears we could ship
> those drivers (as shipped by sqlite.org, I don't really desire to rebuild
> this code unless we believe its necessary). The question is, should we?
>
> The PostgreSQL libraries are BSD licensed. And again it appears we could
> ship those drivers (again from their binary distribution) for the win32
> binary distribution, if we saw a need. But I'd restrict this to the client
> driver only, not the entire PostgreSQL distribution. Again, the question
> would be, should we?
>
> In any case, there is nothing stopping us from shipping these three driver
> connectors that I can find. Thoughts or comments?
>
> Bill
>
>
>
>
Re: Summary of win32 build [licensing] issues
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
I pose this to you all, does anyone have a concern? If not, the oracle,
pgsql and sqlite3 driver connectors will ship. The mysql driver connector
simply will not ship (even once apr-util-1.3.1 is released, now that it
builds), although perhaps from an external site this .dll could be found.
Suggestions welcome.
freetds awaits a windows alternative mssql client connector once someone
has energy to write one.
Bill
> William A. Rowe, Jr. wrote:
>>
>> Secondly, the sqlite3, oracle and pgsql binaries do build, against the
>> current official binaries. Which modules may we distribute under the
>> AL from w.a.o/dist/apr/binaries/win32/? (I have no plan to distribute
>> the binary of the client itself, only the apr_dbd_*-1.dll's bound to
>> them).
>
> My analysis indiciates that there is nothing noxious in the Oracle Instant
> Client license which would encumber us from distributing a binding to it,
> provided that we do not ship it ourselves. GPL packagers might have their
> own concerns with the license.
>
> http://www.oracle.com/technology/software/popup-license/instant_client_lic.html
>
>
> The SQLite libraries are Public Domain. In fact it appears we could ship
> those drivers (as shipped by sqlite.org, I don't really desire to rebuild
> this code unless we believe its necessary). The question is, should we?
>
> The PostgreSQL libraries are BSD licensed. And again it appears we could
> ship those drivers (again from their binary distribution) for the win32
> binary distribution, if we saw a need. But I'd restrict this to the client
> driver only, not the entire PostgreSQL distribution. Again, the question
> would be, should we?
>
> In any case, there is nothing stopping us from shipping these three driver
> connectors that I can find. Thoughts or comments?
>
> Bill
>
>
>
>
Re: Summary of win32 build [licensing] issues
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
>
> Secondly, the sqlite3, oracle and pgsql binaries do build, against the
> current official binaries. Which modules may we distribute under the
> AL from w.a.o/dist/apr/binaries/win32/? (I have no plan to distribute
> the binary of the client itself, only the apr_dbd_*-1.dll's bound to them).
My analysis indiciates that there is nothing noxious in the Oracle Instant
Client license which would encumber us from distributing a binding to it,
provided that we do not ship it ourselves. GPL packagers might have their
own concerns with the license.
http://www.oracle.com/technology/software/popup-license/instant_client_lic.html
The SQLite libraries are Public Domain. In fact it appears we could ship
those drivers (as shipped by sqlite.org, I don't really desire to rebuild
this code unless we believe its necessary). The question is, should we?
The PostgreSQL libraries are BSD licensed. And again it appears we could
ship those drivers (again from their binary distribution) for the win32
binary distribution, if we saw a need. But I'd restrict this to the client
driver only, not the entire PostgreSQL distribution. Again, the question
would be, should we?
In any case, there is nothing stopping us from shipping these three driver
connectors that I can find. Thoughts or comments?
Bill
Re: Summary of win32 build issues
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Philip M. Gollucci wrote:
> httpd has other PCRE issues like local modes in 5.0 which is what is
> shipped currently.
> Now that PCRE is maintained upstream again (7.7) we really should submit
> of hacks back, yada yada....
patches welcome, discussion probably over on dev@httpd, but would you mind
tackling this?
Re: Summary of win32 build issues
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Bojan Smojver wrote:
> On Wed, 2008-06-04 at 18:28 -0500, William A. Rowe, Jr. wrote:
>
>> Many linkage problems, but it compiles now. I'll work those out.
>
> OK, thanks.
>
> I'm not sure what to do about that FreeTDS thing. We use/ship PCRE
> within Apache, but we don't have support for that in APR/APU. Were you
> hinting at maybe putting PCRE into APR/APU? Or did you simply want regex
> support to be from PCRE in the driver?
httpd has other PCRE issues like local modes in 5.0 which is what is
shipped currently.
Now that PCRE is maintained upstream again (7.7) we really should submit
of hacks back, yada yada....
--
------------------------------------------------------------------------
Philip M. Gollucci (philip@ridecharge.com)
o:703.549.2050x206
Senior System Admin - Riderway, Inc.
http://riderway.com / http://ridecharge.com
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.
Re: ODBC driver (Re: Summary of win32 build issues)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Tom Donovan wrote:
> Nick Kew wrote:
>>
>>
>> On Tue, 10 Jun 2008, Tom Donovan wrote:
>>
>>> If there's interest, I have an ODBC DBD driver I would be glad to
>>> contribute.
>>
>> That'll be great. I look forward to it!
>>
>> Given the limitations of the FreeTDS driver, I think there's a strong
>> case to recommend the ODBC driver over it on all platforms, not
>> just Windows.
>
> OK. I think it follows the APR guidelines - but if anyone has the time
> to give it a quick review that would be appreciated.
>
> apr_dbd_odbc.c for APR 1.3 is in (svn)
> http://odbc-dbd.googlecode.com/svn/trunk/
>
> To go into apr it needs #ifdef HAVE_ODBC_H, and all the changes to
> apu.h(w nw .in), dbd.m4, dso.m4, etc. which I may need a little help
> with. I'll wait a few days to let folks look it over, then I'll check
> it into apr-util/trunk if there are no objections.
It sounds great! If you are the author and copyright holder, then you can
commit it directly. If the copyright is actually owned by another, then
we'll work through a code grant / Incubator IP import form.
Might want to commit to trunk/ and others are happy to help plug into the
autoconf magic.
Bill
Re: ODBC driver (Re: Summary of win32 build issues)
Posted by Tom Donovan <do...@bellatlantic.net>.
Nick Kew wrote:
>
>
> On Tue, 10 Jun 2008, Tom Donovan wrote:
>
>> If there's interest, I have an ODBC DBD driver I would be glad to
>> contribute.
>
> That'll be great. I look forward to it!
>
> Given the limitations of the FreeTDS driver, I think there's a strong
> case to recommend the ODBC driver over it on all platforms, not
> just Windows.
>
OK. I think it follows the APR guidelines - but if anyone has the time to give it a quick review
that would be appreciated.
apr_dbd_odbc.c for APR 1.3 is in (svn) http://odbc-dbd.googlecode.com/svn/trunk/
To go into apr it needs #ifdef HAVE_ODBC_H, and all the changes to apu.h(w nw .in), dbd.m4, dso.m4,
etc. which I may need a little help with. I'll wait a few days to let folks look it over, then I'll
check it into apr-util/trunk if there are no objections.
-tom-
Re: ODBC driver (Re: Summary of win32 build issues)
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/11/2008 03:27 AM, Nick Kew wrote:
>
>
> On Tue, 10 Jun 2008, Tom Donovan wrote:
>
>> If there's interest, I have an ODBC DBD driver I would be glad to
>> contribute.
+1
Regards
Rüdiger
ODBC driver (Re: Summary of win32 build issues)
Posted by Nick Kew <ni...@apache.org>.
On Tue, 10 Jun 2008, Tom Donovan wrote:
> If there's interest, I have an ODBC DBD driver I would be glad to contribute.
That'll be great. I look forward to it!
Given the limitations of the FreeTDS driver, I think there's a strong
case to recommend the ODBC driver over it on all platforms, not
just Windows.
--
Nick Kew
Re: Summary of win32 build issues
Posted by Tom Donovan <do...@bellatlantic.net>.
If there's interest, I have an ODBC DBD driver I would be glad to contribute.
It's currently hosted at http://odbc-dbd.googlecode.com/
The license is already Apache2, so transferring ownership shouldn't pose any problems.
For Windows, it could be included by default because odbc32.dll is always present. For Unix, one of
the common ODBC managers (UnixODBC or iODBC) is usually a prerequisite.
-tom-
William A. Rowe, Jr. wrote:
> Bojan Smojver wrote:
>> On Wed, 2008-06-04 at 18:28 -0500, William A. Rowe, Jr. wrote:
>>
>>> Many linkage problems, but it compiles now. I'll work those out.
>>
>> OK, thanks.
>>
>> I'm not sure what to do about that FreeTDS thing. We use/ship PCRE
>> within Apache, but we don't have support for that in APR/APU. Were you
>> hinting at maybe putting PCRE into APR/APU? Or did you simply want regex
>> support to be from PCRE in the driver?
>
> I was obviously clueless, and I'm better now.
>
> What we need is an mssql flavor for win32 builders (disabled, of course,
> on unix). As freetds has no other purpose it seems silly to even consider
> building on win32.
>
> An odbc flavor on both win32 and unix would be slick, of course ;-)
>
>
Re: Summary of win32 build issues
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Bojan Smojver wrote:
> On Wed, 2008-06-04 at 18:28 -0500, William A. Rowe, Jr. wrote:
>
>> Many linkage problems, but it compiles now. I'll work those out.
>
> OK, thanks.
>
> I'm not sure what to do about that FreeTDS thing. We use/ship PCRE
> within Apache, but we don't have support for that in APR/APU. Were you
> hinting at maybe putting PCRE into APR/APU? Or did you simply want regex
> support to be from PCRE in the driver?
I was obviously clueless, and I'm better now.
What we need is an mssql flavor for win32 builders (disabled, of course,
on unix). As freetds has no other purpose it seems silly to even consider
building on win32.
An odbc flavor on both win32 and unix would be slick, of course ;-)
Re: Summary of win32 build issues
Posted by Bojan Smojver <bo...@rexursive.com>.
On Wed, 2008-06-04 at 18:28 -0500, William A. Rowe, Jr. wrote:
> Many linkage problems, but it compiles now. I'll work those out.
OK, thanks.
I'm not sure what to do about that FreeTDS thing. We use/ship PCRE
within Apache, but we don't have support for that in APR/APU. Were you
hinting at maybe putting PCRE into APR/APU? Or did you simply want regex
support to be from PCRE in the driver?
--
Bojan
Re: Summary of win32 build issues
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Bojan Smojver wrote:
> How does this patch work for you? I don't have Windows so I cannot
> test...
Many linkage problems, but it compiles now. I'll work those out.
Bill
Re: Summary of win32 build issues
Posted by Bojan Smojver <bo...@rexursive.com>.
How does this patch work for you? I don't have Windows so I cannot
test...
--
Bojan
Re: Summary of win32 build issues
Posted by Bojan Smojver <bo...@rexursive.com>.
On Mon, 2008-06-02 at 20:10 -0500, William A. Rowe, Jr. wrote:
> apr_dbd_mysql.c(142) : warning C4244: 'function' : conversion from '__int64
> ' to 'unsigned long ', possible loss of data
> apr_dbd_mysql.c(256) : warning C4018: '>=' : signed/unsigned mismatch
> apr_dbd_mysql.c(416) : warning C4244: '=' : conversion from 'double ' to
> 'float ', possible loss of data
> apr_dbd_mysql.c(486) : warning C4244: '=' : conversion from 'double ' to
> 'float ', possible loss of data
> apr_dbd_mysql.c(536) : warning C4244: '=' : conversion from 'unsigned
> __int64 ' to 'int ', possible loss of data
> apr_dbd_mysql.c(642) : warning C4244: '=' : conversion from 'unsigned
> __int64 ' to 'int ', possible loss of data
Get it - will fix. It's just a cast thingy...
> apr_dbd_mysql.c(868) : error C2632: 'long' followed by 'long' is illegal
> apr_dbd_mysql.c(872) : error C2632: 'long' followed by 'long' is illegal
> apr_dbd_mysql.c(873) : error C2632: 'long' followed by 'long' is illegal
> apr_dbd_mysql.c(873) : warning C4244: '=' : conversion from '__int64 ' to
> 'long ', possible loss of data
> apr_dbd_mysql.c(879) : error C2632: 'long' followed by 'long' is illegal
> apr_dbd_mysql.c(883) : error C2632: 'long' followed by 'long' is illegal
> apr_dbd_mysql.c(884) : error C2632: 'long' followed by 'long' is illegal
> apr_dbd_mysql.c(884) : warning C4244: '=' : conversion from 'unsigned
> __int64 ' to 'unsigned long ', possible loss of data
Sorry, just blindly following the manual:
http://dev.mysql.com/doc/refman/5.0/en/c-api-prepared-statement-datatypes.html
> Bottom line, "long long" is just not portable. What's up with that?
I guess we'll need to find a way to work around that. My best bet is
that we can abuse my_ulonglong for that purpose.
--
Bojan