apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: [VOTE] Release APR 1.5.2
Date Tue, 28 Apr 2015 04:00:45 GMT
I am searching and do not see a call for vote on APR until Gregg just
replied.

I'd love to have this done, but doubt it is legit to start a clock on some
other project's post ;-/

Me, myself, am looking forward to reviewing and integrating in the morning
here.  Thanks Jeff.

Bill

On Mon, Apr 27, 2015 at 7:14 PM, Gregg Smith <gls@gknw.net> wrote:

> On 4/27/2015 4:07 PM, Jeff Trawick wrote:
>
>> On 04/27/2015 08:28 AM, Jeff Trawick wrote:
>>
>>> On 04/27/2015 08:15 AM, Jeff Trawick wrote:
>>>
>>>> On 04/26/2015 11:59 PM, Gregg Smith wrote:
>>>>
>>>>> On 4/25/2015 6:39 AM, Jeff Trawick wrote:
>>>>>
>>>>>> +/-1
>>>>>> [  ] Release APR 1.5.2 as GA
>>>>>>
>>>>>
>>>>> Win 8.1, VS 2013 x86, zip, retro build
>>>>> apr tests lib&dll pass
>>>>> httpd-2.4.12 build regression
>>>>>
>>>>> Win Vista, VS 2008 x86, zip, retro build
>>>>> apr tests lib&dll pass
>>>>> httpd-2.4.12 build regression
>>>>> apr-1.lib(rand.obj) : error LNK2019: unresolved external symbol
>>>>> __imp__UuidCreate@4 referenced in function _apr_os_uuid_get@4
>>>>> This happens on many projects in /support that link to the static lib
>>>>> (ab, httdigest, etc.).
>>>>>
>>>>> I'm kind of stumped as to what change has done this. I can easily
>>>>> compensate for it in httpd and is probably the best way on the retro
build.
>>>>>
>>>>> I'm +/-0
>>>>>
>>>>>
>>>> My best guess as to the trigger: file_io/win32/pipe.c now uses
>>>> apr_generate_random_bytes() which is implemented in the same file that has
>>>> the only call to UuidCreate() (rand.obj).
>>>>
>>>>
>> Gregg, can you comment out the apr_generate_random_bytes() call and the
>> apr_escape_hex() call just below in file_io/win32/pipe.c and verify that
>> the build problem goes away?
>>
>> I just did a release build of 1.5.1 and 1.5.2 and see the external
>> reference to UuidCreate in both (...UNDEF...External...__imp_UuidCreate).
>>
>> Can you add rpcrt4 to at least one httpd support program and see if it
>> succeeds in linking with the original 1.5.2 code?
>>
>> It is unfortunate that there is
>>
>> * no doc to tell user which system libraries to use when linking with
>> apr-1.lib
>> * no APR build script/setting to tell user's build system which system
>> libraries to use when linking with apr-1.lib
>>
>> httpd includes rpcrt4 in two of the support/*.dsp files and omits it from
>> the rest.  It is natural to want to add libraries only where required, but
>> it isn't something that httpd can expect to work as-is forever.
>>
>
> I think this will work, I did as much to get a full httpd build I believe
> yesterday.
>
>
>> (I see this in apr/test/Makefile.win: LD_LIBS = kernel32.lib advapi32.lib
>> ws2_32.lib wsock32.lib ole32.lib shell32.lib rpcrt4.lib which is as much a
>> sample as we have AFAIK.)
>>
>>
>>  I wonder if some objects can be omitted from apr-1.lib based on their
>>>> use within the library :(  I see " /OPT:REF eliminates functions and data
>>>> that are never referenced; /OPT:NOREF keeps functions and data that are
>>>> never referenced. ...  By default, /OPT:REF is enabled in non-debug
>>>> builds." at https://msdn.microsoft.com/en-us/library/bxwfs976.aspx
>>>>
>>>>
>> This comment is missing the point IIUC: /OPT:REF|NOREF is not applicable
>> to linking apr-1.lib; it is applicable to something that links against it.
>>
>>  (the idea being that we didn't notice the need for an extra Windows
>>> library in parts of httpd that link apr statically in the past because the
>>> code which calls UuidCreate() was omitted)
>>>
>>> httpd/2.4.x/support/passwd_common.c uses apr_generate_random_bytes; that
>>> presumably uses the apr static library too, so this doesn't seem to hold
>>> water.
>>>
>>>
> I had some outpatient surgery done this morning so sorry if I sound quite
> out of it. Yes, changes in the past have caused the need to have it added
> to specific projects. This is why I am perfectly happy with adding it to
> all the support projects in httpd, that really is about the only way to go
> (though I ran out of time to test a couple other ideas), that or simply
> link to the dll which already has it. It's also why I did not -1 this
> release. It's not a showstopper IMO.
>
> I'll however try to confirm tomorrow, for sure Wednesday. I realize that
> Wednesday goes beyond the 72 hours.
>
> Thanks for RMing BTW
>
>

Mime
View raw message