9.3.0beta3 on Windows Feedback

Wesley Griffin wgriffin at sparta.com
Mon May 17 16:10:05 UTC 2004


On Fri, 2004-05-14 at 09:28, Danny Mayer wrote:
> >One suggestion, can the libdns.mak file be changed to look at C:\OPENSSL
> >for the OpenSSL libraries? The installation instructions for OpenSSL
> >already suggest that for an installation location, and it would mean not
> >being tied to a relative reference of ../../openssl-0.9.6k.
>=20
> That's been an issue for a while. With the versions of OpenSSL constantly=
=20
> changing,
> I needed to come up with general solutions that will figure out what the=20
> latest version
> available is (or ask) and then set it up properly.

That's cool, although just telling people to follow the OpenSSL install
instructions and install OpenSSL into C:\OPENSSL and hard-coding that
would probably work as well.

> >It also turns out that libdns would not link correctly until gdi32.lib
> >was added to the list of libs on the LINK command.
> >
> >Once I added gdi32.lib, I didn't see any compilation or link errors.
>=20
> That's odd, since neither VS 6.0 nor VS.Net needed it. Can you use depend=
s to
> see which dll requires it? gdi32 is a graphics library. so only BINDInsta=
ll=20
> might
> require it.

I ran depends on named.exe and found that gdi32 is listed numerous times
under advapi32. But that's the only place I could find it. Looking more
closely at the output (part of which I've inserted), it turns out
libeay32.lib has a function read_screen (in rand_win.c) that requires
gdi32. I'm not sure if I mentioned that I'm using OpenSSL 0.9.7d

Either way, without having gdi32.lib in libdns.mak, nothing links (with
the error messages below), adding gdi32.lib allows everything to link.

-----

        cd "..\..\dns\win32"
[cl lines snipped]
        cl.exe /nologo /MD /W3 /GX /O2 /I
"C:/OPENSSL/include/openssl/include" /I "./" /I "../../../" /I "include"
/I "../include" /I "../../isc/win32" /I "../../isc/win32/include" /I
"../../isc/
include" /I "../../dns/sec/dst/include" /I "C:/OPENSSL/include" /D
"NDEBUG" /D "WIN32" /D "_WINDOWS" /D "__STDC__" /D "_MBCS" /D "_USRDLL"
/D "USE_MD5" /D "OPENSSL" /D "DST_USE_PRIVATE_OPENSSL" /
D "LIBDNS_EXPORTS" /Fp".\Release\libdns.pch" /YX /Fo".\Release\\"
/Fd".\Release\\" /FD /c ..\sec\dst\opensslrsa_link.c
opensslrsa_link.c
        cl.exe @C:\WINDOWS\TEMP\nmD.tmp
DLLMain.c
version.c
        link.exe @C:\WINDOWS\TEMP\nmE.tmp
   Creating library .\Release\libdns.lib and object
.\Release\libdns.exp
libeay32.lib(rand_win.obj) : error LNK2019: unresolved external symbol
__imp__DeleteDC at 4 referenced in function _readscreen
libeay32.lib(rand_win.obj) : error LNK2019: unresolved external symbol
__imp__DeleteObject at 4 referenced in function _readscreen
libeay32.lib(rand_win.obj) : error LNK2019: unresolved external symbol
__imp__GetBitmapBits at 12 referenced in function _readscreen
libeay32.lib(rand_win.obj) : error LNK2019: unresolved external symbol
__imp__BitBlt at 36 referenced in function _readscreen
libeay32.lib(rand_win.obj) : error LNK2019: unresolved external symbol
__imp__GetObjectA at 12 referenced in function _readscreen
libeay32.lib(rand_win.obj) : error LNK2019: unresolved external symbol
__imp__SelectObject at 8 referenced in function _readscreen
libeay32.lib(rand_win.obj) : error LNK2019: unresolved external symbol
__imp__CreateCompatibleBitmap at 12 referenced in function _readscreen
libeay32.lib(rand_win.obj) : error LNK2019: unresolved external symbol
__imp__GetDeviceCaps at 8 referenced in function _readscreen
libeay32.lib(rand_win.obj) : error LNK2019: unresolved external symbol
__imp__CreateCompatibleDC at 4 referenced in function _readscreen
libeay32.lib(rand_win.obj) : error LNK2019: unresolved external symbol
__imp__CreateDCA at 16 referenced in function _readscreen
../../../Build/Release/libdns.dll : fatal error LNK1120: 10 unresolved
externals
NMAKE : fatal error U1077: 'link.exe' : return code '0x460'
Stop.

-----

> >Deployment was to Windows Server 2003 (Enterprise Edition, although I
> >doubt that matters). Without any additional software (i.e. OpenSSL or
> >Perl). It turns out I had to copy the MFC71.DLL and MSVCR71.DLL to the
> >server to get BINDInstall to run.
>=20
> Looks like that version changed the requirements from M*70.DLL to M*71.DL=
L
> which is what's in the configuration. Again can you check using depends?
> Does named require them?

Yep, named requires MSVCR71 and BINDInstall requires that and MFC71
according to depends. Mark, I've been unable to find where _MSC_VER is
defined, but I created a little program that just prints it out and I
get 1310, *not* 1400.

This isn't too big an issue to me, I just wanted to point it out. Would
it be possible to find out what version of the runtime is being used to
link against and then including the correct DLLs into the install
package?

> >I had to manually reset the named account password to something. I'm not
> >sure if the account had the password created or not, but the ISC BIND
> >service would not start until I had reset the password in the user
> >management console.
>=20
> BINDInstall creates the account with the password you provide.
> You also need need to set up the permissions on the directory where the=20
> configuration
> files live so that named can read and write the various files.

Yeah, I installed it a second time and noticed that there was a set of
text entry boxes in BINDInstall for the password. I'm not sure how I
managed to skip over those the first time.

The directory permissions I had actually managed to set correctly the
first time around :)


I snipped the other parts of the message about signzone and the check
utils, I'll get those under the debugger shortly.

> >Finally, dnssec-makekeyset and dnssec-signkey are still being built and
> >installed.
>=20
> Shouldn't they be?

On the unix side, they're not built at all. My understanding was that
with the move to DS, makekeyset and signkey are no longer needed.



More information about the bind-workers mailing list