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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson via RT-2
[[hidden email] - 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
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson via RT-2
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" <[hidden email]> wrote:

    [[hidden email] - 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
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs