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 <[email protected]> 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 > >
