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 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.