Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases

[Gregg Smith]

On 10/19/2017 1:49 PM, Gregg Smith wrote:

Now, seeing Steffen's problems and what Michal had to go through to get 
this to build for him, so I'm -1 with apu 1.6.1.


Sorry, I meant -0 as I'm not going to stop this from going out. I am 
still quite unhappy this was done midstream.


I'll personally revert this portion in my copy till it gets working and 
publish a patch somewhere for others that don't want to deal with this 
headache.

Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases

[Gregg Smith]

On 10/18/2017 7:41 PM, William A Rowe Jr wrote:

Two additional footnotes...

On Wed, Oct 18, 2017 at 4:13 PM, Gregg Smith  wrote:

On 10/18/2017 7:58 AM, William A Rowe Jr wrote:


Please cast your votes on the following candidate packages;



I'm not there to vote yet, my question is how did you expect us to build APU
with a precompiled lib and this lib put where?


That was addressed in my first response...\


No, you told me to see CHANGES and makefile.win. If you had really read 
what I said you would have realized I already did, at least makefile.win 
which didn't give me any clues, nor did CHANGES.


  *) Win32: Introduce XML_PARSER build-time variable to select the expat
 library name to be linked to libaprutil-1.dll. See Makefile.win

  *) Win32: Removed lingering xml/xml.dsp project forked from the expat
 Project in the 1.9x era. Use expat's maintained build schema instead,
 prior to building apr-util.

It's big info is look at makafile.win which I did, and stated such from 
the beginning, see the first quoted line below

.



Looking at both makafile.win and libaprutil.mak I see not much for pointers
here. I see an include of ./xml/expat/lib in libaprutil.mak so do I really
have to put expat in the xml folder? Seem it should be outside the apr-util
folder so the include would be like /I ../expat/lib


I am 100% in agreement that moving forwards, we suggest a path of
../expat/ vs expecting anyone to embed some other project's sources
deep within ./xml/expat - that seems absurd. OTOH for those doing
so, I don't think we need to break them...



You should have done this now. You've already upset the flow so just 
take it all the way. This is why I was against this in the first place 
and said this should not be done till 1.7, regardless of said "promise," 
we should just say opps, sorry and move forward with 1.7 where we will 
promise again yet have something in svn showing just that so it's not 
another hollow promise.



Further, no /libpath: pointing to where libexpat.lib is grabbed from at
apu's linking. I don't remember vc ever being that smart to just find it, it
knew it was in ./xml/libR because that's where it put xml.lib, which we
don't have anymore.


Adding doubled /I /LIBPATH "default" options isn't silly, it's actually a
good idea... with that said...


As I said, there is "no /LIBPATH present" so how is it even doubled? VC 
cannot find the lib. So what your saying here is silly.





cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DBUILD_shared=OFF
gives me an expat.lib, not libexpat.lib, so unless I'm missing something
really obvious that's right under my nose, I don't get it :)


As I pointed out in the prior email, there is resolution logic already within
the cmake model. If there are bugs, we should send those upstream.


There's no bug that I know of upstream.



My own build model is one component at a time, never changing the LIB
or INCLUDE path, but just layering one by one by one. Pretty much like
every *nix environment out there. At minimum, cmake can resolve this if
the LIB and INCLUDE path point to this target.



This ain't Unix and I'm tired of that rationale.


When we first started debating, we hotly contested whether an expat
xml.dsp project belonged in the apr-util tree, after APR PMC voted to
expel this component from our own maintenance. I understood the pain
of extracting this and have always invited dialog and participation about
the resolution of this unsustainable situation.

If you have more and better ideas to offer, that DON'T involve this
project substituting its logic for the expat project's logic, please bring
them here, I'm all ears.



I did in the beginning, leave as is and do whatever your heart desires 
in 1.7. Even go as far and ask the others to put there attention to 1.7 
instead of 1.6.


I told you off-list I wasn't going to have a veto war with you but this 
is rediculous and I am really tempted to back out on that and veto this 
mess.


Other things of note. XML_PARSER=libxml doesn't get to libaprutil.mak, I 
get an error about ".lib," meaning it didn't get passed (even though it 
does with $(XMLOPTS), VC just doesn't do it. I believe this is the 
reason I just sent a flag from .win to the .mak files and repeated the 
THIS=that in the .maks for OpenSSL 1.1.0.


Now, seeing Steffen's problems and what Michal had to go through to get 
this to build for him, so I'm -1 with apu 1.6.1.


If you want to continue down this road then I ask you to create a 
readme.win file explaining what us stupid people need to do, how you 
expect us to build expat (so someone doesn't foolishly think they can 
build it with cmake as I did) and where to place it before we start the 
apu build, fix the makefiles and as Steffen suggested, do something with 
cvtdsp.pl to handle the change to the .dsps (too bad cvtdsp's in apr).


I didn't pay much attention to apr or apr-iconv but since both get built 
before apu IIRC I'll have a 

Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases

[Rainer Jung]

Am 18.10.2017 um 16:58 schrieb William A Rowe Jr:

Please cast your votes on the following candidate packages;

Release apr-1.6.3
   [XX] +1 looks good
   [  ] +/-0 since
   [  ] -1 because

Release apr-util-1.6.1
   [XX] +1 looks good
   [  ] +/-0 since
   [  ] -1 because

Release apr-iconv-1.2.2
   [XX] +1 looks good
   [  ] +/-0 since
   [  ] -1 because


General comments:

- Announcement and changes download file not yet present for check.
- you might want to add your (sub?) key to the KEYS file

Detailed APR test results:

- files signed, checksums correct

- svn compared with gz, bz2 and zip only minor differences
  (libtool m4 files in gz and bz2, which seem to not get
   cleaned up by buildconf)

- I built and made check on the following platforms:
  - Solaris 8 Sparc, gcc 4.1.2
  - Solaris 10 Sparc, gcc 7.1.0
  - SuSE Linux Enterprise 10 32, 10, 11 and 12 64 Bit
  - RedHat Enterprise Linux 6 and 7 64 Bit

- config.guess timestamp='2017-09-16',
  pretty much up-to-date

- config.sub timestamp='2017-09-16'
  pretty much up-to-date

- all builds succeeded

- all "make check" ran fine, except for
  - binding to ::1 on Solaris with only IPv4 active,
not a regression:
  testsockets: Line 131: Could not bind socket (126):
  Cannot assign requested address
  Line 189: Condition is false, but expected true
  FAILED 1 of 7
  - Solaris 8 (not a regression):
  testsock: Line 116: Problem generating sockaddr (670008):
  host/servname not known
  Segmentation Fault (coredump)

- Some warnings during "make check":
  - Solaris 8+10 (not a regression)
  testsock: Line 433: Cannot test if connect completes synchronously
  SUCCESS

  - Solaris 8+10, OK doesn't know how to cork
  testsockopt: Line 84: TCP isn't corkable
  SUCCESS

  - Solaris 8, OK doesn't have "unsetenv"
  testenv: Line 75: apr_env_delete
   Line 106: apr_env (skip recycle test_emptyenv)
  SUCCESS

  - Solaris 8, OK doesn't support pollcb
  testpoll: Line 584: pollcb interface not supported
Line 611: pollcb interface not supported
Line 637: pollcb interface not supported
Line 653: pollcb interface not supported
Line 836: pollcb interface not supported
Line 733: pollcb interface not supported
  SUCCESS

  - Linux only 64 Bits: OK, no LFS needed on 64 Bit OS
  testlfs: Line 349: LFS support a no-op in 64-bit builds
  SUCCESS

- tests succeed for apr-util 1.6.1 on top of apr 1.6.3
  for all of the above platforms (all observed test failures
  are old and not related to the new version).


Detailed APR-UTIL test results:

- svn compared with gz, bz2 and zip only expected differences

- files signed, checksums correct

- I built and made check on the following platforms:
  - Solaris 8 Sparc, gcc 4.1.2
  - Solaris 10 Sparc, gcc 7.1.0
  - SuSE Linux Enterprise 10 32, 10, 11 and 12 64 Bit
  - RedHat Enterprise Linux 6 and 7 64 Bit
- using all combinations of:
   - apr 1.6.3
   - expat 2.2.4
   - OpenSSL 1.0.2l (plus some patches)
   - dso disable / enable
   - Berkeley DB 6.1.19
   - sqlite 3.20.1
   - mysql 6.1.10
   - oracle 11.2.0.2.0 (Solaris 10), resp. 10.2.0.5.0 (Solaris 8)
   - platform nss (Solaris 10 and RHEL 6)

- make check for all builds was successful


Detailed APR-ICONV test results:

- svn compared with gz, bz2 and zip only expected differences
  - but autom4te.cache could probably be removed before packaging
tar.gz and tar.bz2

- files signed, checksums correct

- builds fine in combination with APR 1.6.3
  - some compiler warnings

- no check/test make target

I did not actually try to use the build result.


Additional test info:

- httpd test framework looks good for httpd 2.4.29
  using apr/apu 1.6.3/1.6.1 on Solaris 10, SLES 11+12 and RHEL 6+7
  (reallyall module set, shared and static linking,
   MPMs prefork, worker and event, log level trace8)
  I need to give it a final look, details will follow on dev@httpd.

Thanks!

Rainer

Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases

[Steffen]

I put in under the xml folder.

To get libexpat.lib double click the included  lib/expat.vcxproj and convert it.

Build expat

The .dll and lib is created in expat/win32/bin

To reduce the size of the libexpat.dll set in 
properties/linker/debugging/generate debug info to No.

For the C99 issue with VC11, see  www.apachelounge.com/viewtopic.php?t=

Found glitches in the libaprutil.dsp

-  Missing in line LINK the path to libexpat.dll:  
/libpath:"..\..\srclib\apr-util\xml\expat/lib

-  With converting the libaprutil.dsp to a .vcxproj  the $(XML_PARSER) is not 
filled  in:

  $(XML_PARSER).lib;ws2_32.lib;mswsock.lib;

  Adding XML_PARSER=libexpat to the .dsp does not help, so replaced 
$(XML_PARSER) with libexpat.

Only solution I see,  is to add to apr cvtdsp.pl the parser to be used by 
replacing $(XML_PARSER).

Did not build with cmake and .mak files. 
 

For the time being I stick with the former xml build, I see no advantage. 




> Op 18 okt. 2017 om 23:13 heeft Gregg Smith  het volgende 
> geschreven:
> 
>> On 10/18/2017 7:58 AM, William A Rowe Jr wrote:
>> Please cast your votes on the following candidate packages;
> 
> I'm not there to vote yet, my question is how did you expect us to build APU 
> with a precompiled lib and this lib put where?
> 
> Looking at both makafile.win and libaprutil.mak I see not much for pointers 
> here. I see an include of ./xml/expat/lib in libaprutil.mak so do I really 
> have to put expat in the xml folder? Seem it should be outside the apr-util 
> folder so the include would be like /I ../expat/lib
> 
> Further, no /libpath: pointing to where libexpat.lib is grabbed from at apu's 
> linking. I don't remember vc ever being that smart to just find it, it knew 
> it was in ./xml/libR because that's where it put xml.lib, which we don't have 
> anymore.
> 
> cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DBUILD_shared=OFF
> gives me an expat.lib, not libexpat.lib, so unless I'm missing something 
> really obvious that's right under my nose, I don't get it :)
> 

Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases

[Jim Jagielski]

I've built and tested on macOS 10.12. All good.

+1 (binding)

Thx for RMing!

> On Oct 18, 2017, at 10:58 AM, William A Rowe Jr  wrote:
> 
> Please cast your votes on the following candidate packages;
> 
> Release apr-1.6.3
>  [  ] +1 looks good
>  [  ] +/-0 since
>  [  ] -1 because
> 
> Release apr-util-1.6.1
>  [  ] +1 looks good
>  [  ] +/-0 since
>  [  ] -1 because
> 
> Release apr-iconv-1.2.2
>  [  ] +1 looks good
>  [  ] +/-0 since
>  [  ] -1 because
> 
> 
> Note that Visual Studio 2015, at least, broke the apr-iconv build
> altogether so it is overdue a refresh. I understand few here build
> on windows, and fewer still don't swap apr-iconv out for libiconv.
> Since this is a supported build combination for apr-util-1.6.1, please
> offer to review to get us to 3 PMC voters.

Re: [Vote] apr-1.6.3, apr-util-1.6.1, apr-iconv-1.2.2 releases

[Nick Kew]

On Wed, 18 Oct 2017 09:58:59 -0500
William A Rowe Jr  wrote:

> Please cast your votes on the following candidate packages;
> 
> Release apr-1.6.3
>   [  ] +1 looks good
>   [  ] +/-0 since
>   [  ] -1 because

All good on Linux.  Pending testing on Mac and static
review of changes before my +1.  Will complete review
tomorrow.

> Release apr-util-1.6.1
>   [  ] +1 looks good
>   [  ] +/-0 since
>   [  ] -1 because

As above.

> Release apr-iconv-1.2.2
>   [  ] +1 looks good
>   [  ] +/-0 since
>   [  ] -1 because

Wow!  I don't think I've ever built or looked at
apr-iconv before.  Builds successfully on Linux,
but since the issues you've dealt with concern
Windows, I'm not able to review them.

-- 
Nick Kew

Re: Old versions gone from dist/ location

[William A Rowe Jr]

APR 1.5.x is retired for APR 1.6.x (and corresponding -util package)
as mid-June of this year. Note that all 1.x releases preserve
backwards binary compatibility.

All historical artifacts at the ASF can be discovered at;

http://archive.apache.org/dist/

(So in this case... http://archive.apache.org/dist/apr/ )


On Thu, Oct 19, 2017 at 9:30 AM, Mitchell Stevenson
 wrote:
> Seems the 1.5.x versions are deleted from http://www.us.apache.org/dist/apr
> This break for example the netty build which assumes it can download
> http://www.us.apache.org/dist/apr/apr-1.5.2.tar.gz
>
> Is there a location where older source dists can be downloaded from?
>
> Thx
> Mitch

Old versions gone from dist/ location

[Mitchell Stevenson]

Seems the 1.5.x versions are deleted from http://www.us.apache.org/dist/apr
This break for example the netty build which assumes it can download
http://www.us.apache.org/dist/apr/apr-1.5.2.tar.gz

Is there a location where older source dists can be downloaded from?

Thx
Mitch

Re: APR Util: Migrating Win64 build from 1.5.x to 1.6.x; testcrypto fails, looking for NSS

[Michal Karm]

On 10/19/2017 10:57 AM, jean-frederic clere wrote:
> On 10/18/2017 10:39 PM, Michal Karm wrote:
>> Hi guys,
>>
>> I've switched my Windows CI from APR Util 1.5.x
>> to the 1.6.x branch. Little did I know it would
>> demand NSS even though I built with OpenSSL.
>>
>> This is the pertinent excerpt from the log [1],
>> the full build log (large text) can be found here [2]
>> and last but not least, this is the build script [3],
>> note that I tried to set -DAPU_HAVE_NSS=OFF out of good
>> sport, but it was in vain.
>>
>> Could you tell me what might be improved in the
>> CMakeLists.txt so as the test run doesn't look for NSS?
>
> If you look to test/testcrypto.c  it seems it require nss and openssl, I think
> it should be possible to test for nss and skip the corresponding tests...
> Patches are welcome
>
Patched on https://bz.apache.org/bugzilla/show_bug.cgi?id=61636

Cheers
Karm

> Cheers
>
> Jean-Frederic
>
>>
>> Is there anything else fishy about it? Perhaps the root
>> cause is entirely different.
>>
>> Thank you for any pointers
>>
>>
>> Cheers
>>
>> Karm
>>
>> [1] https://www.hastebin.com/umitizokor.lua
>> [2] 
>> https://ci.modcluster.io/job/apr-util-windows/15/label=w2k12r2/consoleText
>> [3]
>> https://github.com/modcluster/ci.modcluster.io/blob/6a01bf9f015224271078336eebab4e258b8f9196/windows/apr-util/build.bat#L28
>>
>>
>> Michal Karm Babacek
>>
>
>

Michal Karm Babacek

-- 
Sent from my Hosaka Ono-Sendai Cyberspace 7




signature.asc
Description: OpenPGP digital signature

Re: APR Util: Migrating Win64 build from 1.5.x to 1.6.x; testcrypto fails, looking for NSS

[jean-frederic clere]

On 10/18/2017 10:39 PM, Michal Karm wrote:

Hi guys,

I've switched my Windows CI from APR Util 1.5.x
to the 1.6.x branch. Little did I know it would
demand NSS even though I built with OpenSSL.

This is the pertinent excerpt from the log [1],
the full build log (large text) can be found here [2]
and last but not least, this is the build script [3],
note that I tried to set -DAPU_HAVE_NSS=OFF out of good
sport, but it was in vain.

Could you tell me what might be improved in the
CMakeLists.txt so as the test run doesn't look for NSS?


If you look to test/testcrypto.c  it seems it require nss and openssl, I 
think it should be possible to test for nss and skip the corresponding 
tests... Patches are welcome


Cheers

Jean-Frederic



Is there anything else fishy about it? Perhaps the root
cause is entirely different.

Thank you for any pointers


Cheers

Karm

[1] https://www.hastebin.com/umitizokor.lua
[2] https://ci.modcluster.io/job/apr-util-windows/15/label=w2k12r2/consoleText
[3]
https://github.com/modcluster/ci.modcluster.io/blob/6a01bf9f015224271078336eebab4e258b8f9196/windows/apr-util/build.bat#L28

Michal Karm Babacek