You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Graham Leggett <mi...@sharp.fm> on 2011/12/08 00:25:25 UTC
[VOTE] Release apr-util 1.4.1
Hi all,
Tarballs/zipballs are at http://apr.apache.org/dev/dist/autoconf-2.68+libtool-2.4.2/.
New in apr-util v1.4 is the apr_crypto interface, and a fix for LDAP on Solaris. Full CHANGES are here:
https://svn.apache.org/repos/asf/apr/apr-util/tags/1.4.1/CHANGES
+/-1
[ ] Release apr-util 1.4.1 as GA
Regards,
Graham
--
Re: [VOTE] Release apr-util 1.4.1
Posted by Graham Leggett <mi...@sharp.fm>.
On 08 Dec 2011, at 1:25 AM, Graham Leggett wrote:
> +/-1
> [ ] Release apr-util 1.4.1 as GA
With binding votes from minfrin, jim, mturk and rjung, and a non binding vote from igalic, apr-util v1.4.1 is released.
Regards,
Graham
--
Re: [VOTE] Release apr-util 1.4.1
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1: Fed14, OSX 10.7 (Xcode 4.2.1), CentOS6
On Dec 7, 2011, at 6:25 PM, Graham Leggett wrote:
> Hi all,
>
> Tarballs/zipballs are at http://apr.apache.org/dev/dist/autoconf-2.68+libtool-2.4.2/.
>
> New in apr-util v1.4 is the apr_crypto interface, and a fix for LDAP on Solaris. Full CHANGES are here:
> https://svn.apache.org/repos/asf/apr/apr-util/tags/1.4.1/CHANGES
>
> +/-1
> [ ] Release apr-util 1.4.1 as GA
>
> Regards,
> Graham
> --
>
Re: [VOTE] Release apr-util 1.4.1
Posted by Mladen Turk <mt...@apache.org>.
On 12/14/2011 03:14 PM, Rainer Jung wrote:
> On 14.12.2011 11:09, Mladen Turk wrote:
>> On 12/14/2011 04:25 AM, William A. Rowe Jr. wrote:
>> > Reposting for Graham's benefit, who likely skimmed over this;
>> >
>> > On 12/11/2011 1:49 PM, Rainer Jung wrote:
>> >>
>> >> - Windows Build system:
>> >> - all *.dep and *.mak files are missing
>> >> - in test/testutildll.dsp the probably obsolete string "NT" is
>> >> by the possibly similarly obsolete "9x"
>> >> - change of base addresses in some dsp file (might be OK)
>> >
>> > Bill asks, can you be more specific on the 3rd bullet? Because we aim
>> > for binary compatibility, that would be a (regrettable) regression. As
>> > I was traveling, I had no chance to look at this candidate.
>> >
>>
>> If you look at old version multiple modules has the same base address
>> which was probably caused by simple copy/paste.
>> Eg, multiple dbd modules had the same base address (0x6EF00000)
>> dmb modules had the same address as dbd modules.
>>
>> I only made sure they are unique, because if you try to load the
>> second dll with the same base address it'll get random one.
>
> Changes rel. 1.3.12 I observed:
>
> base address 0x6EF00000 -> 0x6EF60000 apr_dbd_freetds.dsp
> base address 0x6EF00000 -> 0x6F000000 apr_dbm_db.dsp
> base address 0x6EF10000 -> 0x6F010000 apr_dbm_gdbm.dsp
>
Right, as you see apr_dbd_freetds and apr_dbm_db had the
same base address.
apr_dbm_gdbm had the same address as apr_dbd_odbc module.
That was wrong at the first place, so hardly any regression.
Regards
--
^TM
Re: [VOTE] Release apr-util 1.4.1
Posted by Rainer Jung <ra...@kippdata.de>.
On 14.12.2011 11:09, Mladen Turk wrote:
> On 12/14/2011 04:25 AM, William A. Rowe Jr. wrote:
> > Reposting for Graham's benefit, who likely skimmed over this;
> >
> > On 12/11/2011 1:49 PM, Rainer Jung wrote:
> >>
> >> - Windows Build system:
> >> - all *.dep and *.mak files are missing
> >> - in test/testutildll.dsp the probably obsolete string "NT" is
> >> by the possibly similarly obsolete "9x"
> >> - change of base addresses in some dsp file (might be OK)
> >
> > Bill asks, can you be more specific on the 3rd bullet? Because we aim
> > for binary compatibility, that would be a (regrettable) regression. As
> > I was traveling, I had no chance to look at this candidate.
> >
>
> If you look at old version multiple modules has the same base address
> which was probably caused by simple copy/paste.
> Eg, multiple dbd modules had the same base address (0x6EF00000)
> dmb modules had the same address as dbd modules.
>
> I only made sure they are unique, because if you try to load the
> second dll with the same base address it'll get random one.
Changes rel. 1.3.12 I observed:
base address 0x6EF00000 -> 0x6EF60000 apr_dbd_freetds.dsp
base address 0x6EF00000 -> 0x6F000000 apr_dbm_db.dsp
base address 0x6EF10000 -> 0x6F010000 apr_dbm_gdbm.dsp
Looks like r1211219 and r1211223.
Regards,
Rainer
Re: [VOTE] Release apr-util 1.4.1
Posted by Mladen Turk <mt...@apache.org>.
On 12/14/2011 04:25 AM, William A. Rowe Jr. wrote:
> Reposting for Graham's benefit, who likely skimmed over this;
>
> On 12/11/2011 1:49 PM, Rainer Jung wrote:
>>
>> - Windows Build system:
>> - all *.dep and *.mak files are missing
>> - in test/testutildll.dsp the probably obsolete string "NT" is
>> by the possibly similarly obsolete "9x"
>> - change of base addresses in some dsp file (might be OK)
>
> Bill asks, can you be more specific on the 3rd bullet? Because we aim
> for binary compatibility, that would be a (regrettable) regression. As
> I was traveling, I had no chance to look at this candidate.
>
If you look at old version multiple modules has the same base address
which was probably caused by simple copy/paste.
Eg, multiple dbd modules had the same base address (0x6EF00000)
dmb modules had the same address as dbd modules.
I only made sure they are unique, because if you try to load the
second dll with the same base address it'll get random one.
Regards
--
^TM
Re: [VOTE] Release apr-util 1.4.1
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 12/14/2011 3:13 AM, Mario Brandt wrote:
> On Wed, Dec 14, 2011 at 04:25, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>
>> I'll check in these files for potential inclusion in a 1.4.2, as folks
>> decided this mostly works now. But we really can't persist this mess for
>> Netware or Win32 going on to APR 2.0. Seems overtime for Guenter and I,
>> or other fresh blood, to get on the task of generating appropriate build
>> files automagically.
>
> An Idea is might to take a look at the python script from subverion
> that generates that file or the configure.js(for windows) from php
> source code.
> In my point of view the js script is maybe nicer, cause you don't have
> to install python and the javascript support is already on board.
> Just my 2 cents
We don't mind if python is required to update an svn checkout into a
buildable package. Once build files are generated, python is no longer
required. It should work on unix or windows or netware, the idea being
that one checkout/buildconf on unix would be enough to create the whole
package logic.
Re: [VOTE] Release apr-util 1.4.1
Posted by Mario Brandt <jb...@gmail.com>.
On Wed, Dec 14, 2011 at 04:25, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> I'll check in these files for potential inclusion in a 1.4.2, as folks
> decided this mostly works now. But we really can't persist this mess for
> Netware or Win32 going on to APR 2.0. Seems overtime for Guenter and I,
> or other fresh blood, to get on the task of generating appropriate build
> files automagically.
An Idea is might to take a look at the python script from subverion
that generates that file or the configure.js(for windows) from php
source code.
In my point of view the js script is maybe nicer, cause you don't have
to install python and the javascript support is already on board.
Just my 2 cents
Mario
Re: [VOTE] Release apr-util 1.4.1
Posted by Guenter Knauf <fu...@apache.org>.
Am 14.12.2011 11:40, schrieb Graham Leggett:
> Just to be clear, I don't have any access to a Windows system, never
> mind a Windows development environment, just like I don't have access
> to Netware either. I can't comment on any of these points because I'm
> not familiar enough with any of them to make any sort of
> modification.
the problem is that those familar with those platforms should work
harder on more automatism (see my other post for a possible way of doing
that).
All you can do for now is posting a reminder to the list if you have
made changes which you think require further tweaks on the static build
systems.
Gün.
Re: [VOTE] Release apr-util 1.4.1
Posted by Graham Leggett <mi...@sharp.fm>.
On 14 Dec 2011, at 5:25 AM, William A. Rowe Jr. wrote:
> Reposting for Graham's benefit, who likely skimmed over this;
>
> On 12/11/2011 1:49 PM, Rainer Jung wrote:
>>
>> - Windows Build system:
>> - all *.dep and *.mak files are missing
>> - in test/testutildll.dsp the probably obsolete string "NT" is
>> by the possibly similarly obsolete "9x"
>> - change of base addresses in some dsp file (might be OK)
Just to be clear, I don't have any access to a Windows system, never mind a Windows development environment, just like I don't have access to Netware either. I can't comment on any of these points because I'm not familiar enough with any of them to make any sort of modification.
Which leads me to the point I wanted to make earlier in response to Rainer but haven't had a chance to as yet.
The code tree needs to be kept in a releasable state at all times.
I entirely understand that things get missed, and in turn I am entirely happy to reroll a release if necessary, because I want to roll the best release we can. But attempting to use a "just in time" process to see if the builds still work on Windows just prior to release is broken. The builds should always work.
If anyone wants to improve the Windows build and fix any regressions, I am happy to RM another release (or releases) until it's right.
Regards,
Graham
--
Re: [VOTE] Release apr-util 1.4.1
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 12/14/2011 5:32 AM, Guenter Knauf wrote:
> 3) for MSVC we generate the makefiles/dsp with the release script which generates the file
> part from Makefile.inc + adds a header and footer to create a working nmake makefile and dsp.
FWIW we are really interested in makefiles for windows (and netware).
For GUI users, vcproj/sln files are all we need for windows, not sure
what we would like to generate for eclipse, codewarrior, etc. Someone
else would have to champion those. But dsp only persisted because it
could be translated to vcproj and mak files. The latest visual studio
no longer imports dsp files, so the approach is no longer interesting.
Re: [VOTE] Release apr-util 1.4.1
Posted by Guenter Knauf <fu...@apache.org>.
Am 14.12.2011 04:25, schrieb William A. Rowe Jr.:
> I'll check in these files for potential inclusion in a 1.4.2, as folks
> decided this mostly works now. But we really can't persist this mess for
> Netware or Win32 going on to APR 2.0. Seems overtime for Guenter and I,
> or other fresh blood, to get on the task of generating appropriate build
> files automagically.
let me propose to work towards a concept we use with libcurl:
1) we have put all .c and .h files into a Makefile.inc
2) Makefile.am as well as all static makefiles (NetWare, MingW, OS400,
etc.) directly pick up this Makefile.inc and build their object files
list from that unless the platform uses non-gnu make
3) for MSVC we generate the makefiles/dsp with the release script which
generates the file part from Makefile.inc + adds a header and footer to
create a working nmake makefile and dsp.
If one is interested into this concept get a libcurl clone from git and
take a look.
Gün.
Re: [VOTE] Release apr-util 1.4.1
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Reposting for Graham's benefit, who likely skimmed over this;
On 12/11/2011 1:49 PM, Rainer Jung wrote:
>
> - Windows Build system:
> - all *.dep and *.mak files are missing
> - in test/testutildll.dsp the probably obsolete string "NT" is
> by the possibly similarly obsolete "9x"
> - change of base addresses in some dsp file (might be OK)
Bill asks, can you be more specific on the 3rd bullet? Because we aim
for binary compatibility, that would be a (regrettable) regression. As
I was traveling, I had no chance to look at this candidate.
Yes, 9x is most certainly obsolete, each of apr, and apr-util, moved to
NT-only design constraints, as of 1.4.x release trees. It's old news for
APR, but only just realized for apr-util. NT was once the exception, now
9x is the (absurd) exception.
On the first bullet, as I wrote last week while traveling, the initial
1.X.0 -win32-src exports are entirely dependent upon checking in all of
the crap that goes along with modifying sources of generated output, in
the same way that we don't check in ./configure crap.
Once 1.X.0 (or this time, 1.4.1) actually works, checking in a set of
.mak/.dep files which won't change (much) over the lifetime of the stable
branch is trivial. I think I commented to this point while traveling.
But if there is noone else who actually cares to this point, I certainly
won't be bothered. I certainly wouldn't be here if I continued to let
things like unfinished API's or missing files bother me.
I'll check in these files for potential inclusion in a 1.4.2, as folks
decided this mostly works now. But we really can't persist this mess for
Netware or Win32 going on to APR 2.0. Seems overtime for Guenter and I,
or other fresh blood, to get on the task of generating appropriate build
files automagically.
Bill
Re: [VOTE] Release apr-util 1.4.1
Posted by Rainer Jung <ra...@kippdata.de>.
On 08.12.2011 00:25, Graham Leggett wrote:
> Hi all,
>
> Tarballs/zipballs are at http://apr.apache.org/dev/dist/autoconf-2.68+libtool-2.4.2/.
>
> New in apr-util v1.4 is the apr_crypto interface, and a fix for LDAP on Solaris. Full CHANGES are here:
> https://svn.apache.org/repos/asf/apr/apr-util/tags/1.4.1/CHANGES
>
> +/-1
> [+1] Release apr-util 1.4.1 as GA
That was a difficult decision, but all problems are either not a
regression, or crypto specific, or Windows specific. So overall still
+1, but we should really fix some of those problems.
Summary:
- CHANGES-APR-UTIL_1.4 file not available for download
- some libtool m4 files not deleted by buildconf (see below)
- does not compile crypto/apr_crypto.c without DSO support
(see below)
- crypto configure seems to run twice (see Jeff's mail)
- crypto configure does not output a result (yes/no)
- crypto configure for OpenSSL at least fails on Solaris,
because when linking against the libssl we need
the additional flags "-ldl -lsocket -lnsl". Curreently
there's no way to fix this apart from hacking configure.
For Linux I'm not sure, but likely you'll need "-ldl".
- LDADD_* variables are always set in the m4 files instead
of using APR_ADDTO like we do in httpd land. So no way
of adding custom flags before the build.
- LDADD flags are typically not respected during configure
- configure fails for Berkeley DB in non-standard path,
because it doesn't add an rpath to conftest and then tries
to run the file
- no rpath for ldap, mysql and crypto dso extensions. So no
way to run without LD_LIBRARY_PATH. Interesting: the m4 file
does add an rpath for oracle. Since there's no platform independent
way to add rpath, we might remove it everywhere but respect
the LDADD variables and also only add to them instead of overwriting
- testall does not show an error even when crypto can not find
the ssl library. But if you run "testall -v", then it produces
output that it can't load the ssl libraries
- testall fails in crypto on RHEL (where I build NSS and OpenSSL
crypto drivers) (see below)
- Windows Build system:
- all *.dep and *.mak files are missing
- in test/testutildll.dsp the probably obsolete string "NT" is
by the possibly similarly obsolete "9x"
- change of base addresses in some dsp file (might be OK)
- side note about *apr* 1.4 head: "set but not used" warnings in:
test/testlockperf.c:229:17: 'lockname'
test/testmmap.c:122:18: 'rv'
test/testfile.c:739:18: 'rv'
test/testfile.c:925:18: 'rv'
test/testnames.c:272:9: 'hadfailed'
test/echod.c:116:18: 'rv'
test/sockperf.c:206:18: 'rv'
Further testing details:
- svn compared with gz, bz2 and zip only expected differences
except for the following which are not a blocker;
IMHO we could remove those at the and of buildconf
libtool.m4
lt~obsolete.m4
ltoptions.m4
ltsugar.m4
ltversion.m4
- files signed, checksums correct
- built and made check on the following platforms:
- Solaris 8 and 10 Sparc (gcc 4.1. resp. 4.6.2)
- SuSE Linux Enterprise 10 32 Bit and 10 and 11 64 Bit
- RedHat Enterprise Linux 5 64 Bit
- using all combinations of:
- apr 1.4.5 / 1.4.x r1212996
- expat builtin / 2.0.1
- dso disable / enable (dso disable on on Solaris 10)
- Berkeley DB 5.1.25
- sqlite 3.7.8.0
- mysql 6.0.2 (only Solaris)
- oracle 11.2.0.2.0 (Solaris 10), resp. 10.2.0.5.0 (Solaris 8)
- platform nss (Solaris 10 and RHEL 5)
- all builds against either APR with --disable-dso or
APU with --disable-util-dso fail during building crypto:
.../crypto/apr_crypto.c: In function 'apr_crypto_init':
.../crypto/apr_crypto.c:113:5: error: 'params' undeclared (first use in
this function)
.../crypto/apr_crypto.c:113:5: note: each undeclared identifier is
reported only once for each function it appears in
.../crypto/apr_crypto.c:113:5: error: too few arguments to function
'apr_crypto_openssl_driver.init'
.../crypto/apr_crypto.c:116:5: error: too few arguments to function
'apr_crypto_nss_driver.init'
- make check for the successful build ran fine except for:
- binding to ::1 on Solaris with only IPv4 active,
not a regression
- testing crypto on RHEL where I built crypto with nss and OpenSSL:
passphrase: KEY_3DES_192/MODE_CBC nss native error -8128: ()
passphrase: KEY_3DES_192/MODE_CBC nss native error -8128: ()
passphrase: KEY_AES_256/MODE_CBC nss native error -8128: ()
passphrase: KEY_AES_256/MODE_CBC nss native error -8128: ()
...
passphrase: KEY_AES_256/MODE_ECB nss native error -8128: ()
passphrase: KEY_3DES_192/MODE_CBC nss native error -8128: ()
passphrase: KEY_AES_256/MODE_CBC nss native error -8128: ()
FAILED 6 of 13
- I have not run the httpd test framework against those builds
Regards,
Rainer
Re: [VOTE] Release apr-util 1.4.1
Posted by Graham Leggett <mi...@sharp.fm>.
On 08 Dec 2011, at 1:25 AM, Graham Leggett wrote:
> +/-1
> [ X ] Release apr-util 1.4.1 as GA
+1.
Builds clean and all tests pass on Centos6, FC17, and MacOSX 10.6.
Regards,
Graham
--
Re: [VOTE] Release apr-util 1.4.1
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> On 12/08/2011 12:25 AM, Graham Leggett wrote:
> > Tarballs/zipballs are at
> > http://apr.apache.org/dev/dist/autoconf-2.68+libtool-2.4.2/.
> >
> > +/-1
> > [X ] Release apr-util 1.4.1 as GA
> >
>
> +1
Copying from other thread:
diff between tag and tar ball looks fine
GPG verifies.
./configure --with-apr=/usr (Ubuntu 11.10 apr 1.4.5)
make, make check pass fine.
Also tested with Clang 3.1
+1 (non-binding)
> Regards
> --
> ^TM
i
Re: [VOTE] Release apr-util 1.4.1
Posted by Mladen Turk <mt...@apache.org>.
On 12/08/2011 12:25 AM, Graham Leggett wrote:
> Tarballs/zipballs are at http://apr.apache.org/dev/dist/autoconf-2.68+libtool-2.4.2/.
>
> +/-1
> [X ] Release apr-util 1.4.1 as GA
>
+1
Regards
--
^TM