Re: [VOTE] Release APR 1.5.2
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 libdll pass httpd-2.4.12 build regression Win Vista, VS 2008 x86, zip, retro build apr tests libdll 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). 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
Re: [VOTE] Release APR 1.5.2
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 libdll pass httpd-2.4.12 build regression Win Vista, VS 2008 x86, zip, retro build apr tests libdll 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 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.
Re: [VOTE] Release APR 1.5.2
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 libdll pass httpd-2.4.12 build regression Win Vista, VS 2008 x86, zip, retro build apr tests libdll 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
Re: [VOTE] Release APR 1.5.2
And I see this was then addressed an hour later - still learning nuances of gmail filtering and threading. Thanks again, Jeff :) Bill On Mon, Apr 27, 2015 at 11:00 PM, William A Rowe Jr wr...@rowe-clan.net wrote: I am searching and do not see a call for vote on APR until Gregg just replied.
Re: [VOTE] Release APR 1.5.2
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.). Yes, if you do a true retro build, e.g. consume the raw .lib objects and not the .dll's .lib, then things might not resolve at some point. Dynamic libraries are there for a reason. That's not entirely true, though. We can add #pragma hints to bring in specific external libraries for downstream consumers. Whether we want to do this or not for the consumer is another question, MS themself generally does not. I don't think this is a regression. If something needs a band-aid in the httpd binary, and doesn't affect replacing the underlying apr-1.dll with a fresh dll, and only impacts building older-httpd underneath newer-apr, I personally don't think it is a blocker. My 2c USD (which apparently is worth a lot more than it used to be, heh). Bill On Mon, Apr 27, 2015 at 11:02 PM, William A Rowe Jr wr...@rowe-clan.net wrote: And I see this was then addressed an hour later - still learning nuances of gmail filtering and threading. Thanks again, Jeff :) Bill On Mon, Apr 27, 2015 at 11:00 PM, William A Rowe Jr wr...@rowe-clan.net wrote: I am searching and do not see a call for vote on APR until Gregg just replied.
Re: [VOTE] Release APR 1.5.2
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 g...@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 libdll pass httpd-2.4.12 build regression Win Vista, VS 2008 x86, zip, retro build apr tests libdll 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
