Build failed × 3: changed kvp_string(), .hpp/.h headers, MD5Init() et al

[jmarshall]

krb/libkrb.cpp:1271:41: error: too many arguments to function call, expected single argument '_kvp', have 2 arguments
irods::kvp_string( kvp, resp_str );

Presumably since irods/irods@ef65cbd.

krb/libkrb.cpp:1362:37: error: use of undeclared identifier 'parseUserName'
parseUserName( _resp->username, user…

Presumably since irods/irods@a153e90.

[jasoncoposky]

This plugin will be brought up to date, and have a new release shortly after iRODS 4.1 is released.
Thanks for the feedback.

[jmarshall]

Builds still failing (for slightly different though still trivial reasons), and the 4.1 release was 10 days ago…

[jasoncoposky]

we are still working to move all of the external plugins to the new Hudson CI cloud system.
a new release of all of the plugins can be expected in the next couple weeks.

fixed by #7

[jmarshall]

Thanks. It still fails when building against an in-place irods build, as the .hpp symlinks don't exist.

[jasoncoposky]

let me know how this works out.

also, what is your method for building krb using run-in-place?

[jmarshall]

Yes, that does the trick.

My build method is about the most brutal possible: I extracted the commands used to build libosauth.so from an irods/irods make log and made a script by applying s/osauth/krb/g pretty much. This dates from when I had my own hacked-up wrapper around iRODS's makefiles. Now that I am using an only mildly hacked-up packaging/build.sh, I should probably revisit this.

However as I'm using Kerberos authentication with our organisation's 3.3.x repository, I somewhat lost interest when I found that a 4.1.x client couldn't talk to a 3.3.x server at all. So for me, building 4.x is really only for testing purposes, against a native-authed test installation.