[krbdev.mit.edu #8672] KFW 4.1 credential cache issue

[Hong Ye via RT]

Thanks Ben. Finally I built it successfully on a Windows 2008 R2 server. The latest release of strawberry Perl doesn't work. I have to use a version released in 2016. Also after install visual studio 2010 professional , I also need to install visual studio 2010 SP1 to get rid of a link error.

Now could you tell me how to enable the debug log? I might need to add debugging log in the source code, do you have a function for logging?

Thanks,
Hong

On 5/1/18, 6:38 AM, "Benjamin Kaduk via RT" <rt-comment at krbdev.mit.edu> wrote:

    I don't have that configuration on the machine in front of me, but from 
    memory, it was Windows 7 Enterprise (I used the subsystem for unix 
    applications to get awk/sed, but I understand the SUA was removed in a 
    later release), Visual Studio 2010 Professional, Strawberry Perl, and 
    Windows SDK 7.1.  (The perl 5.12.4 version you cite below seems a 
    rather old version, though I don't know for sure that that version is 
    old enough to cause problems.)
    
    -Ben
    
    
    [hy93 at cornell.edu - Mon Apr 30 13:11:42 2018]:
    
    > I first used Strawberry perl, it  gave me error when doing nmake -f
    > Makefile.in prep-windows . Then I used ActivateState perl, it
    > generated error when doing nmake.
    > 
    > What is the build environment that you can successfully build KFW 
    4.1?
    > 
    > Hong
    > 
    > 
    > On 4/29/18, 10:13 AM, "Benjamin Kaduk via RT" <rt-
    > comment at krbdev.mit.edu> wrote:
    > 
    >     [hy93 at cornell.edu - Thu Apr 26 09:25:58 2018]:
    > 
    >     > Thanks for your reply. I followed the instruction from the
    > README in
    >     > the source of the tarball. Here is my build environment:
    >     >
    >     > Windows 2012 R2
    >     > Microsoft visual studio 12.0
    >     > Windows SDK 8
    >     > Perl 5.12.4
    > 
    >     I don't have a whole lot of experience with VS 2013 (or access to
    > such
    >     a setup at the moment), but one common source of trouble is
    > ensuring
    >     that all the moving pieces agree on whether 32- or 64-bit code is
    > being
    >     built (and potentially also what processor architecture).  This
    >     includes at least the way that the cmd.exe shell is spawned 
    and/or
    >     initialized, and the value of the CPU environment variable.  The
    > build
    >     log snippet implies that something is trying to build 64-bit code
    > (the
    >     "obj/AMD64" in the path to libecho), but I note that the README
    >     instructions start off by building the 32-bit code.  (It's okay 
    to
    > just
    >     build the 64-bit code and not the 32-bit code for local testing;
    > the
    >     32-bit build is included in the instructions there so that the 
    32-
    > bit
    >     libraries can be included in the 64-bit MSI installer.)
    > 
    >     Separately, sometimes the source of the perl binary can be
    > relevant --
    >     do you have Strawberry Perl, ActiveState Perl, or something else?
    > 
    >