[15973] in Kerberos-V5-bugs
[krbdev.mit.edu #8672] KFW 4.1 credential cache issue
daemon@ATHENA.MIT.EDU (Benjamin Kaduk via RT)
Sun Apr 29 10:13:18 2018
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Benjamin Kaduk via RT" <rt-comment@KRBDEV-PROD-APP-1.mit.edu>
In-Reply-To: <rt-8672@krbdev.mit.edu>
Message-ID: <rt-8672-48457.2.58991976568034@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #8672'":;
Date: Sun, 29 Apr 2018 10:13:06 -0400 (EDT)
Reply-To: rt-comment@KRBDEV-PROD-APP-1.mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
[hy93@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?
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
