Still trying to get the master branch to compile on AIX 6.1.&n= bsp; I've gotten through a number of hurdles, but I'm stuck on this one:

/bin/sh ../../libtool --quiet --mode=3Dli= nk --tag=3DCC xlc_r -static -L/project/openafs/lib -L/project= /openafs/lib -O -DRXDEBUG -DFSSYNC_BUILD_SERVER -DSALVSYNC_BUIL= D_CLIENT -O -K -D_NONSTD_TYPES -D_MBI=3Dvoid -I/project/opena= fs/src/config -I/project/openafs/include -I. -I. -DAFS_PTHREAD_ENV -o fileserver v= iced.o afsfileprocs.o host.o physio.o callback.o serialize_state.o fs= stats.o buffer.o dir.o salvage.o vnode.o volume.o vutil.o partition.o fssyn= c-server.o clone.o devname.o common.o ihandle.o listinodes.o namei_ops.o salvsync-client.o daemon_com.o vg_cache.o vg_scan.o afsi= nt.ss.o ../../src/vlserver/liboafs_vldb.la ../../src/rxkad/libo= afs_rxkad.la ../../src/rxstat/liboafs_rxstat.la ../../src/lwp/l= iboafs_lwpcompat.la ../../src/libacl/liboafs_acl.la ../../src/f= sint/liboafs_fsint.la ../../src/cmd/liboafs_cmd.la ../../src/opr/liboafs_opr.la &nbs= p;../../src/util/liboafs_util.la -lafshcrypto -lrokenafs -lpthread -ldl

ld: 0711-224 WARNING: Duplicate symbol: .icreate

ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more info= rmation.

ld: 0711-317 ERROR: Undefined symbol: .RXAFS_OpCodeIndex

make: 1254-004 The error code from the last command is 8.

Where does RXAFS_OpCodeIndex even come from? It's in the= object file afsfileprocs.o, but not in afsfileprocs.c. Any hints at = where I should start looking would be appreciated.

Thank you!

-Ben

--_000_MWHPR0701MB3674FD012C613B3CB79B6EA5A7669MWHPR0701MB3674_-- From kaduk@mit.edu Sat Aug 13 21:47:58 2022 From: kaduk@mit.edu (Benjamin Kaduk) Date: Sat, 13 Aug 2022 13:47:58 -0700 Subject: [OpenAFS-devel] AIX build fails with missing symbol .RXAFS_OpCodeIndex In-Reply-To: References: Message-ID: <20220813204758.GL24514@kduck.mit.edu> On Sat, Aug 13, 2022 at 08:09:55PM +0000, Ben Huntsman wrote: > Hi guys- > Still trying to get the master branch to compile on AIX 6.1. I've gotten through a number of hurdles, but I'm stuck on this one: > > /bin/sh ../../libtool --quiet --mode=link --tag=CC xlc_r -static -L/project/openafs/lib -L/project/openafs/lib -O -DRXDEBUG -DFSSYNC_BUILD_SERVER -DSALVSYNC_BUILD_CLIENT -O -K -D_NONSTD_TYPES -D_MBI=void -I/project/openafs/src/config -I/project/openafs/include -I. -I. -DAFS_PTHREAD_ENV -o fileserver viced.o afsfileprocs.o host.o physio.o callback.o serialize_state.o fsstats.o buffer.o dir.o salvage.o vnode.o volume.o vutil.o partition.o fssync-server.o clone.o devname.o common.o ihandle.o listinodes.o namei_ops.o salvsync-client.o daemon_com.o vg_cache.o vg_scan.o afsint.ss.o ../../src/vlserver/liboafs_vldb.la ../../src/rxkad/liboafs_rxkad.la ../../src/rxstat/liboafs_rxstat.la ../../src/lwp/liboafs_lwpcompat.la ../../src/libacl/liboafs_acl.la ../../src/fsint/liboafs_fsint.la ../../src/cmd/liboafs_cmd.la ../../src/opr/liboafs_opr.la ../../src/util/liboafs_util.la -lafshcrypto -lrokenafs -lpthread -ldl > ld: 0711-224 WARNING: Duplicate symbol: .icreate > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. > ld: 0711-317 ERROR: Undefined symbol: .RXAFS_OpCodeIndex > make: 1254-004 The error code from the last command is 8. > > > Where does RXAFS_OpCodeIndex even come from? It's in the object file afsfileprocs.o, but not in afsfileprocs.c. Any hints at where I should start looking would be appreciated. The RXAFS prefix indicates that it relates to the Rx RPC procedures, that have C code generated during the build process using the rxgen tool (a fork of rpcgen). It may well be that that symbol needs to be added to the export list in src/fsint/liboafs_fsint.la.sym; IIRC AIX is one of the few platforms that heeds the export list even when statically linking. -Ben From ben@huntsmans.net Sun Aug 14 07:23:53 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Sun, 14 Aug 2022 06:23:53 +0000 Subject: [OpenAFS-devel] AIX build fails with missing symbol .RXAFS_OpCodeIndex In-Reply-To: <20220813204758.GL24514@kduck.mit.edu> References: <20220813204758.GL24514@kduck.mit.edu> Message-ID: --_000_MWHPR0701MB3674AC00364E0CA371D501CFA7699MWHPR0701MB3674_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there! Yep, adding it to src/fsint/liboafs_fsint.la.sym indeed resolved that. = On to the next error... Thanks! -Ben ________________________________ From: Benjamin Kaduk Sent: Saturday, August 13, 2022 1:47 PM To: Ben Huntsman Cc: openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .RXAFS_OpC= odeIndex On Sat, Aug 13, 2022 at 08:09:55PM +0000, Ben Huntsman wrote: > Hi guys- > Still trying to get the master branch to compile on AIX 6.1. I've got= ten through a number of hurdles, but I'm stuck on this one: > > /bin/sh ../../libtool --quiet --mode=3Dlink --tag=3DCC xlc_r -= static -L/project/openafs/lib -L/project/openafs/lib -O -DRXDEBUG -DFSS= YNC_BUILD_SERVER -DSALVSYNC_BUILD_CLIENT -O -K -D_NONSTD_TYPES -D_MBI=3Dv= oid -I/project/openafs/src/config -I/project/openafs/include -I. -I. = -DAFS_PTHREAD_ENV -o fileserver viced.o afsfileprocs.o host.o physio.o = callback.o serialize_state.o fsstats.o buffer.o dir.o salvage.o vnode.o vo= lume.o vutil.o partition.o fssync-server.o clone.o devname.o common.o ihan= dle.o listinodes.o namei_ops.o salvsync-client.o daemon_com.o vg_cache.o v= g_scan.o afsint.ss.o ../../src/vlserver/liboafs_vldb.la ../../src/rxkad/l= iboafs_rxkad.la ../../src/rxstat/liboafs_rxstat.la ../../src/lwp/liboafs_= lwpcompat.la ../../src/libacl/liboafs_acl.la ../../src/fsint/liboafs_fsin= t.la ../../src/cmd/liboafs_cmd.la ../../src/opr/liboafs_opr.la ../../src= /util/liboafs_util.la -lafshcrypto -lrokenafs -lpthread -ldl > ld: 0711-224 WARNING: Duplicate symbol: .icreate > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more informa= tion. > ld: 0711-317 ERROR: Undefined symbol: .RXAFS_OpCodeIndex > make: 1254-004 The error code from the last command is 8. > > > Where does RXAFS_OpCodeIndex even come from? It's in the object file = afsfileprocs.o, but not in afsfileprocs.c. Any hints at where I should sta= rt looking would be appreciated. The RXAFS prefix indicates that it relates to the Rx RPC procedures, that have C code generated during the build process using the rxgen tool (a fork of rpcgen). It may well be that that symbol needs to be added to the export list in src/fsint/liboafs_fsint.la.sym; IIRC AIX is one of the few platforms that heeds the export list even when statically linking. -Ben --_000_MWHPR0701MB3674AC00364E0CA371D501CFA7699MWHPR0701MB3674_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there!

Yep, adding it to src/fsint/liboafs_fsint.la.sym indeed r= esolved that. On to the next error...

Thanks!

-Ben

From: Benjamin Kaduk <ka= duk@mit.edu>
Sent: Saturday, August 13, 2022 1:47 PM
To: Ben Huntsman <ben@huntsmans.net>
Cc: openafs-devel@openafs.org <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .RX= AFS_OpCodeIndex

On Sat, Aug 13, 2022 at 08:09:55PM +0000, Ben Hunt= sman wrote:
> Hi guys-
>    Still trying to get the master branch to compile on = AIX 6.1. I've gotten through a number of hurdles, but I'm stuck on th= is one:
>
>          /bin/sh ../../li= btool --quiet --mode=3Dlink --tag=3DCC   xlc_r -static  = ; -L/project/openafs/lib -L/project/openafs/lib -O -DRXDEBUG -D= FSSYNC_BUILD_SERVER -DSALVSYNC_BUILD_CLIENT   -O -K -D_NONSTD_TYP= ES -D_MBI=3Dvoid   -I/project/openafs/src/config -I/project/opena= fs/include -I. -I.      -DAFS_PTHREAD_ENV   -o fil= eserver viced.o afsfileprocs.o host.o physio.o callback.o serialize_state.o= fsstats.o buffer.o dir.o salvage.o vnode.o volume.o vutil.o partitio= n.o fssync-server.o clone.o devname.o common.o ihandle.o listinodes.o= namei_ops.o salvsync-client.o daemon_com.o vg_cache.o vg_scan.o afsint.ss.o ../.= ./src/vlserver/liboafs_vldb.la ../../src/rxkad/liboafs_rxkad.la = ../../src/rxstat/liboafs_rxstat.la ../../src/lwp/liboafs_lwpcompat.l= a ../../src/libacl/liboafs_acl.la ../../src/fsint/liboafs_fsint= .la ../../src/cmd/liboafs_cmd.la ../../src/opr/liboafs_opr.la ../.= ./src/util/liboafs_util.la -lafshcrypto -lrokenafs -lpthread -ldl
> ld: 0711-224 WARNING: Duplicate symbol: .icreate
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more info= rmation.
> ld: 0711-317 ERROR: Undefined symbol: .RXAFS_OpCodeIndex
> make: 1254-004 The error code from the last command is 8.
>
>
>    Where does RXAFS_OpCodeIndex even come from? I= t's in the object file afsfileprocs.o, but not in afsfileprocs.c. Any= hints at where I should start looking would be appreciated.

The RXAFS prefix indicates that it relates to the Rx RPC procedures, that have C code generated during the build process using the rxgen tool (a fork=
of rpcgen).
It may well be that that symbol needs to be added to the export list in
src/fsint/liboafs_fsint.la.sym; IIRC AIX is one of the few platforms that heeds the export list even when statically linking.

-Ben

--_000_MWHPR0701MB3674AC00364E0CA371D501CFA7699MWHPR0701MB3674_-- From ben@huntsmans.net Sun Aug 14 07:31:35 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Sun, 14 Aug 2022 06:31:35 +0000 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key Message-ID: --_000_MWHPR0701MB3674796EE70642DF77484A14A7699MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi guys- Sorry for the spam of late but thank you to everyone who's helped so far= . Great progress is being made! Currently, it's failing on aklog. Here's the output: + cd aklog + make all /bin/sh ../../libtool --quiet --mode=3Dlink --tag=3DCC xlc_r -st= atic -L/opt/freeware/lib -L/project/openafs/lib -L/project/openafs/lib -O= -I/opt/freeware/include -DALLOW_REGISTER -O -K -D_NONSTD_TYPES -D_MBI= =3Dvoid -I/project/openafs/src/config -I/project/openafs/include -I. -I.= -DAFS_PTHREAD_ENV -o asetkey asetkey.o -L/opt/freeware/lib -lkrb5 = -lcom_err -lkrb5support ../../src/ptserver/liboafs_prot.la ../../src/rxk= ad/liboafs_rxkad.la ../../src/cmd/liboafs_cmd.la ../../src/opr/liboafs_op= r.la ../../src/util/liboafs_util.la -L/project/openafs/lib -lafshcrypto -L= /project/openafs/lib -lrokenafs -lpthread -ldl ld: 0711-317 ERROR: Undefined symbol: .krb5_c_make_random_key ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more informati= on. make: 1254-004 The error code from the last command is 8. There is a changeset https://gerrit.openafs.org/#/c/10107/ that looks like = a substantially similar build failure, except on Linux. However, that's a = pretty old change and it would appear that this code worked on AIX more rec= ently. One thing to note, I'm using the krb5 from the AIX Linux Toolbox, a= nd krb5.a is in /opt/freeware/lib. nm shows that it indeed has that symbol= in it, and it's there on the command line... Do most AIX users typically = use the AIX Linux Toolbox kerberos, or a different implementation? Thanks again! -Ben Gerrit Code Review - OpenAFS ID: Subject: Status: Owner: Project: Branch: Updated: Size: CR: V: 15085: v= iced: Keep host locked after h_Lookup_r: Merge Conflict gerrit.openafs.org --_000_MWHPR0701MB3674796EE70642DF77484A14A7699MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi guys-

Sorry for the spam of late but thank you to everyone who's hel= ped so far. Great progress is being made!

Currently, it's failing on aklog. Here's the output:

+ cd aklog

+ make all

/bin/sh ../../libtool --quiet --mode= =3Dlink --tag=3DCC xlc_r -static -L/opt/freeware/lib -L/projec= t/openafs/lib -L/project/openafs/lib -O -I/opt/freeware/include= -DALLOW_REGISTER -O -K -D_NONSTD_TYPES -D_MBI=3Dvoid -I/proj= ect/openafs/src/config -I/project/openafs/include -I. -I. -DAFS_PTHREAD= _ENV -o asetkey asetkey.o -L/opt/freeware/lib -lkrb5 -lcom_err= -lkrb5support ../../src/ptserver/liboafs_prot.la ../../src/rx= kad/liboafs_rxkad.la ../../src/cmd/liboafs_cmd.la ../../src/opr= /liboafs_opr.la ../../src/util/liboafs_util.la -L/project/openafs/lib -lafshcrypto -= L/project/openafs/lib -lrokenafs -lpthread -ldl

ld: 0711-317 ERROR: Undefined symbol: .krb5_c_make_random_key

ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more info= rmation.

make: 1254-004 The error code from the last command is 8.

There is a changeset https://gerrit.openafs.org/#/c/10107/ = that looks like a substantially similar build failure, except on Linux.&nbs= p; However, that's a pretty old change and it would appear that this code worked on AIX more recently. One thing to note= , I'm using the krb5 from the AIX Linux Toolbox, and krb5.a is in /opt/free= ware/lib. nm shows that it indeed has that symbol in it, and it's the= re on the command line... Do most AIX users typically use the AIX Linux Toolbox kerberos, or a different implementatio= n?

Thanks again!

-Ben

Gerrit Code Review - OpenAFS

ID: Subject: Status: Owner: Project: Branch: Updated: Size: CR: V: 15085: v= iced: Keep host locked after h_Lookup_r: Merge Conflict

gerrit.openafs.org

--_000_MWHPR0701MB3674796EE70642DF77484A14A7699MWHPR0701MB3674_-- From jaltman@auristor.com Sun Aug 14 11:32:10 2022 From: jaltman@auristor.com (Jeffrey E Altman) Date: Sun, 14 Aug 2022 06:32:10 -0400 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: References: Message-ID: <1f280abd-8cf4-f6e0-3774-22f3af8f82c2@auristor.com> This is a cryptographically signed message in MIME format. --------------ms030007060301020009050607 Content-Type: multipart/alternative; boundary="------------74dtifnekXPQ7xP3Rd0oD00p" --------------74dtifnekXPQ7xP3Rd0oD00p Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/14/2022 2:31 AM, Ben Huntsman (ben@huntsmans.net) wrote: > There is a changeset https://gerrit.openafs.org/#/c/10107/ that looks > like a substantially similar build failure, except on Linux. However, > that's a pretty old change and it would appear that this code worked > on AIX more recently. One thing to note, I'm using the krb5 from the > AIX Linux Toolbox, and krb5.a is in /opt/freeware/lib. nm shows that > it indeed has that symbol in it, and it's there on the command > line... Do most AIX users typically use the AIX Linux Toolbox > kerberos, or a different implementation? > Look for a more recent MIT Kerberos. --------------74dtifnekXPQ7xP3Rd0oD00p Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 8/14/2022 2:31 AM, Ben Huntsman (ben@huntsmans.net) wrote:

There is a changeset https://gerrit.openafs.org/#/c/10107/ that looks like a substantially similar build failure, except on Linux. However, that's a pretty old change and it would appear that this code worked on AIX more recently. One thing to note, I'm using the krb5 from the AIX Linux Toolbox, and krb5.a is in /opt/freeware/lib. nm shows that it indeed has that symbol in it, and it's there on the command line... Do most AIX users typically use the AIX Linux Toolbox kerberos, or a different implementation?

Look for a more recent MIT Kerberos.

--------------74dtifnekXPQ7xP3Rd0oD00p-- --------------ms030007060301020009050607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DHEwggXSMIIEuqADAgECAhBAAYJpmi/rPn/F0fJyDlzMMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEz MB4XDTIyMDgwNDE2MDQ0OFoXDTI1MTAzMTE2MDM0OFowcDEvMC0GCgmSJomT8ixkAQETH0Ew MTQxMEQwMDAwMDE4MjY5OUEyRkQyMDAwMjMzQ0QxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRt YW4xFTATBgNVBAoTDEF1cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCkC7PKBBZnQqDKPtZPMLAy77zo2DPvwtGnd1hNjPvbXrpGxUb3 xHZRtv179LHKAOcsY2jIctzieMxf82OMyhpBziMPsFAG/ukihBMFj3/xEeZVso3K27pSAyyN fO/wJ0rX7G+ges22Dd7goZul8rPaTJBIxbZDuaykJMGpNq4PQ8VPcnYZx+6b+nJwJJoJ46kI EEfNh3UKvB/vM0qtxS690iAdgmQIhTl+qfXq4IxWB6b+3NeQxgR6KLU4P7v88/tvJTpxIKkg 9xj89ruzeThyRFd2DSe3vfdnq9+g4qJSHRXyTft6W3Lkp7UWTM4kMqOcc4VSRdufVKBQNXjG IcnhAgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAwgYQGCCsGAQUFBwEBBHgwdjAwBggr BgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUF BzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWEx My5wN2MwHwYDVR0jBBgwFoAULbfeG1l+KpguzeHUG+PFEBJe6RQwCQYDVR0TBAIwADCCASsG A1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIBFj5odHRwczov L3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRt bDCBugYIKwYBBQUHAgIwga0MgapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4g aXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRp ZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8v dmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTMuY3JsMB8GA1UdEQQY MBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBQB+nzqgljLocLTsiUn2yWqEc2s gjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJwV eycprp8Ox1npiTyfwc5QaVaqtoe8Dcg2JXZc0h4DmYGW2rRLHp8YL43snEV93rPJVk6B2v4c WLeQfaMrnyNeEuvHx/2CT44cdLtaEk5zyqo3GYJYlLcRVz6EcSGHv1qPXgDT0xB/25etwGYq utYF4Chkxu4KzIpq90eDMw5ajkexw+8ARQz4N5+d6NRbmMCovd7wTGi8th/BZvz8hgKUiUJo Qle4wDxrdXdnIhCP7g87InXKefWgZBF4VX21t2+hkc04qrhIJlHrocPG9mRSnnk2WpsY0MXt a8ivbVKtfpY7uSNDZSKTDi1izEFH5oeQdYRkgIGb319a7FjslV8wggaXMIIEf6ADAgECAhBA AXA7OrqBjMk8rp4OuNQSMA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK EwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAe Fw0yMDAyMTIyMTA3NDlaFw0zMDAyMTIyMTA3NDlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK EwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAu6sUO01SDD99PM+QdZkNxKxJNt0NgQE+Zt6ixaNP0JKSjTd+SG5L wqxBWjnOgI/3dlwgtSNeN77AgSs+rA4bK4GJ75cUZZANUXRKw/et8pf9Qn6iqgB63OdHxBN/ 15KbM3HR+PyiHXQoUVIevCKW8nnlWnnZabT1FejOhRRKVUg5HACGOTfnCOONrlxlg+m1Vjgn o1uNqNuLM/jkD1z6phNZ/G9IfZGI0ppHX5AA/bViWceX248VmefNhSR14ADZJtlAAWOi2un0 3bqrBPHA9nDyXxI8rgWLfUP5rDy8jx2hEItg95+ORF5wfkGUq787HBjspE86CcaduLka/Bk2 VwIDAQABo4IChzCCAoMwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwgYkG CCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVu dHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t L3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C 5yZUyI42djCCASQGA1UdIASCARswggEXMIIBEwYEVR0gADCCAQkwSgYIKwYBBQUHAgEWPmh0 dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRl eC5odG1sMIG6BggrBgEFBQcCAjCBrQyBqlRoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMg YmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIElkZW5UcnVzdCdzIFRydXN0SUQgQ2Vy dGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20v Y2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEoGA1UdHwRDMEEwP6A9oDuGOWh0 dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL2NvbW1lcmNpYWxyb290Y2ExLmNy bDAdBgNVHQ4EFgQULbfeG1l+KpguzeHUG+PFEBJe6RQwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4ICAQB/7BKcygLX6Nl4a03cDHt7TLdPxCzFvDF2 bkVYCFTRX47UfeomF1gBPFDee3H/IPlLRmuTPoNt0qjdpfQzmDWN95jUXLdLPRToNxyaoB5s 0hOhcV6H08u3FHACBif55i0DTDzVSaBv0AZ9h1XeuGx4Fih1Vm3Xxz24GBqqVudvPRLyMJ7u 6hvBqTIKJ53uCs3dyQLZT9DXnp+kJv8y7ZSAY+QVrI/dysT8avtn8d7k7azNBkfnbRq+0e88 QoBnel6u+fpwbd5NLRHywXeH+phbzULCa+bLPRMqJaW2lbhvSWrMHRDy3/d8HvgnLCBFK2s4 Spns4YCN4xVcbqlGWzgolHCKUH39vpcsDo1ymZFrJ8QR6ihIn8FmJ5oKwAnnd/G6ADXFC9bu db9+532phSAXOZrrecIQn+vtP366PC+aClAPsIIDJDsotS5z4X2JUFsNIuEgXGqhiKE7SuZb rFG9sdcLprSlJN7TsRDc0W2b9nqwD+rj/5MN0C+eKwha+8ydv0+qzTyxPP90KRgaegGowC4d UsZyTk2n4Z3MuAHX5nAZL/Vh/SyDj/ajorV44yqZBzQ3ChKhXbfUSwe2xMmygA2Z5DRwMRJn p/BscizYdNk2WXJMTnH+wVLN8sLEwEtQR4eTLoFmQvrK2AMBS9kW5sBkMzINt/ZbbcZ3F+eA MDGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUG A1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwDQYJYIZIAWUDBAIBBQCg ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgxNDEw MzIxMFowLwYJKoZIhvcNAQkEMSIEIP3gD73CMz7VdGAwerRnI7Ul6Ceth9X14tJekhRm1W/a MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAZtH6 +HuMKskO9QBeMO51WpdcKHv0Bcq8YaFUaG3QLAWtebkwQMwurWlO1yLgOE1jb4wmB+RiTOji BBAlLXtkpf7YIGwlDR0r1jZMIvydx1OV386IgQwel8T3tabDdj/JS8+9zmjKMQWLml0Nz05k 7/orE/KX7PfLrFRAHhqFx7r/g5pJfYsaFqs7+6wSi0FiPtkMU5SxV8FNMc4/F8dQzA/qsr3+ kKH1/PGW2+SUkm6rbnwdSJCOIXIuh1RTuEl6e1htiZnAEH5+n+WJB1xrLco9RBkYxAvp6vYF 7e6eF878t0JdtSXpzvqf7EaE2FI2YA4okRZLDBSJBB0ffhiWEAAAAAAAAA== --------------ms030007060301020009050607-- From ben@huntsmans.net Sun Aug 14 17:53:27 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Sun, 14 Aug 2022 16:53:27 +0000 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key Message-ID: --_000_MWHPR0701MB3674C0C1B88BCAE53F506B78A7699MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there! Thanks for the reply. I have installed MIT Kerberos 1.18.4, the latest that IBM supplies in it= s AIX Toolbox for Linux. The current version on MIT's website is 1.20. Wh= at version is the minimum required for OpenAFS? Like I said though, nm shows that the libkrb5.a library has the symbol i= n question in it, so I'm not quite sure how providing a newer version would= alter the outcome... Thank you. -Ben ________________________________ From: Jeffrey E Altman Sent: Sunday, August 14, 2022 3:32 AM To: Ben Huntsman; openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_ma= ke_random_key On 8/14/2022 2:31 AM, Ben Huntsman (ben@huntsmans.net) wrote: There is a changeset https://gerrit.openafs.org/#/c/10107/ that looks like = a substantially similar build failure, except on Linux. However, that's a = pretty old change and it would appear that this code worked on AIX more rec= ently. One thing to note, I'm using the krb5 from the AIX Linux Toolbox, a= nd krb5.a is in /opt/freeware/lib. nm shows that it indeed has that symbol= in it, and it's there on the command line... Do most AIX users typically = use the AIX Linux Toolbox kerberos, or a different implementation? Look for a more recent MIT Kerberos. --_000_MWHPR0701MB3674C0C1B88BCAE53F506B78A7699MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi there!

Thanks for the reply.

I have installed MIT Kerberos 1.18.4, the latest that IBM supp= lies in its AIX Toolbox for Linux. The current version on MIT's websi= te is 1.20. What version is the minimum required for OpenAFS?

Like I said though, nm shows that the libkrb5.a library has th= e symbol in question in it, so I'm not quite sure how providing a newer ver= sion would alter the outcome...

Thank you.

-Ben

From: Jeffrey E Altman
Sent: Sunday, August 14, 2022 3:32 AM
To: Ben Huntsman; openafs-devel@openafs.org
Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .kr= b5_c_make_random_key

On 8/14/2022 2:31 AM, Ben Huntsman (ben@hunt= smans.net) wrote:

There is a changeset https://gerrit= .openafs.org/#/c/10107/ that looks like a substantially similar build failure, except on Linux. However, that's a pretty old= change and it would appear that this code worked on AIX more recently.&nbs= p; One thing to note, I'm using the krb5 from the AIX Linux Toolbox, and kr= b5.a is in /opt/freeware/lib. nm shows that it indeed has that symbol in it, and it's there on the command line...&nbs= p; Do most AIX users typically use the AIX Linux Toolbox kerberos, or a dif= ferent implementation?

Look for a more recent MI= T Kerberos.

--_000_MWHPR0701MB3674C0C1B88BCAE53F506B78A7699MWHPR0701MB3674_-- From kenh@cmf.nrl.navy.mil Sun Aug 14 18:25:24 2022 From: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Sun, 14 Aug 2022 13:25:24 -0400 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: References: Message-ID: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> > Like I said though, nm shows that the libkrb5.a library has the > symbol in question in it, so I'm not quite sure how providing a > newer version would alter the outcome... Are you _sure_ that libkrb5.a has that symbol in it, and it's not just an undefined reference to the symbol? On my system (using MIT krb5 1.19) krb5_c_make_random_key is in libk5crypto, and I noticed that library is not in your link command (there are references to krb5_c_make_random_key in libkrb5, but no symbol definition). --Ken From ben@huntsmans.net Sun Aug 14 19:46:00 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Sun, 14 Aug 2022 18:46:00 +0000 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> References: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> Message-ID: --_000_MWHPR0701MB36743D74D14311A20D2B3F03A7699MWHPR0701MB3674_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ken- Ah, yes, I believe you are right. That library does exist on my system als= o, and I manually added it to Makefile.config and the build continued. The= question is then, why didn't ./configure detect it and add it? I think this is the problem: $ grep md5 config.log configure:41845: checking for krb5int_hash_md5 in -lk5crypto ld: 0711-317 ERROR: Undefined symbol: .krb5int_hash_md5 | char krb5int_hash_md5 (); | return krb5int_hash_md5 (); configure:48734: checking for krb5int_hash_md5 in -lk5crypto ac_cv_lib_k5crypto_krb5int_hash_md5=3Dno $ nm /opt/freeware/lib/libk5crypto.a | grep md5 .EVP_md5 T 268449356 .EVP_md5 t 268449356 40 .hash_md5 t 268450036 120 .krb5int_hmacmd5_checksum T 268481192 892 EVP_md5 U - EVP_md5 d 536875224 4 _checksumhmacmd5.rop_ t 268504960 13 checksum_hmac_md5.c f - hash_md5 d 536873496 12 hash_md5:f821 - 520 krb5int_hash_md5 D 536871692 krb5int_hash_md5 d 536875384 4 krb5int_hash_md5:G1628 - 60 krb5int_hmacmd5_checksum D 536874036 krb5int_hmacmd5_checksum d 536874036 12 krb5int_hmacmd5_checksum:F821 - 0 For some reason, the check for if we should add -lk5crypto is failing. The= re's a krb5int_hash_md5 but not a .krb5int_hash_md5. Should we check for s= omething else on AIX? Thank you. -Ben ________________________________ From: Ken Hornstein Sent: Sunday, August 14, 2022 10:25 AM To: Ben Huntsman Cc: openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_ma= ke_random_key > Like I said though, nm shows that the libkrb5.a library has the > symbol in question in it, so I'm not quite sure how providing a > newer version would alter the outcome... Are you _sure_ that libkrb5.a has that symbol in it, and it's not just an undefined reference to the symbol? On my system (using MIT krb5 1.19) krb5_c_make_random_key is in libk5crypto, and I noticed that library is not in your link command (there are references to krb5_c_make_random_key in libkrb5, but no symbol definition). --Ken --_000_MWHPR0701MB36743D74D14311A20D2B3F03A7699MWHPR0701MB3674_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ken-

Ah, yes, I believe you are right. That library does exist on my syste= m also, and I manually added it to Makefile.config and the build continued.= The question is then, why didn't ./configure detect it and add it?

I think this is the problem:

$ grep md5 config.log

configure:41845: checking for krb5int_hash_md5 in -lk5crypto

ld: 0711-317 ERROR: Undefined symbol: .krb5int_hash_md5

| char krb5int_hash_md5 ();

| return krb5int_hash_md5 ();

configure:48734: checking for krb5int_hash_md5 in -lk5crypto

ac_cv_lib_k5crypto_krb5int_hash_md5=3Dno

$ nm /opt/freeware/lib/libk5crypto.a | grep md5

.EVP_md5 T 268449356<= /div>

.EVP_md5 t 268449356 = 40

.hash_md5 t 268450036 = 120

.krb5int_hmacmd5_checksum T 268481192 &nbs= p; 892

EVP_md5 U = ; -

EVP_md5 d 53687= 5224 4

_checksumhmacmd5.rop_ t 268504960 &= nbsp;13

checksum_hmac_md5.c f -

hash_md5 d 536873496 = 12

hash_md5:f821 - = 520

krb5int_hash_md5 D 536871692

krb5int_hash_md5 d 536875384 = 4

krb5int_hash_md5:G1628 - 60

krb5int_hmacmd5_checksum D 536874036

krb5int_hmacmd5_checksum d 536874036 = ; 12

krb5int_hmacmd5_checksum:F821 - 0

For some reason, the check for if we should add -lk5crypto is failing. = ; There's a krb5int_hash_md5 but not a .krb5int_hash_md5. Should we check for something else on AIX?

Thank you.

-Ben

From: Ken Hornstein <ken= h@cmf.nrl.navy.mil>
Sent: Sunday, August 14, 2022 10:25 AM
To: Ben Huntsman <ben@huntsmans.net>
Cc: openafs-devel@openafs.org <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .kr= b5_c_make_random_key

>   Like I said though, nm shows that= the libkrb5.a library has the
>   symbol in question in it, so I'm not quite sure how provid= ing a
>   newer version would alter the outcome...

Are you _sure_ that libkrb5.a has that symbol in it, and it's not just
an undefined reference to the symbol? On my system (using MIT krb5 1.= 19)
krb5_c_make_random_key is in libk5crypto, and I noticed that library is
not in your link command (there are references to krb5_c_make_random_key in libkrb5, but no symbol definition).

--Ken

--_000_MWHPR0701MB36743D74D14311A20D2B3F03A7699MWHPR0701MB3674_-- From kaduk@mit.edu Sun Aug 14 19:53:31 2022 From: kaduk@mit.edu (Benjamin Kaduk) Date: Sun, 14 Aug 2022 11:53:31 -0700 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: References: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> Message-ID: <20220814185331.GM24514@kduck.mit.edu> Do you have a krb5-config script (or pkgconfig files) for your kerberos installation? Looking at more of what configure had to say about krb5 detection, and possibly passing --with-krb5* of some form, might help. -Ben On Sun, Aug 14, 2022 at 06:46:00PM +0000, Ben Huntsman wrote: > Hi Ken- > > Ah, yes, I believe you are right. That library does exist on my system also, and I manually added it to Makefile.config and the build continued. The question is then, why didn't ./configure detect it and add it? > > I think this is the problem: > > $ grep md5 config.log > configure:41845: checking for krb5int_hash_md5 in -lk5crypto > ld: 0711-317 ERROR: Undefined symbol: .krb5int_hash_md5 > | char krb5int_hash_md5 (); > | return krb5int_hash_md5 (); > configure:48734: checking for krb5int_hash_md5 in -lk5crypto > ac_cv_lib_k5crypto_krb5int_hash_md5=no > $ nm /opt/freeware/lib/libk5crypto.a | grep md5 > .EVP_md5 T 268449356 > .EVP_md5 t 268449356 40 > .hash_md5 t 268450036 120 > .krb5int_hmacmd5_checksum T 268481192 892 > EVP_md5 U - > EVP_md5 d 536875224 4 > _checksumhmacmd5.rop_ t 268504960 13 > checksum_hmac_md5.c f - > hash_md5 d 536873496 12 > hash_md5:f821 - 520 > krb5int_hash_md5 D 536871692 > krb5int_hash_md5 d 536875384 4 > krb5int_hash_md5:G1628 - 60 > krb5int_hmacmd5_checksum D 536874036 > krb5int_hmacmd5_checksum d 536874036 12 > krb5int_hmacmd5_checksum:F821 - 0 > > > For some reason, the check for if we should add -lk5crypto is failing. There's a krb5int_hash_md5 but not a .krb5int_hash_md5. Should we check for something else on AIX? > > Thank you. > > -Ben > > > ________________________________ > From: Ken Hornstein > Sent: Sunday, August 14, 2022 10:25 AM > To: Ben Huntsman > Cc: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key > > > Like I said though, nm shows that the libkrb5.a library has the > > symbol in question in it, so I'm not quite sure how providing a > > newer version would alter the outcome... > > Are you _sure_ that libkrb5.a has that symbol in it, and it's not just > an undefined reference to the symbol? On my system (using MIT krb5 1.19) > krb5_c_make_random_key is in libk5crypto, and I noticed that library is > not in your link command (there are references to krb5_c_make_random_key > in libkrb5, but no symbol definition). > > --Ken From kenh@cmf.nrl.navy.mil Sun Aug 14 20:10:55 2022 From: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Sun, 14 Aug 2022 15:10:55 -0400 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: References: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> Message-ID: <202208141910.27EJAufL012997@hedwig.cmf.nrl.navy.mil> >Ah, yes, I believe you are right. That library does exist on my >system also, and I manually added it to Makefile.config and the build >continued. The question is then, why didn't ./configure detect it and >add it? I can't speak for that; I lack the energy at this time to go delving into the configure script for OpenAFS. The traditional way that Kerberos options are detected by autoconf (as Benjamin Kaduk alluded to) is you give it a path to a krb5-config script which will tell you the right compile and link-time options to build a Kerberos program. --Ken From ben@huntsmans.net Sun Aug 14 20:52:23 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Sun, 14 Aug 2022 19:52:23 +0000 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: <202208141910.27EJAufL012997@hedwig.cmf.nrl.navy.mil> References: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> <202208141910.27EJAufL012997@hedwig.cmf.nrl.navy.mil> Message-ID: --_000_MWHPR0701MB3674CAB6F6ABC28851A5579FA7699MWHPR0701MB3674_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ken! No worries, but thank you for your pointers so far! It is interesting that krb5-config --libs does indeed show k5crypto: $ krb5-config --libs -L/opt/freeware/lib64 -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/lib:/= usr/lib:/lib -L/opt/freeware/lib64 -L/opt/freeware/lib -Wl,-brtl -lpthreads= -lkrb5 -lk5crypto -lcom_err It would appear that the output from that is not being used by OpenAFS thou= gh, because in the original error I also didn't see the -blibpath... argume= nts nor references to /opt/freeware/lib64. Thanks! -Ben ________________________________ From: Ken Hornstein Sent: Sunday, August 14, 2022 12:10 PM To: Ben Huntsman Cc: openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_ma= ke_random_key >Ah, yes, I believe you are right. That library does exist on my >system also, and I manually added it to Makefile.config and the build >continued. The question is then, why didn't ./configure detect it and >add it? I can't speak for that; I lack the energy at this time to go delving into the configure script for OpenAFS. The traditional way that Kerberos options are detected by autoconf (as Benjamin Kaduk alluded to) is you give it a path to a krb5-config script which will tell you the right compile and link-time options to build a Kerberos program. --Ken --_000_MWHPR0701MB3674CAB6F6ABC28851A5579FA7699MWHPR0701MB3674_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ken!

No worries, but thank you for your pointers so far!

It is interesting that krb5-config --libs does indeed show k5c= rypto:

$ krb5-config --libs

-L/opt/freeware/lib64 -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/= lib:/usr/lib:/lib -L/opt/freeware/lib64 -L/opt/freeware/lib -Wl,-brtl -lpth= reads -lkrb5 -lk5crypto -lcom_err

It would appear that the output from that is not being used by OpenAFS thou= gh, because in the original error I also didn't see the -blibpath... argume= nts nor references to /opt/freeware/lib64.

Thanks!

-Ben

From: Ken Hornstein <ken= h@cmf.nrl.navy.mil>
Sent: Sunday, August 14, 2022 12:10 PM
To: Ben Huntsman <ben@huntsmans.net>
Cc: openafs-devel@openafs.org <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .kr= b5_c_make_random_key

>Ah, yes, I believe you are right. That l= ibrary does exist on my
>system also, and I manually added it to Makefile.config and the build >continued. The question is then, why didn't ./configure detect it= and
>add it?

I can't speak for that; I lack the energy at this time to go delving
into the configure script for OpenAFS. The traditional way that Kerbe= ros
options are detected by autoconf (as Benjamin Kaduk alluded to) is
you give it a path to a krb5-config script which will tell you the
right compile and link-time options to build a Kerberos program.

--Ken

--_000_MWHPR0701MB3674CAB6F6ABC28851A5579FA7699MWHPR0701MB3674_-- From shadow@gmail.com Sun Aug 14 20:57:17 2022 From: shadow@gmail.com (Daria Phoebe Brashear) Date: Sun, 14 Aug 2022 15:57:17 -0400 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: References: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> <202208141910.27EJAufL012997@hedwig.cmf.nrl.navy.mil> Message-ID: did you tell it to use krb5-config, and where it was? PATH_KRB5_CONFIG=/path/to/krb5-config ./configure ... On Sun, Aug 14, 2022 at 3:53 PM Ben Huntsman (ben@huntsmans.net) wrote: > > Hi Ken! > No worries, but thank you for your pointers so far! > > It is interesting that krb5-config --libs does indeed show k5crypto: > > $ krb5-config --libs > -L/opt/freeware/lib64 -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib -L/opt/freeware/lib64 -L/opt/freeware/lib -Wl,-brtl -lpthreads -lkrb5 -lk5crypto -lcom_err > > > It would appear that the output from that is not being used by OpenAFS though, because in the original error I also didn't see the -blibpath... arguments nor references to /opt/freeware/lib64. > > Thanks! > > -Ben > > ________________________________ > From: Ken Hornstein > Sent: Sunday, August 14, 2022 12:10 PM > To: Ben Huntsman > Cc: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key > > >Ah, yes, I believe you are right. That library does exist on my > >system also, and I manually added it to Makefile.config and the build > >continued. The question is then, why didn't ./configure detect it and > >add it? > > I can't speak for that; I lack the energy at this time to go delving > into the configure script for OpenAFS. The traditional way that Kerberos > options are detected by autoconf (as Benjamin Kaduk alluded to) is > you give it a path to a krb5-config script which will tell you the > right compile and link-time options to build a Kerberos program. > > --Ken -- Daria Phoebe Brashear AuriStor, Inc dariaphoebe.com From ben@huntsmans.net Sun Aug 14 21:03:38 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Sun, 14 Aug 2022 20:03:38 +0000 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: References: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> <202208141910.27EJAufL012997@hedwig.cmf.nrl.navy.mil>

Message-ID: --_000_MWHPR0701MB3674FBAD2C4B31EBAF298A37A7699MWHPR0701MB3674_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I did not, I just used the option --with-krb5=3D/opt/freeware Shouldn't that be enough since krb5-config is in /opt/freeware/bin? Thank you! -Ben ________________________________ From: Daria Phoebe Brashear Sent: Sunday, August 14, 2022 12:57 PM To: Ben Huntsman Cc: Ken Hornstein ; openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_ma= ke_random_key did you tell it to use krb5-config, and where it was? PATH_KRB5_CONFIG=3D/path/to/krb5-config ./configure ... On Sun, Aug 14, 2022 at 3:53 PM Ben Huntsman (ben@huntsmans.net) wrote: > > Hi Ken! > No worries, but thank you for your pointers so far! > > It is interesting that krb5-config --libs does indeed show k5crypto: > > $ krb5-config --libs > -L/opt/freeware/lib64 -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/lib= :/usr/lib:/lib -L/opt/freeware/lib64 -L/opt/freeware/lib -Wl,-brtl -lpthrea= ds -lkrb5 -lk5crypto -lcom_err > > > It would appear that the output from that is not being used by OpenAFS th= ough, because in the original error I also didn't see the -blibpath... argu= ments nor references to /opt/freeware/lib64. > > Thanks! > > -Ben > > ________________________________ > From: Ken Hornstein > Sent: Sunday, August 14, 2022 12:10 PM > To: Ben Huntsman > Cc: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_= make_random_key > > >Ah, yes, I believe you are right. That library does exist on my > >system also, and I manually added it to Makefile.config and the build > >continued. The question is then, why didn't ./configure detect it and > >add it? > > I can't speak for that; I lack the energy at this time to go delving > into the configure script for OpenAFS. The traditional way that Kerberos > options are detected by autoconf (as Benjamin Kaduk alluded to) is > you give it a path to a krb5-config script which will tell you the > right compile and link-time options to build a Kerberos program. > > --Ken -- Daria Phoebe Brashear AuriStor, Inc dariaphoebe.com --_000_MWHPR0701MB3674FBAD2C4B31EBAF298A37A7699MWHPR0701MB3674_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I did not, I just used the option --with-krb5=3D/opt/freeware

Shouldn't that be enough since krb5-config is in /opt/freeware/bin?

Thank you!

-Ben

From: Daria Phoebe Brashear= <shadow@gmail.com>
Sent: Sunday, August 14, 2022 12:57 PM
To: Ben Huntsman <ben@huntsmans.net>
Cc: Ken Hornstein <kenh@cmf.nrl.navy.mil>; openafs-devel@opena= fs.org <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .kr= b5_c_make_random_key

did you tell it to use krb5-config, and where it w= as?
PATH_KRB5_CONFIG=3D/path/to/krb5-config ./configure ...

On Sun, Aug 14, 2022 at 3:53 PM Ben Huntsman (ben@huntsmans.net)
<ben@huntsmans.net> wrote:
>
> Hi Ken!
> No worries, but thank you for your pointers so far!<= br> >
> It is interesting that krb5-config --libs does indee= d show k5crypto:
>
> $ krb5-config --libs
> -L/opt/freeware/lib64 -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/= lib:/usr/lib:/lib -L/opt/freeware/lib64 -L/opt/freeware/lib -Wl,-brtl -lpth= reads -lkrb5 -lk5crypto -lcom_err
>
>
> It would appear that the output from that is not being used by OpenAFS= though, because in the original error I also didn't see the -blibpath... a= rguments nor references to /opt/freeware/lib64.
>
> Thanks!
>
> -Ben
>
> ________________________________
> From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
> Sent: Sunday, August 14, 2022 12:10 PM
> To: Ben Huntsman <ben@huntsmans.net>
> Cc: openafs-devel@openafs.org <openafs-devel@openafs.org>
> Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5= _c_make_random_key
>
> >Ah, yes, I believe you are right. That library does exist on= my
> >system also, and I manually added it to Makefile.config and the bu= ild
> >continued. The question is then, why didn't ./configure dete= ct it and
> >add it?
>
> I can't speak for that; I lack the energy at this time to go delving > into the configure script for OpenAFS. The traditional way that = Kerberos
> options are detected by autoconf (as Benjamin Kaduk alluded to) is
> you give it a path to a krb5-config script which will tell you the
> right compile and link-time options to build a Kerberos program.
>
> --Ken

--
Daria Phoebe Brashear
AuriStor, Inc
dariaphoebe.com

--_000_MWHPR0701MB3674FBAD2C4B31EBAF298A37A7699MWHPR0701MB3674_-- From shadow@gmail.com Sun Aug 14 21:04:43 2022 From: shadow@gmail.com (Daria Phoebe Brashear) Date: Sun, 14 Aug 2022 16:04:43 -0400 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: References: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> <202208141910.27EJAufL012997@hedwig.cmf.nrl.navy.mil>

Message-ID: --000000000000594d9e05e639075f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Regardless of whether it should, my suggestion is setting PATH_KRB5_CONFIG (or just KRB5_CONFIG if you=E2=80=99re using 1.6) On Sun, Aug 14, 2022 at 16:03 Ben Huntsman wrote: > I did not, I just used the option --with-krb5=3D/opt/freeware > > Shouldn't that be enough since krb5-config is in /opt/freeware/bin? > > Thank you! > > -Ben > > ------------------------------ > *From:* Daria Phoebe Brashear > *Sent:* Sunday, August 14, 2022 12:57 PM > *To:* Ben Huntsman > *Cc:* Ken Hornstein ; openafs-devel@openafs.org < > openafs-devel@openafs.org> > *Subject:* Re: [OpenAFS-devel] AIX build fails with missing symbol > .krb5_c_make_random_key > > did you tell it to use krb5-config, and where it was? > PATH_KRB5_CONFIG=3D/path/to/krb5-config ./configure ... > > > On Sun, Aug 14, 2022 at 3:53 PM Ben Huntsman (ben@huntsmans.net) > wrote: > > > > Hi Ken! > > No worries, but thank you for your pointers so far! > > > > It is interesting that krb5-config --libs does indeed show k5crypto: > > > > $ krb5-config --libs > > -L/opt/freeware/lib64 > -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib > -L/opt/freeware/lib64 -L/opt/freeware/lib -Wl,-brtl -lpthreads -lkrb5 > -lk5crypto -lcom_err > > > > > > It would appear that the output from that is not being used by OpenAFS > though, because in the original error I also didn't see the -blibpath... > arguments nor references to /opt/freeware/lib64. > > > > Thanks! > > > > -Ben > > > > ________________________________ > > From: Ken Hornstein > > Sent: Sunday, August 14, 2022 12:10 PM > > To: Ben Huntsman > > Cc: openafs-devel@openafs.org > > Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol > .krb5_c_make_random_key > > > > >Ah, yes, I believe you are right. That library does exist on my > > >system also, and I manually added it to Makefile.config and the build > > >continued. The question is then, why didn't ./configure detect it and > > >add it? > > > > I can't speak for that; I lack the energy at this time to go delving > > into the configure script for OpenAFS. The traditional way that Kerber= os > > options are detected by autoconf (as Benjamin Kaduk alluded to) is > > you give it a path to a krb5-config script which will tell you the > > right compile and link-time options to build a Kerberos program. > > > > --Ken > > > > > -- > Daria Phoebe Brashear > AuriStor, Inc > dariaphoebe.com > --=20 -- Daria Phoebe Brashear AuriStor, Inc. dariaphoebe.com --000000000000594d9e05e639075f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Regardless of whether it should, my suggestion is setting= PATH_KRB5_CONFIG (or just KRB5_CONFIG if you=E2=80=99re using 1.6)

On = Sun, Aug 14, 2022 at 16:03 Ben Huntsman <ben@huntsmans.net> wrote:

I did not, I just used the option --with-krb5=3D/opt/freeware

Shouldn't that be enough since krb5-config is in /opt/freeware/bin?

Thank you!

-Ben

From: Dari= a Phoebe Brashear <shadow@gmail.com>
Sent: Sunday, August 14, 20= 22 12:57 PM
To: Ben Huntsman <ben@huntsmans.net>
Cc: Ken Hornstein <kenh@cmf.nrl.navy.mil>; openafs-devel@openafs.org <openafs= -devel@openafs.org>
Subject: Re: [OpenAFS-devel= ] AIX build fails with missing symbol .krb5_c_make_random_key
=C2=A0

did you tell it to use krb5-config, and where it was?
PATH_KRB5_CONFIG=3D/path/to/krb5-config ./configure ...

On Sun, Aug 14, 2022 at 3:53 PM Ben Huntsman (ben@huntsmans.net)
<ben@huntsmans.ne= t> wrote:
>
> Hi Ken!
>=C2=A0=C2=A0=C2=A0 No worries, but thank you for your pointers so far!<= br> >
>=C2=A0=C2=A0=C2=A0 It is interesting that krb5-config --libs does indee= d show k5crypto:
>
> $ krb5-config --libs
> -L/opt/freeware/lib64 -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/= lib:/usr/lib:/lib -L/opt/freeware/lib64 -L/opt/freeware/lib -Wl,-brtl -lpth= reads -lkrb5 -lk5crypto -lcom_err
>
>
> It would appear that the output from that is not being used by OpenAFS= though, because in the original error I also didn't see the -blibpath.= .. arguments nor references to /opt/freeware/lib64.
>
> Thanks!
>
> -Ben
>
> ________________________________
> From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
> Sent: Sunday, August 14, 2022 12:10 PM
> To: Ben Huntsman <ben@huntsmans.net>
> Cc: ope= nafs-devel@openafs.org <openafs-devel@openafs.org>
> Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5= _c_make_random_key
>
> >Ah, yes, I believe you are right.=C2=A0 That library does exist on= my
> >system also, and I manually added it to Makefile.config and the bu= ild
> >continued.=C2=A0 The question is then, why didn't ./configure = detect it and
> >add it?
>
> I can't speak for that; I lack the energy at this time to go delvi= ng
> into the configure script for OpenAFS.=C2=A0 The traditional way that = Kerberos
> options are detected by autoconf (as Benjamin Kaduk alluded to) is
> you give it a path to a krb5-config script which will tell you the
> right compile and link-time options to build a Kerberos program.
>
> --Ken

--
Daria Phoebe Brashear
AuriStor, Inc
dariaphoebe.com

--
Daria Phoebe Brashear
AuriStor,= Inc.
dariaphoebe.com

--000000000000594d9e05e639075f-- From ben@huntsmans.net Sun Aug 14 21:09:36 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Sun, 14 Aug 2022 20:09:36 +0000 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: References: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> <202208141910.27EJAufL012997@hedwig.cmf.nrl.navy.mil>

Message-ID: --_000_MWHPR0701MB367464822B7EBD9766B78BB7A7699MWHPR0701MB3674_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Daria- I just re-ran configure using that option, and it does print out that it= uses /opt/freeware/bin/krb5-config, however it still does not add the opti= on -lk5crypto to the Kerberos build flags. Thank you. -Ben ________________________________ From: Ben Huntsman Sent: Sunday, August 14, 2022 1:03 PM To: Daria Phoebe Brashear Cc: Ken Hornstein ; openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_ma= ke_random_key I did not, I just used the option --with-krb5=3D/opt/freeware Shouldn't that be enough since krb5-config is in /opt/freeware/bin? Thank you! -Ben ________________________________ From: Daria Phoebe Brashear Sent: Sunday, August 14, 2022 12:57 PM To: Ben Huntsman Cc: Ken Hornstein ; openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_ma= ke_random_key did you tell it to use krb5-config, and where it was? PATH_KRB5_CONFIG=3D/path/to/krb5-config ./configure ... On Sun, Aug 14, 2022 at 3:53 PM Ben Huntsman (ben@huntsmans.net) wrote: > > Hi Ken! > No worries, but thank you for your pointers so far! > > It is interesting that krb5-config --libs does indeed show k5crypto: > > $ krb5-config --libs > -L/opt/freeware/lib64 -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/lib= :/usr/lib:/lib -L/opt/freeware/lib64 -L/opt/freeware/lib -Wl,-brtl -lpthrea= ds -lkrb5 -lk5crypto -lcom_err > > > It would appear that the output from that is not being used by OpenAFS th= ough, because in the original error I also didn't see the -blibpath... argu= ments nor references to /opt/freeware/lib64. > > Thanks! > > -Ben > > ________________________________ > From: Ken Hornstein > Sent: Sunday, August 14, 2022 12:10 PM > To: Ben Huntsman > Cc: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_= make_random_key > > >Ah, yes, I believe you are right. That library does exist on my > >system also, and I manually added it to Makefile.config and the build > >continued. The question is then, why didn't ./configure detect it and > >add it? > > I can't speak for that; I lack the energy at this time to go delving > into the configure script for OpenAFS. The traditional way that Kerberos > options are detected by autoconf (as Benjamin Kaduk alluded to) is > you give it a path to a krb5-config script which will tell you the > right compile and link-time options to build a Kerberos program. > > --Ken -- Daria Phoebe Brashear AuriStor, Inc dariaphoebe.com --_000_MWHPR0701MB367464822B7EBD9766B78BB7A7699MWHPR0701MB3674_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Daria-

I just re-ran configure using that option, and it does print o= ut that it uses /opt/freeware/bin/krb5-config, however it still does not ad= d the option -lk5crypto to the Kerberos build flags.

Thank you.

-Ben

From: Ben Huntsman <ben@= huntsmans.net>
Sent: Sunday, August 14, 2022 1:03 PM
To: Daria Phoebe Brashear <shadow@gmail.com>
Cc: Ken Hornstein <kenh@cmf.nrl.navy.mil>; openafs-devel@opena= fs.org <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .kr= b5_c_make_random_key

I did not, I just used the option --with-krb5=3D/opt/freeware

Shouldn't that be enough since krb5-config is in /opt/freeware/bin?

Thank you!

-Ben

From: Daria Phoebe Brashe= ar <shadow@gmail.com>
Sent: Sunday, August 14, 2022 12:57 PM
To: Ben Huntsman <ben@huntsmans.net>
Cc: Ken Hornstein <kenh@cmf.nrl.navy.mil>; openafs-devel@opena= fs.org <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .kr= b5_c_make_random_key

did you tell it to use krb5-config, and where it= was?
PATH_KRB5_CONFIG=3D/path/to/krb5-config ./configure ...

On Sun, Aug 14, 2022 at 3:53 PM Ben Huntsman (ben@huntsmans.net)
<ben@huntsmans.net> wrote:
>
> Hi Ken!
> No worries, but thank you for your pointers so far!<= br> >
> It is interesting that krb5-config --libs does indee= d show k5crypto:
>
> $ krb5-config --libs
> -L/opt/freeware/lib64 -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/= lib:/usr/lib:/lib -L/opt/freeware/lib64 -L/opt/freeware/lib -Wl,-brtl -lpth= reads -lkrb5 -lk5crypto -lcom_err
>
>
> It would appear that the output from that is not being used by OpenAFS= though, because in the original error I also didn't see the -blibpath... a= rguments nor references to /opt/freeware/lib64.
>
> Thanks!
>
> -Ben
>
> ________________________________
> From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
> Sent: Sunday, August 14, 2022 12:10 PM
> To: Ben Huntsman <ben@huntsmans.net>
> Cc: openafs-devel@openafs.org <openafs-devel@openafs.org>
> Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5= _c_make_random_key
>
> >Ah, yes, I believe you are right. That library does exist on= my
> >system also, and I manually added it to Makefile.config and the bu= ild
> >continued. The question is then, why didn't ./configure dete= ct it and
> >add it?
>
> I can't speak for that; I lack the energy at this time to go delving > into the configure script for OpenAFS. The traditional way that = Kerberos
> options are detected by autoconf (as Benjamin Kaduk alluded to) is
> you give it a path to a krb5-config script which will tell you the
> right compile and link-time options to build a Kerberos program.
>
> --Ken

--
Daria Phoebe Brashear
AuriStor, Inc
dariaphoebe.com

--_000_MWHPR0701MB367464822B7EBD9766B78BB7A7699MWHPR0701MB3674_-- From kaduk@mit.edu Sun Aug 14 21:40:31 2022 From: kaduk@mit.edu (Benjamin Kaduk) Date: Sun, 14 Aug 2022 13:40:31 -0700 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: References: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> <20220814185331.GM24514@kduck.mit.edu> Message-ID: <20220814204031.GN24514@kduck.mit.edu> On Sun, Aug 14, 2022 at 07:41:43PM +0000, Ben Huntsman wrote: > Hi Ben- > Thanks for the reply! > > My krb5-config and openafs's config.log are attached. > > When I ran configure, I used the argument --with-krb5=/opt/freeware Thanks! It looks like your /opt/freeware/bin/krb5-config is trying to use 64-bit libraries, but at least configure is trying to build for 32-bit: configure:40672: checking for krb5-config configure:40696: found /opt/freeware/bin/krb5-config configure:40708: result: /opt/freeware/bin/krb5-config configure:41045: checking for krb5 support in krb5-config configure:41058: result: yes configure:41066: checking for --deps support in krb5-config configure:41079: result: no configure:41108: checking for krb5_init_context configure:41108: cc -o conftest -I/opt/freeware/include conftest.c -L/opt/freeware/lib64 -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib -L/opt/freeware/lib64 -L/opt/freeware/lib -Wl,-brtl -lpthreads -lkrb5 -lk5crypto -lcom_err >&5 ld: 0711-736 ERROR: Input file /opt/freeware/lib64/libkrb5.so: XCOFF64 object files are not allowed in 32-bit mode. So if the krb5-config output gets rejected, configure will fall back to some heuristics for how to link krb5, and those heuristics are wrong in this case. I'm not super familiar with the mechanisms to get 32- vs 64-bit output from the compiler/linker on AIX, but random googling suggests that maybe passing CFLAGS=-q64 to configure would affect that aspect of things? (It might break something else, of course.) For what it's worth, most of the OS-specific build settings are in src/cf/osconf.m4, and for rs_aix61 we currently show: rs_aix61) CC="cc" DBG="-g" LIBSYS_AIX_EXP="afsl.exp" MT_CC="xlc_r" SHLIB_SUFFIX="o" XCFLAGS="-K -D_NONSTD_TYPES -D_MBI=void" XLIBS="${LIB_AFSDB} ${LIB_libintl} -ldl" SHLIB_LINKER="${MT_CC} -bM:SRE -berok" AIX32="no" AIX64="yes" TSM_IMPORTS="-bI:/lib/aio.exp -bI:/lib/netinet.exp -bI:/lib/sockets.exp -bI:/lib/statcmd.exp" TSM_LIBS="-lsys -lcsys -lc" ;; The AIX32 and AIX64 variables are not widely used in the buildsystem, but the one place they do show up suggest that this does indicate that we "expect to" be building 64-bit libraries on this system. Perhaps there's some skew in compiler defaults between when that was written and what you have. -Ben From ben@huntsmans.net Sun Aug 14 22:12:53 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Sun, 14 Aug 2022 21:12:53 +0000 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: <20220814204031.GN24514@kduck.mit.edu> References: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> <20220814185331.GM24514@kduck.mit.edu> <20220814204031.GN24514@kduck.mit.edu> Message-ID: --_000_MWHPR0701MB367426DAEFAB3FEFC496FEF3A7699MWHPR0701MB3674_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there- Yes, on AIX 6.1 we need to be building 64-bit, as there is no 32-bit on = 6.1. The 32-bit kernel is available on AIX 5.3 and below. On XL C, the de= fault is -q32. So, we should probably tweak something to always build as 64-bit on AIX = 6.1... Alternatively, for userland stuff, the krb5-libs package provides b= oth 32-bit and 64-bit libraries... It is interesting that krb5-config isn'= t doing the right thing for 32-bit... Thanks! -Ben ________________________________ From: Benjamin Kaduk Sent: Sunday, August 14, 2022 1:40 PM To: Ben Huntsman Cc: Ken Hornstein ; openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_ma= ke_random_key On Sun, Aug 14, 2022 at 07:41:43PM +0000, Ben Huntsman wrote: > Hi Ben- > Thanks for the reply! > > My krb5-config and openafs's config.log are attached. > > When I ran configure, I used the argument --with-krb5=3D/opt/freeware Thanks! It looks like your /opt/freeware/bin/krb5-config is trying to use 64-bit libraries, but at least configure is trying to build for 32-bit: configure:40672: checking for krb5-config configure:40696: found /opt/freeware/bin/krb5-config configure:40708: result: /opt/freeware/bin/krb5-config configure:41045: checking for krb5 support in krb5-config configure:41058: result: yes configure:41066: checking for --deps support in krb5-config configure:41079: result: no configure:41108: checking for krb5_init_context configure:41108: cc -o conftest -I/opt/freeware/include conftest.c -L/opt/freeware/lib64 -Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib -L/opt/freeware/lib64 -L/opt/freeware/lib -Wl,-brtl -lpthreads -lkrb5 -lk5crypto -lcom_err >&5 ld: 0711-736 ERROR: Input file /opt/freeware/lib64/libkrb5.so: XCOFF64 object files are not allowed in 32-bit mode. So if the krb5-config output gets rejected, configure will fall back to some heuristics for how to link krb5, and those heuristics are wrong in this case. I'm not super familiar with the mechanisms to get 32- vs 64-bit output from the compiler/linker on AIX, but random googling suggests that maybe passing CFLAGS=3D-q64 to configure would affect that aspect of things? (It might break something else, of course.) For what it's worth, most of the OS-specific build settings are in src/cf/osconf.m4, and for rs_aix61 we currently show: rs_aix61) CC=3D"cc" DBG=3D"-g" LIBSYS_AIX_EXP=3D"afsl.exp" MT_CC=3D"xlc_r" SHLIB_SUFFIX=3D"o" XCFLAGS=3D"-K -D_NONSTD_TYPES -D_MBI=3Dvoid" XLIBS=3D"${LIB_AFSDB} ${LIB_libintl} -ldl" SHLIB_LINKER=3D"${MT_CC} -bM:SRE -berok" AIX32=3D"no" AIX64=3D"yes" TSM_IMPORTS=3D"-bI:/lib/aio.exp -bI:/lib/netinet.exp -bI:/l= ib/sockets.exp -bI:/lib/statcmd.exp" TSM_LIBS=3D"-lsys -lcsys -lc" ;; The AIX32 and AIX64 variables are not widely used in the buildsystem, but the one place they do show up suggest that this does indicate that we "expect to" be building 64-bit libraries on this system. Perhaps there's some skew in compiler defaults between when that was written and what you have. -Ben --_000_MWHPR0701MB367426DAEFAB3FEFC496FEF3A7699MWHPR0701MB3674_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there-

Yes, on AIX 6.1 we need to be building 64-bit, as there is no = 32-bit on 6.1. The 32-bit kernel is available on AIX 5.3 and below.&n= bsp; On XL C, the default is -q32.

So, we should probably tweak something to always build as 64-b= it on AIX 6.1... Alternatively, for userland stuff, the krb5-libs pac= kage provides both 32-bit and 64-bit libraries... It is interesting t= hat krb5-config isn't doing the right thing for 32-bit...

Thanks!

-Ben

From: Benjamin Kaduk <ka= duk@mit.edu>
Sent: Sunday, August 14, 2022 1:40 PM
To: Ben Huntsman <ben@huntsmans.net>
Cc: Ken Hornstein <kenh@cmf.nrl.navy.mil>; openafs-devel@opena= fs.org <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .kr= b5_c_make_random_key

On Sun, Aug 14, 2022 at 07:41:43PM +0000, Ben Hunt= sman wrote:
> Hi Ben-
>    Thanks for the reply!
>
>    My krb5-config and openafs's config.log are attached= .
>
>    When I ran configure, I used the argument --with-krb= 5=3D/opt/freeware

Thanks!

It looks like your /opt/freeware/bin/krb5-config is trying to use 64-bit libraries, but at least configure is trying to build for 32-bit:

configure:40672: checking for krb5-config     &nbs= p;            &= nbsp;           &nbs= p;
configure:40696: found /opt/freeware/bin/krb5-config    = ;            &n= bsp;            = ;
configure:40708: result: /opt/freeware/bin/krb5-config   &nb= sp;            =             &nb= sp;
configure:41045: checking for krb5 support in krb5-config   =             &nb= sp;
configure:41058: result: yes        = ;            &n= bsp;            = ;            &n= bsp;
configure:41066: checking for --deps support in krb5-config  &nbs= p;            &= nbsp;
configure:41079: result: no        =             &nb= sp;            =             &nb= sp;
configure:41108: checking for krb5_init_context    &nbs= p;            &= nbsp;           &nbs= p;
configure:41108: cc -o conftest   -I/opt/freeware/include &n= bsp; conftest.c         =
-L/opt/freeware/lib64         =             &nb= sp;            =             &nb= sp;            =
-Wl,-blibpath:/opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib &nbs= p;            &= nbsp;
-L/opt/freeware/lib64 -L/opt/freeware/lib -Wl,-brtl -lpthreads -lkrb5
-lk5crypto
-lcom_err >&5        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;
ld: 0711-736 ERROR: Input file /opt/freeware/lib64/libkrb5.so:  &= nbsp;           &nbs= p;
        XCOFF64 object files are not all= owed in 32-bit mode.         &= nbsp;           &nbs= p;

So if the krb5-config output gets rejected, configure will fall back to
some heuristics for how to link krb5, and those heuristics are wrong in
this case.

I'm not super familiar with the mechanisms to get 32- vs 64-bit output from=
the compiler/linker on AIX, but random googling suggests that maybe passing=
CFLAGS=3D-q64 to configure would affect that aspect of things? (It mi= ght
break something else, of course.)

For what it's worth, most of the OS-specific build settings are in
src/cf/osconf.m4, and for rs_aix61 we currently show:

        rs_aix61)    = ;
            &nb= sp;   CC=3D"cc"
            &nb= sp;   DBG=3D"-g"
            &nb= sp;   LIBSYS_AIX_EXP=3D"afsl.exp"
            &nb= sp;   MT_CC=3D"xlc_r"
            &nb= sp;   SHLIB_SUFFIX=3D"o"
            &nb= sp;   XCFLAGS=3D"-K -D_NONSTD_TYPES -D_MBI=3Dvoid"
            &nb= sp;   XLIBS=3D"${LIB_AFSDB} ${LIB_libintl} -ldl"
            &nb= sp;   SHLIB_LINKER=3D"${MT_CC} -bM:SRE -berok"
            &nb= sp;   AIX32=3D"no"
            &nb= sp;   AIX64=3D"yes"
            &nb= sp;   TSM_IMPORTS=3D"-bI:/lib/aio.exp -bI:/lib/netinet.exp -= bI:/lib/sockets.exp -bI:/lib/statcmd.exp"
            &nb= sp;   TSM_LIBS=3D"-lsys -lcsys -lc"
            &nb= sp;   ;;

The AIX32 and AIX64 variables are not widely used in the buildsystem, but the one place they do show up suggest that this does indicate that we
"expect to" be building 64-bit libraries on this system. Pe= rhaps there's
some skew in compiler defaults between when that was written and what you have.

-Ben

--_000_MWHPR0701MB367426DAEFAB3FEFC496FEF3A7699MWHPR0701MB3674_-- From kaduk@mit.edu Sun Aug 14 22:21:57 2022 From: kaduk@mit.edu (Benjamin Kaduk) Date: Sun, 14 Aug 2022 14:21:57 -0700 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: References: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> <20220814185331.GM24514@kduck.mit.edu> <20220814204031.GN24514@kduck.mit.edu> Message-ID: <20220814212157.GO24514@kduck.mit.edu> On Sun, Aug 14, 2022 at 09:12:53PM +0000, Ben Huntsman wrote: > Hi there- > Yes, on AIX 6.1 we need to be building 64-bit, as there is no 32-bit on 6.1. The 32-bit kernel is available on AIX 5.3 and below. On XL C, the default is -q32. > > So, we should probably tweak something to always build as 64-bit on AIX 6.1... Alternatively, for userland stuff, the krb5-libs package provides both 32-bit and 64-bit libraries... It is interesting that krb5-config isn't doing the right thing for 32-bit... It's reasonable to just pass CFLAGS (and LDFLAGS?) to configure for diagnosis, but I think the long-term answer would be in the src/cf/osconf.m4 stanza I mentioned earlier. I don't see anything in your krb5-config that offers an option to provide 32- vs 64-bit output, and it wouldn't have any way to know intrinsically which bittedness we're asking it for. So maybe there are missing pieces in both what we ask it and what it can tell us... -Ben From ben@huntsmans.net Mon Aug 15 00:01:47 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Sun, 14 Aug 2022 23:01:47 +0000 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: <20220814212157.GO24514@kduck.mit.edu> References: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> <20220814185331.GM24514@kduck.mit.edu> <20220814204031.GN24514@kduck.mit.edu> <20220814212157.GO24514@kduck.mit.edu> Message-ID: --_000_MWHPR0701MB3674E3FB47B9D076AF876F86A7699MWHPR0701MB3674_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure, I agree for testing that's fine. But, there is evidence to suggest that this has compiled successfully on AI= X 6.1 and 7.2 in the past, and this issue would have occurred there. Or are you suggesting that all successful compiles used Kerberos packages w= hich provided only 32-bit libraries? Thanks. -Ben ________________________________ From: Benjamin Kaduk Sent: Sunday, August 14, 2022 2:21 PM To: Ben Huntsman Cc: Ken Hornstein ; openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_ma= ke_random_key On Sun, Aug 14, 2022 at 09:12:53PM +0000, Ben Huntsman wrote: > Hi there- > Yes, on AIX 6.1 we need to be building 64-bit, as there is no 32-bit o= n 6.1. The 32-bit kernel is available on AIX 5.3 and below. On XL C, the = default is -q32. > > So, we should probably tweak something to always build as 64-bit on AI= X 6.1... Alternatively, for userland stuff, the krb5-libs package provides= both 32-bit and 64-bit libraries... It is interesting that krb5-config is= n't doing the right thing for 32-bit... It's reasonable to just pass CFLAGS (and LDFLAGS?) to configure for diagnosis, but I think the long-term answer would be in the src/cf/osconf.m4 stanza I mentioned earlier. I don't see anything in your krb5-config that offers an option to provide 32- vs 64-bit output, and it wouldn't have any way to know intrinsically which bittedness we're asking it for. So maybe there are missing pieces in both what we ask it and what it can tell us... -Ben --_000_MWHPR0701MB3674E3FB47B9D076AF876F86A7699MWHPR0701MB3674_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sure, I agree for testing that's fine.

But, there is evidence to suggest that this has compiled successfully on AI= X 6.1 and 7.2 in the past, and this issue would have occurred there.

Or are you suggesting that all successful compiles used Kerberos packages w= hich provided only 32-bit libraries?

Thanks.

-Ben

From: Benjamin Kaduk <ka= duk@mit.edu>
Sent: Sunday, August 14, 2022 2:21 PM
To: Ben Huntsman <ben@huntsmans.net>
Cc: Ken Hornstein <kenh@cmf.nrl.navy.mil>; openafs-devel@opena= fs.org <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .kr= b5_c_make_random_key

On Sun, Aug 14, 2022 at 09:12:53PM +0000, Ben Hunt= sman wrote:
> Hi there-
> Yes, on AIX 6.1 we need to be building 64-bit, as th= ere is no 32-bit on 6.1. The 32-bit kernel is available on AIX 5.3 an= d below. On XL C, the default is -q32.
>
> So, we should probably tweak something to always bui= ld as 64-bit on AIX 6.1... Alternatively, for userland stuff, the krb= 5-libs package provides both 32-bit and 64-bit libraries... It is int= eresting that krb5-config isn't doing the right thing for 32-bit...

It's reasonable to just pass CFLAGS (and LDFLAGS?) to configure for
diagnosis, but I think the long-term answer would be in the
src/cf/osconf.m4 stanza I mentioned earlier.

I don't see anything in your krb5-config that offers an option to provide 32- vs 64-bit output, and it wouldn't have any way to know intrinsically which bittedness we're asking it for. So maybe there are missing piec= es in
both what we ask it and what it can tell us...

-Ben

--_000_MWHPR0701MB3674E3FB47B9D076AF876F86A7699MWHPR0701MB3674_-- From jaltman@auristor.com Mon Aug 15 03:23:11 2022 From: jaltman@auristor.com (Jeffrey E Altman) Date: Sun, 14 Aug 2022 22:23:11 -0400 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: References: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> <20220814185331.GM24514@kduck.mit.edu> <20220814204031.GN24514@kduck.mit.edu> <20220814212157.GO24514@kduck.mit.edu> Message-ID: <029e8756-be34-0b68-9a5a-b3bbe56ef26b@auristor.com> This is a cryptographically signed message in MIME format. --------------ms030706000503080602000501 Content-Type: multipart/alternative; boundary="------------Mk7UsO8Nw6vaY4bZMCYDWscY" --------------Mk7UsO8Nw6vaY4bZMCYDWscY Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 8/14/2022 7:01 PM, Ben Huntsman (ben@huntsmans.net) wrote: > Sure, I agree for testing that's fine. > > But, there is evidence to suggest that this has compiled successfully > on AIX 6.1 and 7.2 in the past, and this issue would have occurred there. > Ben, The change that you referred to as being similar to the build failure on AIX is dated Sept 2013. AIX 6.1 was last updated in November 2013. AIX 7.2 was first released in December 2015. The initial use of krb5_c_make_random_key() was added to OpenAFS in 2007 but it was for test infrastructure which might not have been built for AIX. In the years since additional use of that function has been added to the source tree. However, it is unclear to me at least whether such changes were built on AIX. The comments on https://gerrit.openafs.org/#/c/14707/3 which was the tip of the series that added symbols for AIX 7.2 state that the build on AIX succeeded only if the kernel module was not built and if all linkage was static. That change series is a little over a year old. The last combination that I can find evidence of the AIX kernel module working was OpenAFS 1.6.5 and AIX 6.1 TL5 which would have been 32-bit. OpenAFS 1.6.5 was released in July 2013. In Feb 2017 there was an openafs-info discussion on could OpenAFS be supported on AIX 7.1. OpenAFS 1.6.20.1 built on AIX 7.1 at that time but panicked the machine. There is no evidence that OpenAFS 1.8.x or current master has ever been built for AIX producing a working kernel module. Jeffrey Altman --------------Mk7UsO8Nw6vaY4bZMCYDWscY Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 8/14/2022 7:01 PM, Ben Huntsman (ben@huntsmans.net) wrote:

Sure, I agree for testing that's fine.

But, there is evidence to suggest that this has compiled successfully on AIX 6.1 and 7.2 in the past, and this issue would have occurred there.

Ben,

The change that you referred to as being similar to the build failure on AIX is dated Sept 2013.

AIX 6.1 was last updated in November 2013. AIX 7.2 was first released in December 2015.

The initial use of krb5_c_make_random_key() was added to OpenAFS in 2007 but it was for test infrastructure which might not have been built for AIX. In the years since additional use of that function has been added to the source tree. However, it is unclear to me at least whether such changes were built on AIX.

The comments on https://gerrit.openafs.org/#/c/14707/3 which was the tip of the series that added symbols for AIX 7.2 state that the build on AIX succeeded only if the kernel module was not built and if all linkage was static. That change series is a little over a year old.

The last combination that I can find evidence of the AIX kernel module working was OpenAFS 1.6.5 and AIX 6.1 TL5 which would have been 32-bit. OpenAFS 1.6.5 was released in July 2013.

In Feb 2017 there was an openafs-info discussion on could OpenAFS be supported on AIX 7.1. OpenAFS 1.6.20.1 built on AIX 7.1 at that time but panicked the machine.

There is no evidence that OpenAFS 1.8.x or current master has ever been built for AIX producing a working kernel module.

Jeffrey Altman

--------------Mk7UsO8Nw6vaY4bZMCYDWscY-- --------------ms030706000503080602000501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DHEwggXSMIIEuqADAgECAhBAAYJpmi/rPn/F0fJyDlzMMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEz MB4XDTIyMDgwNDE2MDQ0OFoXDTI1MTAzMTE2MDM0OFowcDEvMC0GCgmSJomT8ixkAQETH0Ew MTQxMEQwMDAwMDE4MjY5OUEyRkQyMDAwMjMzQ0QxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRt YW4xFTATBgNVBAoTDEF1cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCkC7PKBBZnQqDKPtZPMLAy77zo2DPvwtGnd1hNjPvbXrpGxUb3 xHZRtv179LHKAOcsY2jIctzieMxf82OMyhpBziMPsFAG/ukihBMFj3/xEeZVso3K27pSAyyN fO/wJ0rX7G+ges22Dd7goZul8rPaTJBIxbZDuaykJMGpNq4PQ8VPcnYZx+6b+nJwJJoJ46kI EEfNh3UKvB/vM0qtxS690iAdgmQIhTl+qfXq4IxWB6b+3NeQxgR6KLU4P7v88/tvJTpxIKkg 9xj89ruzeThyRFd2DSe3vfdnq9+g4qJSHRXyTft6W3Lkp7UWTM4kMqOcc4VSRdufVKBQNXjG IcnhAgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAwgYQGCCsGAQUFBwEBBHgwdjAwBggr BgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUF BzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWEx My5wN2MwHwYDVR0jBBgwFoAULbfeG1l+KpguzeHUG+PFEBJe6RQwCQYDVR0TBAIwADCCASsG A1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIBFj5odHRwczov L3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRt bDCBugYIKwYBBQUHAgIwga0MgapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4g aXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRp ZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8v dmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTMuY3JsMB8GA1UdEQQY MBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBQB+nzqgljLocLTsiUn2yWqEc2s gjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJwV eycprp8Ox1npiTyfwc5QaVaqtoe8Dcg2JXZc0h4DmYGW2rRLHp8YL43snEV93rPJVk6B2v4c WLeQfaMrnyNeEuvHx/2CT44cdLtaEk5zyqo3GYJYlLcRVz6EcSGHv1qPXgDT0xB/25etwGYq utYF4Chkxu4KzIpq90eDMw5ajkexw+8ARQz4N5+d6NRbmMCovd7wTGi8th/BZvz8hgKUiUJo Qle4wDxrdXdnIhCP7g87InXKefWgZBF4VX21t2+hkc04qrhIJlHrocPG9mRSnnk2WpsY0MXt a8ivbVKtfpY7uSNDZSKTDi1izEFH5oeQdYRkgIGb319a7FjslV8wggaXMIIEf6ADAgECAhBA AXA7OrqBjMk8rp4OuNQSMA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK EwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAe Fw0yMDAyMTIyMTA3NDlaFw0zMDAyMTIyMTA3NDlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK EwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAu6sUO01SDD99PM+QdZkNxKxJNt0NgQE+Zt6ixaNP0JKSjTd+SG5L wqxBWjnOgI/3dlwgtSNeN77AgSs+rA4bK4GJ75cUZZANUXRKw/et8pf9Qn6iqgB63OdHxBN/ 15KbM3HR+PyiHXQoUVIevCKW8nnlWnnZabT1FejOhRRKVUg5HACGOTfnCOONrlxlg+m1Vjgn o1uNqNuLM/jkD1z6phNZ/G9IfZGI0ppHX5AA/bViWceX248VmefNhSR14ADZJtlAAWOi2un0 3bqrBPHA9nDyXxI8rgWLfUP5rDy8jx2hEItg95+ORF5wfkGUq787HBjspE86CcaduLka/Bk2 VwIDAQABo4IChzCCAoMwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwgYkG CCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVu dHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t L3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C 5yZUyI42djCCASQGA1UdIASCARswggEXMIIBEwYEVR0gADCCAQkwSgYIKwYBBQUHAgEWPmh0 dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRl eC5odG1sMIG6BggrBgEFBQcCAjCBrQyBqlRoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMg YmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIElkZW5UcnVzdCdzIFRydXN0SUQgQ2Vy dGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20v Y2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEoGA1UdHwRDMEEwP6A9oDuGOWh0 dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL2NvbW1lcmNpYWxyb290Y2ExLmNy bDAdBgNVHQ4EFgQULbfeG1l+KpguzeHUG+PFEBJe6RQwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4ICAQB/7BKcygLX6Nl4a03cDHt7TLdPxCzFvDF2 bkVYCFTRX47UfeomF1gBPFDee3H/IPlLRmuTPoNt0qjdpfQzmDWN95jUXLdLPRToNxyaoB5s 0hOhcV6H08u3FHACBif55i0DTDzVSaBv0AZ9h1XeuGx4Fih1Vm3Xxz24GBqqVudvPRLyMJ7u 6hvBqTIKJ53uCs3dyQLZT9DXnp+kJv8y7ZSAY+QVrI/dysT8avtn8d7k7azNBkfnbRq+0e88 QoBnel6u+fpwbd5NLRHywXeH+phbzULCa+bLPRMqJaW2lbhvSWrMHRDy3/d8HvgnLCBFK2s4 Spns4YCN4xVcbqlGWzgolHCKUH39vpcsDo1ymZFrJ8QR6ihIn8FmJ5oKwAnnd/G6ADXFC9bu db9+532phSAXOZrrecIQn+vtP366PC+aClAPsIIDJDsotS5z4X2JUFsNIuEgXGqhiKE7SuZb rFG9sdcLprSlJN7TsRDc0W2b9nqwD+rj/5MN0C+eKwha+8ydv0+qzTyxPP90KRgaegGowC4d UsZyTk2n4Z3MuAHX5nAZL/Vh/SyDj/ajorV44yqZBzQ3ChKhXbfUSwe2xMmygA2Z5DRwMRJn p/BscizYdNk2WXJMTnH+wVLN8sLEwEtQR4eTLoFmQvrK2AMBS9kW5sBkMzINt/ZbbcZ3F+eA MDGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUG A1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwDQYJYIZIAWUDBAIBBQCg ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgxNTAy MjMxMVowLwYJKoZIhvcNAQkEMSIEILZwvJadQmnpFgnZauL47IJs3gslRhR9zo/PoIAmK8Ri MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEACWm8 inv/9wdYYyp+0TqWHyU8fGovV5hPoI31M1uXC3MBAOJH4MvvCY2GU6QtpI69eN7sXOOnOB/o +pyuoX2dusbcGGDtT5/sutS89n7lI6ucLvARoMZKNMuxAws7JrGOQ/GYHNVLMnKOyX36OuP4 loSblpT0rvlZItU0m0WDHrrfHbKvs2B9YpO6vPjvVkF5zuNVT5uKmaqTvLUvQRHT7N1wyB8P kG7Qme7gVn9DwWQXH1Hyggpgvv3vFOFrsJZFbgqNgthLQDSsszTIlR6jB9wrtef5u6ibGfzH JxrgXsyUU7C8/Lz3ce1P5hj3EqEt/bKd8OVzlTtoL3JoeGm5IgAAAAAAAA== --------------ms030706000503080602000501-- From shadow@gmail.com Mon Aug 15 03:33:56 2022 From: shadow@gmail.com (Daria Phoebe Brashear) Date: Sun, 14 Aug 2022 22:33:56 -0400 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: <029e8756-be34-0b68-9a5a-b3bbe56ef26b@auristor.com> References: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> <20220814185331.GM24514@kduck.mit.edu> <20220814204031.GN24514@kduck.mit.edu> <20220814212157.GO24514@kduck.mit.edu> <029e8756-be34-0b68-9a5a-b3bbe56ef26b@auristor.com> Message-ID: --00000000000048908505e63e77b0 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 14, 2022 at 22:24 Jeffrey E Altman (jaltman@auristor.com) < jaltman@auristor.com> wrote: > On 8/14/2022 7:01 PM, Ben Huntsman (ben@huntsmans.net) wrote: > > Sure, I agree for testing that's fine. > > But, there is evidence to suggest that this has compiled successfully on > AIX 6.1 and 7.2 in the past, and this issue would have occurred there. > > Ben, > > > The change that you referred to as being similar to the build failure on > AIX is dated Sept 2013. > > > AIX 6.1 was last updated in November 2013. AIX 7.2 was first released in > December 2015. > > > The initial use of krb5_c_make_random_key() was added to OpenAFS in 2007 > but it was for test infrastructure which might not have been built for > AIX. In the years since additional use of that function has been added to > the source tree. However, it is unclear to me at least whether such > changes were built on AIX. > > > The comments on https://gerrit.openafs.org/#/c/14707/3 which was the tip > of the series that added symbols for AIX 7.2 state that the build on AIX > succeeded only if the kernel module was not built and if all linkage was > static. That change series is a little over a year old. > > > The last combination that I can find evidence of the AIX kernel module > working was OpenAFS 1.6.5 and AIX 6.1 TL5 which would have been 32-bit. > OpenAFS 1.6.5 was released in July 2013. > > And there was work needed for even that, given the incompatible struct mbuf changes that broke things across TL5 I would not expect 7.1 to work without at least some kernel changes. -- -- Daria Phoebe Brashear AuriStor, Inc. dariaphoebe.com --00000000000048908505e63e77b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Aug 14, 2022 at 22:24 Jeffrey E Altman (jaltman@auristor.com) <jaltman@auristor.com> wrote:

=20 =20 =20

On 8/14/2022 7:01 PM, Ben Huntsman (ben@huntsmans= .net) wrote:

=20 =20
Sure, I agree for testing that's fine.

But, there is evidence to suggest that this has compiled successfully on AIX 6.1 and 7.2 in the past, and this issue would have occurred there.

Ben,

The change that you referred to as being similar to the build failure on AIX is dated Sept 2013.

AIX 6.1 was last updated in November 2013.=C2=A0=C2=A0 AIX 7.2 was f= irst released in December 2015.

The initial use of krb5_c_make_random_key() was added to OpenAFS in 2007 but it was for test infrastructure which might not have been built for AIX.=C2=A0 In the years since additional use of that function has been added to the source tree.=C2=A0 However, it is unclear to me at least whether such changes were built on AIX.=C2=A0 =

The last combination that I can find evidence of the AIX kernel module working was OpenAFS 1.6.5 and AIX 6.1 TL5 which would have been 32-bit.=C2=A0=C2=A0 OpenAFS 1.6.5 was released in July 2013.

And there was work needed for even that, given the incompatible struct mbu= f changes that broke things across TL5

I would not expect 7.1 to work without at least some kernel = changes.=C2=A0

--
Daria Phoebe Brashear
Au= riStor, Inc.
dariaphoebe.com --00000000000048908505e63e77b0-- From ben@huntsmans.net Mon Aug 15 07:25:46 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Mon, 15 Aug 2022 06:25:46 +0000 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: References: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> <20220814185331.GM24514@kduck.mit.edu> <20220814204031.GN24514@kduck.mit.edu> <20220814212157.GO24514@kduck.mit.edu> <029e8756-be34-0b68-9a5a-b3bbe56ef26b@auristor.com> Message-ID: --_000_MWHPR0701MB36746ADAFBCC6BE89D6A0676A7689MWHPR0701MB3674_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there! Ah, that makes some sense. So presumably there hasn't ever been a succe= ssful build on AIX 6.1 using kerberos. Is it practical to try to build wit= hout it? Thank you! -Ben ________________________________ From: Daria Phoebe Brashear Sent: Sunday, August 14, 2022 7:33 PM To: Jeffrey E Altman (jaltman@auristor.com) Cc: Ben Huntsman ; Benjamin Kaduk ; Ken H= ornstein ; openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_ma= ke_random_key On Sun, Aug 14, 2022 at 22:24 Jeffrey E Altman (jaltman@auristor.com) >= wrote: On 8/14/2022 7:01 PM, Ben Huntsman (ben@huntsmans.net) wrote: Sure, I agree for testing that's fine. But, there is evidence to suggest that this has compiled successfully on AI= X 6.1 and 7.2 in the past, and this issue would have occurred there. Ben, The change that you referred to as being similar to the build failure on AI= X is dated Sept 2013. AIX 6.1 was last updated in November 2013. AIX 7.2 was first released in = December 2015. The initial use of krb5_c_make_random_key() was added to OpenAFS in 2007 bu= t it was for test infrastructure which might not have been built for AIX. = In the years since additional use of that function has been added to the so= urce tree. However, it is unclear to me at least whether such changes were= built on AIX. The comments on https://gerrit.openafs.org/#/c/14707/3 which was the tip of= the series that added symbols for AIX 7.2 state that the build on AIX succ= eeded only if the kernel module was not built and if all linkage was static= . That change series is a little over a year old. The last combination that I can find evidence of the AIX kernel module work= ing was OpenAFS 1.6.5 and AIX 6.1 TL5 which would have been 32-bit. OpenA= FS 1.6.5 was released in July 2013. And there was work needed for even that, given the incompatible struct mbuf= changes that broke things across TL5 I would not expect 7.1 to work without at least some kernel changes. -- -- Daria Phoebe Brashear AuriStor, Inc. dariaphoebe.com --_000_MWHPR0701MB36746ADAFBCC6BE89D6A0676A7689MWHPR0701MB3674_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there!

Ah, that makes some sense. So presumably there hasn't ev= er been a successful build on AIX 6.1 using kerberos. Is it practical= to try to build without it?

Thank you!

-Ben

From: Daria Phoebe Brashear= <shadow@gmail.com>
Sent: Sunday, August 14, 2022 7:33 PM
To: Jeffrey E Altman (jaltman@auristor.com) <jaltman@auristor.com= >
Cc: Ben Huntsman <ben@huntsmans.net>; Benjamin Kaduk <kaduk= @mit.edu>; Ken Hornstein <kenh@cmf.nrl.navy.mil>; openafs-devel@op= enafs.org <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .kr= b5_c_make_random_key

On Sun, Aug 14, 2022 at 22:24 Jeffr= ey E Altman (jaltman@auristor.com) <jaltman@auristor.com>= ; wrote:

On 8/14/2022 7:01 PM, Ben Huntsman (ben@huntsmans.net) wrote:

Sure, I agree for testing that's fine.

But, there is evidence to suggest that this has compiled successfully on AI= X 6.1 and 7.2 in the past, and this issue would have occurred there.

Ben,

The change that you referred to as being similar to the build failure on= AIX is dated Sept 2013.

AIX 6.1 was last updated in November 2013. AIX 7.2 was first= released in December 2015.

The initial use of krb5_c_make_random_key() was added to OpenAFS in 2007= but it was for test infrastructure which might not have been built for AIX= . In the years since additional use of that function has been added t= o the source tree. However, it is unclear to me at least whether such changes were built on AIX.

The comments on https://gerrit.openafs.org/#/c/14707/3 which was the tip of the series = that added symbols for AIX 7.2 state that the build on AIX succeeded only i= f the kernel module was not built and if all linkage was static. = ; That change series is a little over a year old.

The last combination that I can find evidence of the AIX kernel module w= orking was OpenAFS 1.6.5 and AIX 6.1 TL5 which would have been 32-bit. = ; OpenAFS 1.6.5 was released in July 2013.

And there was work needed for even that, given the incomp= atible struct mbuf changes that broke things across TL5

I would not expect 7.1 to work without at least some kern= el changes.

--
Daria Phoebe Brashear
AuriStor, Inc.
dariaphoebe.com

--_000_MWHPR0701MB36746ADAFBCC6BE89D6A0676A7689MWHPR0701MB3674_-- From ben@huntsmans.net Mon Aug 15 07:27:55 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Mon, 15 Aug 2022 06:27:55 +0000 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: References: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> <20220814185331.GM24514@kduck.mit.edu> <20220814204031.GN24514@kduck.mit.edu> <20220814212157.GO24514@kduck.mit.edu> <029e8756-be34-0b68-9a5a-b3bbe56ef26b@auristor.com> Message-ID: --_000_MWHPR0701MB3674A3291C36E4A7A58BFA69A7689MWHPR0701MB3674_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So looking into a build on AIX 7.1 was where I was going next, I was just t= rying to get it working on AIX 6.1 for reference. There's something significant in AIX 7.1 that doesn't work with OpenAFS, bu= t which is not also present in AIX 7.2? Thank you! -Ben ________________________________ From: Daria Phoebe Brashear Sent: Sunday, August 14, 2022 7:33 PM To: Jeffrey E Altman (jaltman@auristor.com) Cc: Ben Huntsman ; Benjamin Kaduk ; Ken H= ornstein ; openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_ma= ke_random_key On Sun, Aug 14, 2022 at 22:24 Jeffrey E Altman (jaltman@auristor.com) >= wrote: On 8/14/2022 7:01 PM, Ben Huntsman (ben@huntsmans.net) wrote: Sure, I agree for testing that's fine. But, there is evidence to suggest that this has compiled successfully on AI= X 6.1 and 7.2 in the past, and this issue would have occurred there. Ben, The change that you referred to as being similar to the build failure on AI= X is dated Sept 2013. AIX 6.1 was last updated in November 2013. AIX 7.2 was first released in = December 2015. The initial use of krb5_c_make_random_key() was added to OpenAFS in 2007 bu= t it was for test infrastructure which might not have been built for AIX. = In the years since additional use of that function has been added to the so= urce tree. However, it is unclear to me at least whether such changes were= built on AIX. The comments on https://gerrit.openafs.org/#/c/14707/3 which was the tip of= the series that added symbols for AIX 7.2 state that the build on AIX succ= eeded only if the kernel module was not built and if all linkage was static= . That change series is a little over a year old. The last combination that I can find evidence of the AIX kernel module work= ing was OpenAFS 1.6.5 and AIX 6.1 TL5 which would have been 32-bit. OpenA= FS 1.6.5 was released in July 2013. And there was work needed for even that, given the incompatible struct mbuf= changes that broke things across TL5 I would not expect 7.1 to work without at least some kernel changes. -- -- Daria Phoebe Brashear AuriStor, Inc. dariaphoebe.com --_000_MWHPR0701MB3674A3291C36E4A7A58BFA69A7689MWHPR0701MB3674_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So looking into a build on AIX 7.1 was where I was going next, I was just t= rying to get it working on AIX 6.1 for reference.

There's something significant in AIX 7.1 that doesn't work with OpenAFS, bu= t which is not also present in AIX 7.2?

Thank you!

-Ben

On Sun, Aug 14, 2022 at 22:24 Jeffr= ey E Altman (jaltman@auristor.com) <jaltman@auristor.com>= ; wrote:

On 8/14/2022 7:01 PM, Ben Huntsman (ben@huntsmans.net) wrote:

Sure, I agree for testing that's fine.

But, there is evidence to suggest that this has compiled successfully on AI= X 6.1 and 7.2 in the past, and this issue would have occurred there.

Ben,

The change that you referred to as being similar to the build failure on= AIX is dated Sept 2013.

AIX 6.1 was last updated in November 2013. AIX 7.2 was first= released in December 2015.

The initial use of krb5_c_make_random_key() was added to OpenAFS in 2007= but it was for test infrastructure which might not have been built for AIX= . In the years since additional use of that function has been added t= o the source tree. However, it is unclear to me at least whether such changes were built on AIX.

The comments on https://gerrit.openafs.org/#/c/14707/3 which was the tip of the series = that added symbols for AIX 7.2 state that the build on AIX succeeded only i= f the kernel module was not built and if all linkage was static. = ; That change series is a little over a year old.

The last combination that I can find evidence of the AIX kernel module w= orking was OpenAFS 1.6.5 and AIX 6.1 TL5 which would have been 32-bit. = ; OpenAFS 1.6.5 was released in July 2013.

And there was work needed for even that, given the incomp= atible struct mbuf changes that broke things across TL5

I would not expect 7.1 to work without at least some kern= el changes.

--
Daria Phoebe Brashear
AuriStor, Inc.
dariaphoebe.com

--_000_MWHPR0701MB3674A3291C36E4A7A58BFA69A7689MWHPR0701MB3674_-- From jaltman@auristor.com Mon Aug 15 13:49:33 2022 From: jaltman@auristor.com (Jeffrey E Altman) Date: Mon, 15 Aug 2022 08:49:33 -0400 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: References: <202208141725.27EHPOKB012457@hedwig.cmf.nrl.navy.mil> <20220814185331.GM24514@kduck.mit.edu> <20220814204031.GN24514@kduck.mit.edu> <20220814212157.GO24514@kduck.mit.edu> <029e8756-be34-0b68-9a5a-b3bbe56ef26b@auristor.com> Message-ID: <05a2cb20-4513-d2b5-36f4-7d54f4cd1b3f@auristor.com> This is a cryptographically signed message in MIME format. --------------ms040907050205040906090008 Content-Type: multipart/alternative; boundary="------------2bAVOIh3Vg5mj6qRu2CjBtsD" --------------2bAVOIh3Vg5mj6qRu2CjBtsD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 8/15/2022 2:25 AM, Ben Huntsman (ben@huntsmans.net) wrote: > Hi there! > Ah, that makes some sense. So presumably there hasn't ever been a > successful build on AIX 6.1 using kerberos. Is it practical to try to > build without it? > AIX was built with Kerberos 5. As I said, it was known to work for AIX 6.1 TL5 and OpenAFS 1.6.5. Somewhere between AIX 6.1 TL5 and TL8 the kernel module stopped functioning properly and no one ever had the combination of desire, skills, knowledge and access to AIX systems to figure out why. The build failures you are experiencing could be for several reasons: * The wrong libraries are being used because of 32-bit vs 64-bit. o How many versions of krb5-config are there? Are there two, one for 32-bit and the other for 64-bit? * Perhaps krb5_c_make_random_key isn't in the export list for AIX? * Other broken behavior in the configure tests related to AIX. --------------2bAVOIh3Vg5mj6qRu2CjBtsD Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 8/15/2022 2:25 AM, Ben Huntsman (ben@huntsmans.net) wrote:

Hi there!

Ah, that makes some sense. So presumably there hasn't ever been a successful build on AIX 6.1 using kerberos. Is it practical to try to build without it?

AIX was built with Kerberos 5. As I said, it was known to work for AIX 6.1 TL5 and OpenAFS 1.6.5.

Somewhere between AIX 6.1 TL5 and TL8 the kernel module stopped functioning properly and no one ever had the combination of desire, skills, knowledge and access to AIX systems to figure out why.

The build failures you are experiencing could be for several reasons:

The wrong libraries are being used because of 32-bit vs 64-bit.

How many versions of krb5-config are there? Are there two, one for 32-bit and the other for 64-bit?

Perhaps krb5_c_make_random_key isn't in the export list for AIX?
Other broken behavior in the configure tests related to AIX.

--------------2bAVOIh3Vg5mj6qRu2CjBtsD-- --------------ms040907050205040906090008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DHEwggXSMIIEuqADAgECAhBAAYJpmi/rPn/F0fJyDlzMMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEz MB4XDTIyMDgwNDE2MDQ0OFoXDTI1MTAzMTE2MDM0OFowcDEvMC0GCgmSJomT8ixkAQETH0Ew MTQxMEQwMDAwMDE4MjY5OUEyRkQyMDAwMjMzQ0QxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRt YW4xFTATBgNVBAoTDEF1cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCkC7PKBBZnQqDKPtZPMLAy77zo2DPvwtGnd1hNjPvbXrpGxUb3 xHZRtv179LHKAOcsY2jIctzieMxf82OMyhpBziMPsFAG/ukihBMFj3/xEeZVso3K27pSAyyN fO/wJ0rX7G+ges22Dd7goZul8rPaTJBIxbZDuaykJMGpNq4PQ8VPcnYZx+6b+nJwJJoJ46kI EEfNh3UKvB/vM0qtxS690iAdgmQIhTl+qfXq4IxWB6b+3NeQxgR6KLU4P7v88/tvJTpxIKkg 9xj89ruzeThyRFd2DSe3vfdnq9+g4qJSHRXyTft6W3Lkp7UWTM4kMqOcc4VSRdufVKBQNXjG IcnhAgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAwgYQGCCsGAQUFBwEBBHgwdjAwBggr BgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUF BzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWEx My5wN2MwHwYDVR0jBBgwFoAULbfeG1l+KpguzeHUG+PFEBJe6RQwCQYDVR0TBAIwADCCASsG A1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIBFj5odHRwczov L3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRt bDCBugYIKwYBBQUHAgIwga0MgapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4g aXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRp ZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8v dmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTMuY3JsMB8GA1UdEQQY MBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBQB+nzqgljLocLTsiUn2yWqEc2s gjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJwV eycprp8Ox1npiTyfwc5QaVaqtoe8Dcg2JXZc0h4DmYGW2rRLHp8YL43snEV93rPJVk6B2v4c WLeQfaMrnyNeEuvHx/2CT44cdLtaEk5zyqo3GYJYlLcRVz6EcSGHv1qPXgDT0xB/25etwGYq utYF4Chkxu4KzIpq90eDMw5ajkexw+8ARQz4N5+d6NRbmMCovd7wTGi8th/BZvz8hgKUiUJo Qle4wDxrdXdnIhCP7g87InXKefWgZBF4VX21t2+hkc04qrhIJlHrocPG9mRSnnk2WpsY0MXt a8ivbVKtfpY7uSNDZSKTDi1izEFH5oeQdYRkgIGb319a7FjslV8wggaXMIIEf6ADAgECAhBA AXA7OrqBjMk8rp4OuNQSMA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK EwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAe Fw0yMDAyMTIyMTA3NDlaFw0zMDAyMTIyMTA3NDlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK EwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAu6sUO01SDD99PM+QdZkNxKxJNt0NgQE+Zt6ixaNP0JKSjTd+SG5L wqxBWjnOgI/3dlwgtSNeN77AgSs+rA4bK4GJ75cUZZANUXRKw/et8pf9Qn6iqgB63OdHxBN/ 15KbM3HR+PyiHXQoUVIevCKW8nnlWnnZabT1FejOhRRKVUg5HACGOTfnCOONrlxlg+m1Vjgn o1uNqNuLM/jkD1z6phNZ/G9IfZGI0ppHX5AA/bViWceX248VmefNhSR14ADZJtlAAWOi2un0 3bqrBPHA9nDyXxI8rgWLfUP5rDy8jx2hEItg95+ORF5wfkGUq787HBjspE86CcaduLka/Bk2 VwIDAQABo4IChzCCAoMwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwgYkG CCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVu dHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t L3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C 5yZUyI42djCCASQGA1UdIASCARswggEXMIIBEwYEVR0gADCCAQkwSgYIKwYBBQUHAgEWPmh0 dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRl eC5odG1sMIG6BggrBgEFBQcCAjCBrQyBqlRoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMg YmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIElkZW5UcnVzdCdzIFRydXN0SUQgQ2Vy dGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20v Y2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEoGA1UdHwRDMEEwP6A9oDuGOWh0 dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL2NvbW1lcmNpYWxyb290Y2ExLmNy bDAdBgNVHQ4EFgQULbfeG1l+KpguzeHUG+PFEBJe6RQwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4ICAQB/7BKcygLX6Nl4a03cDHt7TLdPxCzFvDF2 bkVYCFTRX47UfeomF1gBPFDee3H/IPlLRmuTPoNt0qjdpfQzmDWN95jUXLdLPRToNxyaoB5s 0hOhcV6H08u3FHACBif55i0DTDzVSaBv0AZ9h1XeuGx4Fih1Vm3Xxz24GBqqVudvPRLyMJ7u 6hvBqTIKJ53uCs3dyQLZT9DXnp+kJv8y7ZSAY+QVrI/dysT8avtn8d7k7azNBkfnbRq+0e88 QoBnel6u+fpwbd5NLRHywXeH+phbzULCa+bLPRMqJaW2lbhvSWrMHRDy3/d8HvgnLCBFK2s4 Spns4YCN4xVcbqlGWzgolHCKUH39vpcsDo1ymZFrJ8QR6ihIn8FmJ5oKwAnnd/G6ADXFC9bu db9+532phSAXOZrrecIQn+vtP366PC+aClAPsIIDJDsotS5z4X2JUFsNIuEgXGqhiKE7SuZb rFG9sdcLprSlJN7TsRDc0W2b9nqwD+rj/5MN0C+eKwha+8ydv0+qzTyxPP90KRgaegGowC4d UsZyTk2n4Z3MuAHX5nAZL/Vh/SyDj/ajorV44yqZBzQ3ChKhXbfUSwe2xMmygA2Z5DRwMRJn p/BscizYdNk2WXJMTnH+wVLN8sLEwEtQR4eTLoFmQvrK2AMBS9kW5sBkMzINt/ZbbcZ3F+eA MDGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUG A1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwDQYJYIZIAWUDBAIBBQCg ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgxNTEy NDkzM1owLwYJKoZIhvcNAQkEMSIEIB9dz/Sct8i1LH3K1F8CAd0SnglhFN6KbLOZjc9enSlX MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAJWJV OQB21kSm6f1XVfHa8vsDQbjl4Fof2pgw67LQ68cMyBNdYlsk9V3j5ngifAbDnvA2EraZ/Qo+ /4cdxS3NR2M9bt2bJZEf/EIoDznoDx4BNQ1ahzGl6iBsoOoj/Z2+P8K0rJnNLTKsB/iY758Q UskJHzPy14WXGpOLXd4N1ZLJJ+bCFPjPPHZQ95g7vOjMga1WLrkA65v/FG8VsFobkW3vPrZ1 zC59UeGA+y+hbHFLPMt5HcZ+pSES7lMcQbCRxS9/4PbC3Y3C4WuEPhyLmcXfU5aU2d6NJcSx 1cOJZ0vOrzwSTUhNMgaL9VWshI+Gpm6g1WDLguQ9yB8AH6bw+gAAAAAAAA== --------------ms040907050205040906090008-- From ben@huntsmans.net Mon Aug 15 20:07:09 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Mon, 15 Aug 2022 19:07:09 +0000 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key Message-ID: --_000_MWHPR0701MB3674EA646E07BFF858BF8195A7689MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ok, I got the whole tree to build! Now to test! I had to add one more symbol to an .sym file, fix one of the Makefiles for = AIX, and I manually edited one of the generated Makefiles to append -lk5cry= pto to the kerberos libs. One thing I noticed, it seems that the rc files for AIX in src/afsd are not= installed, and are only referenced in the "make dest" target. Furthermore= , they seem to be hard-coded to expect Transarc-style paths. Did anyone bu= ild for AIX using openafs-style paths? Thanks. -Ben ________________________________ From: Jeffrey E Altman Sent: Monday, August 15, 2022 5:49 AM To: Ben Huntsman; Daria Phoebe Brashear Cc: Benjamin Kaduk; Ken Hornstein; openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_ma= ke_random_key On 8/15/2022 2:25 AM, Ben Huntsman (ben@huntsmans.net) wrote: Hi there! Ah, that makes some sense. So presumably there hasn't ever been a succe= ssful build on AIX 6.1 using kerberos. Is it practical to try to build wit= hout it? AIX was built with Kerberos 5. As I said, it was known to work for AIX 6.= 1 TL5 and OpenAFS 1.6.5. Somewhere between AIX 6.1 TL5 and TL8 the kernel module stopped functioning= properly and no one ever had the combination of desire, skills, knowledge = and access to AIX systems to figure out why. The build failures you are experiencing could be for several reasons: * The wrong libraries are being used because of 32-bit vs 64-bit. * How many versions of krb5-config are there? Are there two, one f= or 32-bit and the other for 64-bit? * Perhaps krb5_c_make_random_key isn't in the export list for AIX? * Other broken behavior in the configure tests related to AIX. --_000_MWHPR0701MB3674EA646E07BFF858BF8195A7689MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ok, I got the whole tree to build! Now to test!

I had to add one more symbol to an .sym file, fix one of the Makefiles for = AIX, and I manually edited one of the generated Makefiles to append -lk5cry= pto to the kerberos libs.

One thing I noticed, it seems that the rc files for AIX in src/afsd are not= installed, and are only referenced in the "make dest" target.&nb= sp; Furthermore, they seem to be hard-coded to expect Transarc-style paths.= Did anyone build for AIX using openafs-style paths?

Thanks.

-Ben

From: Jeffrey E Altman
Sent: Monday, August 15, 2022 5:49 AM
To: Ben Huntsman; Daria Phoebe Brashear
Cc: Benjamin Kaduk; Ken Hornstein; openafs-devel@openafs.org
Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .kr= b5_c_make_random_key

On 8/15/2022 2:25 AM, Ben Huntsman (ben@hunt= smans.net) wrote:

Hi there!

Ah, that makes some sense. So presumably there hasn't ev= er been a successful build on AIX 6.1 using kerberos. Is it practical= to try to build without it?

AIX was built with Kerber= os 5. As I said, it was known to work for AIX 6.1 TL5 and OpenA= FS 1.6.5.

Somewhere between AIX 6.1= TL5 and TL8 the kernel module stopped functioning properly and no one ever= had the combination of desire, skills, knowledge and access to AIX systems= to figure out why.

The build failures you ar= e experiencing could be for several reasons:

The wrong libraries are being used because of 32-bit vs 64-bit. <= br>

How many versions of krb5-config are there? Are there two, = one for 32-bit and the other for 64-bit?

Perhaps krb5_c_make_random_key isn't in the export list for AIX?

Other broken behavior in the configure tests related to AIX.

--_000_MWHPR0701MB3674EA646E07BFF858BF8195A7689MWHPR0701MB3674_-- From kaduk@mit.edu Mon Aug 15 20:28:27 2022 From: kaduk@mit.edu (Benjamin Kaduk) Date: Mon, 15 Aug 2022 12:28:27 -0700 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: References: Message-ID: <20220815192827.GP24514@kduck.mit.edu> On Mon, Aug 15, 2022 at 07:07:09PM +0000, Ben Huntsman wrote: > Ok, I got the whole tree to build! Now to test! > I had to add one more symbol to an .sym file, fix one of the Makefiles for AIX, and I manually edited one of the generated Makefiles to append -lk5crypto to the kerberos libs. Exciting! > One thing I noticed, it seems that the rc files for AIX in src/afsd are not installed, and are only referenced in the "make dest" target. Furthermore, they seem to be hard-coded to expect Transarc-style paths. Did anyone build for AIX using openafs-style paths? Those two are probably related -- "make dest" is intrinsically tied to Transarc-style paths, and I could see someone deciding to just only install the rc file for "make dest" instead of trying to come up with a scheme to translate the paths. Also, we've generally been trending toward not shipping rc files or packaging in general in the main openafs tree when there is an external/authoritative packaging system for the OS in question. E.g., the Debian packaging is managed by the debian maintainer (me) at https://salsa.debian.org/debian/openafs/ , FreeBSD packaging would be managed in the FreeBSD ports tree, etc. I don't know if there's a canonical packaging system for AIX, though, so maybe that doesn't apply -- we still have the RPM packaging in-tree since there's not a single central place that would pick it up. -Ben From ben@huntsmans.net Mon Aug 15 20:59:10 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Mon, 15 Aug 2022 19:59:10 +0000 Subject: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_make_random_key In-Reply-To: <20220815192827.GP24514@kduck.mit.edu> References: <20220815192827.GP24514@kduck.mit.edu> Message-ID: --_000_MWHPR0701MB3674C5885CFE7CF68804E243A7689MWHPR0701MB3674_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For AIX, the easiest thing would probably be to have the configure scripts = fix the paths in src/afsd/rc.afs.rs_aix, and then to have "make install" dr= op it in /etc. ________________________________ From: Benjamin Kaduk Sent: Monday, August 15, 2022 12:28 PM To: Ben Huntsman Cc: openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .krb5_c_ma= ke_random_key On Mon, Aug 15, 2022 at 07:07:09PM +0000, Ben Huntsman wrote: > Ok, I got the whole tree to build! Now to test! > I had to add one more symbol to an .sym file, fix one of the Makefiles fo= r AIX, and I manually edited one of the generated Makefiles to append -lk5c= rypto to the kerberos libs. Exciting! > One thing I noticed, it seems that the rc files for AIX in src/afsd are n= ot installed, and are only referenced in the "make dest" target. Furthermo= re, they seem to be hard-coded to expect Transarc-style paths. Did anyone = build for AIX using openafs-style paths? Those two are probably related -- "make dest" is intrinsically tied to Transarc-style paths, and I could see someone deciding to just only install the rc file for "make dest" instead of trying to come up with a scheme to translate the paths. Also, we've generally been trending toward not shipping rc files or packaging in general in the main openafs tree when there is an external/authoritative packaging system for the OS in question. E.g., the Debian packaging is managed by the debian maintainer (me) at https://salsa.debian.org/debian/openafs/ , FreeBSD packaging would be managed in the FreeBSD ports tree, etc. I don't know if there's a canonical packaging system for AIX, though, so maybe that doesn't apply -- we still have the RPM packaging in-tree since there's not a single central place that would pick it up. -Ben --_000_MWHPR0701MB3674C5885CFE7CF68804E243A7689MWHPR0701MB3674_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For AIX, the easiest thing would probably be to have the configure scripts = fix the paths in src/afsd/rc.afs.rs_aix, and then to have "make instal= l" drop it in /etc.

From: Benjamin Kaduk <ka= duk@mit.edu>
Sent: Monday, August 15, 2022 12:28 PM
To: Ben Huntsman <ben@huntsmans.net>
Cc: openafs-devel@openafs.org <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] AIX build fails with missing symbol .kr= b5_c_make_random_key

On Mon, Aug 15, 2022 at 07:07:09PM +0000, Ben Hunt= sman wrote:
> Ok, I got the whole tree to build! Now to test!
> I had to add one more symbol to an .sym file, fix one of the Makefiles= for AIX, and I manually edited one of the generated Makefiles to append -l= k5crypto to the kerberos libs.

Exciting!

> One thing I noticed, it seems that the rc files for AIX in src/afsd ar= e not installed, and are only referenced in the "make dest" targe= t. Furthermore, they seem to be hard-coded to expect Transarc-style p= aths. Did anyone build for AIX using openafs-style paths?

Those two are probably related -- "make dest" is intrinsically ti= ed to
Transarc-style paths, and I could see someone deciding to just only install=
the rc file for "make dest" instead of trying to come up with a s= cheme to
translate the paths.

Also, we've generally been trending toward not shipping rc files or
packaging in general in the main openafs tree when there is an
external/authoritative packaging system for the OS in question. E.g.,= the
Debian packaging is managed by the debian maintainer (me) at
https://salsa.debian.o= rg/debian/openafs/ , FreeBSD packaging would be
managed in the FreeBSD ports tree, etc. I don't know if there's a
canonical packaging system for AIX, though, so maybe that doesn't apply --<= br> we still have the RPM packaging in-tree since there's not a single central<= br> place that would pick it up.

-Ben

--_000_MWHPR0701MB3674C5885CFE7CF68804E243A7689MWHPR0701MB3674_-- From ben@huntsmans.net Mon Aug 15 21:18:39 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Mon, 15 Aug 2022 20:18:39 +0000 Subject: [OpenAFS-devel] Running afsd on AIX Message-ID: --_000_MWHPR0701MB36749E06BD652BCB1CA2DEBEA7689MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi guys- Changing the subject to keep topics making sense... Ok, I built using the prefix /opt/openafs. Everything is in there. The= re are some issues: 1. On AIX, the install stripped the execute flags from /opt/openafs/lib/ope= nafs/cfgafs64 and cfgexport64 I added it back and the export and afs kernel module loaded! 2. Running afsd fails: bash-4.2# /opt/openafs/sbin/afsd -stat 300 -dcache 100 -daemons 2 -volumes = 50 exec(): 0509-036 Cannot load program /opt/openafs/sbin/afsd because of the = following errors: 0509-150 Dependent module /opt/openafs/lib/librokenafs.a(libroken= afs.so.2) could not be loaded. 0509-152 Member librokenafs.so.2 is not found in archive Something seems to be messed up with the linking: bash-4.2# dump -H /opt/openafs/sbin/afsd /opt/openafs/sbin/afsd: ***Loader Section*** Loader Header Information VERSION# #SYMtableENT #RELOCent LENidSTR 0x00000001 0x00000043 0x000000a4 0x000002b9 #IMPfilID OFFidSTR LENstrTBL OFFstrTBL 0x0000000b 0x00000e18 0x000001b4 0x000010d1 ***Import File Strings*** INDEX PATH BASE MEMBER 0 /project/openafs/src/auth/.libs:/project/openafs/src/audit/.libs:/pr= oject/openafs/src/rxkad/.libs:/project/openafs/src/crypto/rfc3961/.libs:/pr= oject/openafs/src/util/.libs:/project/openafs/src/sys/.libs:/project/openaf= s/src/cmd/.libs:/project/openafs/src/comerr/.libs:/project/openafs/src/rx/.= libs:/project/openafs/src/opr/.libs:/opt/openafs/lib:/opt/IBM/xlmass/8.1.3/= lib/aix61:/opt/IBM/xlc/13.1.3/lib:/usr/lib:/lib 1 libc.a shr.o 2 libpthread.a shr_xpg5.o 3 liboafs_opr.a liboafs_opr.so.0 4 liboafs_util.a liboafs_util.so.0 5 liboafs_cmd.a liboafs_cmd.so.0 6 liboafs_sys.a liboafs_sys.so.0 7 liboafs_auth.a liboafs_auth.so.0 8 librokenafs.a librokenafs.so.2 9 libafshcrypto.a libafshcrypto.so.2 10 / unix Is this libtool's doing? Thanks! -Ben --_000_MWHPR0701MB36749E06BD652BCB1CA2DEBEA7689MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi guys-

Changing the subject to keep topics making sense...

Ok, I built using the prefix /opt/openafs. Everything is= in there. There are some issues:

1. On AIX, the install stripped the execute flags from /opt/openafs/lib/ope= nafs/cfgafs64 and cfgexport64

I added it back and the export and afs kernel module loaded!

2. Running afsd fails:

bash-4.2# /opt/openafs/sbin/afsd -stat 300 -dcache 100 -daemons 2 -volumes = 50

exec(): 0509-036 Cannot load program /opt/openafs/sbin/afsd because of= the following errors:

0509-150 Dependent module /opt/open= afs/lib/librokenafs.a(librokenafs.so.2) could not be loaded.

0509-152 Member librokenafs.so.2 is= not found in archive

Something seems to be messed up with the linking:

bash-4.2# dump -H /opt/openafs/sbin/afsd

/opt/openafs/sbin/afsd:

= ***Loader Section***

= Loader Header Information

VERSION# #SYMtableENT #RELOC= ent LENidSTR

0x00000001 0x00000043 0x0000= 00a4 0x000002b9

#IMPfilID OFFidSTR &nb= sp; LENstrTBL OFFstrTBL

0x0000000b 0x00000e18 0x0000= 01b4 0x000010d1

= ***Import File Strings***

INDEX PATH &nbs= p; BASE = ; MEMBER

0 /project/openafs/src/auth/.libs:/project/openafs= /src/audit/.libs:/project/openafs/src/rxkad/.libs:/project/openafs/src/cryp= to/rfc3961/.libs:/project/openafs/src/util/.libs:/project/openafs/src/sys/.= libs:/project/openafs/src/cmd/.libs:/project/openafs/src/comerr/.libs:/proj= ect/openafs/src/rx/.libs:/project/openafs/src/opr/.libs:/opt/openafs/lib:/o= pt/IBM/xlmass/8.1.3/lib/aix61:/opt/IBM/xlc/13.1.3/lib:/usr/lib:/lib

1 = ; libc.a &nbs= p; shr.o

2 = ; libpthread.a = ; shr_xpg5.o

3 = ; liboafs_opr.a &nbs= p; liboafs_opr.so.0

4 = ; liboafs_util.a &nb= sp; liboafs_util.so.0

5 = ; liboafs_cmd.a &nbs= p; liboafs_cmd.so.0

6 = ; liboafs_sys.a &nbs= p; liboafs_sys.so.0

7 = ; liboafs_auth.a &nb= sp; liboafs_auth.so.0

8 = ; librokenafs.a &nbs= p; librokenafs.so.2

9 = ; libafshcrypto.a &n= bsp; libafshcrypto.so.2

10 / &n= bsp; unix

Is this libtool's doing?

Thanks!

-Ben

--_000_MWHPR0701MB36749E06BD652BCB1CA2DEBEA7689MWHPR0701MB3674_-- From ben@huntsmans.net Tue Aug 16 07:50:50 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Tue, 16 Aug 2022 06:50:50 +0000 Subject: [OpenAFS-devel] Latest build kernel panic on AIX 6.1 6100-09-12 Message-ID: --_000_MWHPR0701MB367403D583B4D648B36695EDA76B9MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi guys- Ok, I got the build done, but as predicted, it kernel panics the system: # /opt/openafs/sbin/afsd -stat 300 -dcache 100 -daemons 2 -volumes 50 afs: Binding rx to 0.0.0.0:7001 ... and then it panics. Before running afsd, I loaded the export and kerne= l module, and those went just fine. The panic only occurs when starting af= sd. I configured a dump device and did some basic looking. Here's the stack tr= ace from the dump: CRASH INFORMATION: CPU 0 CSA F00000002FF47600 at time of crash, error code for LEDs: 30000000 pvthread+01DB00 STACK: [0000E864]___memset64+00005C () [F1000000C04C1AF4]rxevent_alloc+000094 () [F1000000C04C2058]rxevent_Post+000038 (F00000002FF46D28, F00000002FF46D20, F1000000C0592ED8, 0000000000000000, 0000000000000000, 0000000000000000) [F1000000C04AE890]rxi_ReapConnections+000630 (0000000000000000, 00000000000= 00000, 0000000000000000, 0000000000000000) [F1000000C04AE9E0]rx_StartServer+0000E0 (0000000000000000) [F1000000C0536E78]afs_ResourceInit+0002D8 (??) [F1000000C0542A30]afs_InitSetup+0001B0 (0000019000000190) [F1000000C0543160]afs_syscall_call+000120 (0000000000000000, 00000000000001= 90, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000) [F1000000C0557D5C]syscall+0000DC (0000001C0000001C, 0000000000000000, 0000019000000190, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000) [00014D70].hkey_legacy_gate+00004C () [00003888]mfspurr_sc_flih01+0000E4 () [kdb_get_virtual_memory] no real storage @ FFFFFFFF3FFFE60 [kdb_read_mem] no real storage @ FFFFFFFFFFF6150 And here's the mst: Machine State Save Area iar : 000000000000E864 msr : 8000000000009032 cr : 24224244 lr : F1000000C04C1AF8 ctr : 0000000000000000 xer : 00000008 mq : DEADBEEF asr : FFFFFFFFFFFFFFFF amr : 0008C00000000000 r0 : FFFFFFFFFFFFFFFF r1 : F00000002FF46B70 r2 : F1000000C05945A0 r3 : 00000000DEADBEEF r4 : 0000000000000068 r5 : 0000000000000000 r6 : 0000000000000000 r7 : 0000000000000000 r8 : 0000000000000000 r9 : 0000000000000000 r10 : 00000000DEADBEEF r11 : 00000000DEADBF57 r12 : 0000000000000007 r13 : F1000A03E05B7000 r14 : 0000000000000009 r15 : 000000002FF22CAC r16 : 000000002FF22CD4 r17 : 00000000DEADBEEF r18 : 00000000DEADBEEF r19 : 00000000F135E1D8 r20 : 00000000DEADBEEF r21 : 00000000DEADBEEF r22 : 0000000020000444 r23 : 00000000DEADBEEF r24 : 00000000DEADBEEF r25 : 0000000020020CD8 r26 : 0000000020022F08 r27 : 000000002FF1F5A0 r28 : 0000000000000000 r29 : 0000000020022F08 r30 : F1000000C05874D8 r31 : F1000000C0597EC8 prev 0000000000000000 stackfix 0000000000000000 int_ticks 0000 cfar 00000000001FCC6C kjmpbuf 0000000000000000 excbranch 0000000000000000 no_pfault 00 intpri 0B backt 00 flags 00 hw_fru_id 00000000 hw_cpu_id 00000000 fpscr 0000000000000000 fpscrx 00000000 fpowner 01 fpeu 01 fpinfo 00 alloc F000 o_iar 000000000000E864 o_toc F1000000C05945A0 o_arg1 00000000DEADBEEF o_vaddr 00000000DEADBEEF krlockp 0000000000000000 rmgrwa F1000816B0035E20 amrstackhigh F00000002FFCCFF0 amrstacklow F00000002FFCC000 amrstackcur F00000002FFCCFE0 amrstackfix 0000000000000000 kstackhigh 0000000000000000 kstacksize 00000000 frrstart 700DFEED00000000 frrend 700DFEED00000000 frrcur 700DFEED00000000 frrstatic 0000 kjmpfrroff 0000 frrovcnt 0000 frrbarrcnt 0000 frrmask 00 callrmgr 00 Except : excp_type 00000086 EXCEPT_PROT orgea 00000000DEADBEEF dsisr 000000000A000000 bit set: DSISR_PROT DSISR_S= T vmh 0000000009000D90 curea 00000000DEADBEEF pftyp 0000000000000106 I haven't done a ton of kernel debugging, but DSISR_PROT DSISR_ST seems to = mean that there was a protection exception. Does anything jump out to anyone? I will try re-compiling with --enable-de= bug and --enable-debug-kernel and see if that provides any more info. So would this be more of a problem with the kernel module, or with afsd? Thanks! -Ben --_000_MWHPR0701MB367403D583B4D648B36695EDA76B9MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi guys-

Ok, I got the build done, but as predicted, it kernel panics t= he system:

# /opt/openafs/sbin/afsd -stat 300 -dcache 100 -daemons 2 -volumes 50

afs: Binding rx to 0.0.0.0:7001

... and then it panics. Before running afsd, I loaded the export and = kernel module, and those went just fine. The panic only occurs when s= tarting afsd.

I configured a dump device and did some basic looking. Here's the sta= ck trace from the dump:

CRASH INFORMATION:

CPU 0 CSA F00000002FF47600 at time of crash, error code for LEDs: 3000= 0000

pvthread+01DB00 STACK:

[0000E864]___memset64+00005C ()

[F1000000C04C1AF4]rxevent_alloc+000094 ()

[F1000000C04C2058]rxevent_Post+000038 (F00000002FF46D28, F00000002FF46= D20,

F1000000C0592ED8, 0000000000000000, 0000000000000000, 000= 0000000000000)

[F1000000C04AE890]rxi_ReapConnections+000630 (0000000000000000, 000000= 0000000000,

0000000000000000, 0000000000000000)

[F1000000C04AE9E0]rx_StartServer+0000E0 (0000000000000000)

[F1000000C0536E78]afs_ResourceInit+0002D8 (??)

[F1000000C0542A30]afs_InitSetup+0001B0 (0000019000000190)

[F1000000C0543160]afs_syscall_call+000120 (0000000000000000, 000000000= 0000190,

0000000000000000, 0000000000000000, 0000000000000000, 000= 0000000000000)

[F1000000C0557D5C]syscall+0000DC (0000001C0000001C, 0000000000000000,<= /div>

0000019000000190, 0000000000000000, 0000000000000000, 000= 0000000000000,

0000000000000000)

[00014D70].hkey_legacy_gate+00004C ()

[00003888]mfspurr_sc_flih01+0000E4 ()

[kdb_get_virtual_memory] no real storage @ FFFFFFFF3FFFE60

[kdb_read_mem] no real storage @ FFFFFFFFFFF6150

And here's the mst:

Machine State Save Area

iar : 000000000000E864 msr : 8000000000009032 &nbs= p;cr : 24224244

lr : F1000000C04C1AF8 ctr : 0000000000000000= xer : 00000008

mq : DEADBEEF asr : FFFFFFFFFFFFFFFF a= mr : 0008C00000000000

r0 : FFFFFFFFFFFFFFFF r1 : F00000002FF46B70 r2= : F1000000C05945A0

r3 : 00000000DEADBEEF r4 : 0000000000000068 r5= : 0000000000000000

r6 : 0000000000000000 r7 : 0000000000000000 r8= : 0000000000000000

r9 : 0000000000000000 r10 : 00000000DEADBEEF r11 : 0= 0000000DEADBF57

r12 : 0000000000000007 r13 : F1000A03E05B7000 r14 : 000000= 0000000009

r15 : 000000002FF22CAC r16 : 000000002FF22CD4 r17 : 000000= 00DEADBEEF

r18 : 00000000DEADBEEF r19 : 00000000F135E1D8 r20 : 000000= 00DEADBEEF

r21 : 00000000DEADBEEF r22 : 0000000020000444 r23 : 000000= 00DEADBEEF

r24 : 00000000DEADBEEF r25 : 0000000020020CD8 r26 : 000000= 0020022F08

r27 : 000000002FF1F5A0 r28 : 0000000000000000 r29 : 000000= 0020022F08

r30 : F1000000C05874D8 r31 : F1000000C0597EC8

prev 0000000000000000 stackfix 0000000000000= 000 int_ticks 0000

cfar 00000000001FCC6C

kjmpbuf 0000000000000000 excbranch 0000000000000000 no_pfault 0= 0

intpri 0B = ; backt 00 f= lags 00

hw_fru_id 00000000 hw_cpu_id 00000000

fpscr 0000000000000000 fpscrx 00000000 &nbs= p; fpowner 01

fpeu 01 = fpinfo 00 &nb= sp; alloc F000

o_iar 000000000000E864 o_toc F1000000C0594= 5A0

o_arg1 00000000DEADBEEF o_vaddr 00000000DEADBEEF

krlockp 0000000000000000 rmgrwa F1000816B0035E20

amrstackhigh F00000002FFCCFF0 amrstacklow F00000002FFCC00= 0

amrstackcur F00000002FFCCFE0 amrstackfix 000000000000000= 0

kstackhigh 0000000000000000 kstacksize 00000= 000

frrstart 700DFEED00000000 frrend 700DFEED00000000

frrcur 700DFEED00000000 frrstatic 0000 kjmpfrroff 0000

frrovcnt 0000 frrbarrcnt 0000 frrmask 00 callrmgr 00

Except :

excp_type 00000086 EXCEPT_PROT

orgea 00000000DEADBEEF dsisr 000000000A000000 bit set: DSI= SR_PROT DSISR_ST

vmh 0000000009000D90 curea 00000000DEADBEEF pftyp 0000000= 000000106

I haven't done a ton of kernel debugging, but DSISR_PROT DSISR_ST seems to = mean that there was a protection exception.

Does anything jump out to anyone? I will try re-compiling with --enab= le-debug and --enable-debug-kernel and see if that provides any more info.<= /div>

So would this be more of a problem with the kernel module, or with afsd?

Thanks!

-Ben

--_000_MWHPR0701MB367403D583B4D648B36695EDA76B9MWHPR0701MB3674_-- From jaltman@auristor.com Tue Aug 16 13:34:09 2022 From: jaltman@auristor.com (Jeffrey E Altman) Date: Tue, 16 Aug 2022 08:34:09 -0400 Subject: [OpenAFS-devel] Latest build kernel panic on AIX 6.1 6100-09-12 In-Reply-To: References: Message-ID: <681890d0-1dfb-3d65-18c7-d91006db2659@auristor.com> This is a cryptographically signed message in MIME format. --------------ms030508040609020605000505 Content-Type: multipart/alternative; boundary="------------NghvM6GxASRR0l120BJFVKAZ" --------------NghvM6GxASRR0l120BJFVKAZ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 8/16/2022 2:50 AM, Ben Huntsman (ben@huntsmans.net) wrote: > CRASH INFORMATION: > CPU 0 CSA F00000002FF47600 at time of crash, error code for LEDs: 30000000 > pvthread+01DB00 STACK: > [0000E864]___memset64+00005C () > [F1000000C04C1AF4]rxevent_alloc+000094 () > Try fixing the misplaced #endif. diff --git a/src/rx/rx_event.c b/src/rx/rx_event.c --- a/src/rx/rx_event.c +++ b/src/rx/rx_event.c @@ -126,8 +126,8 @@ rxevent_alloc(void) mrec->next = freeEvents.mallocs; freeEvents.mallocs = mrec; MUTEX_EXIT(&freeEvents.lock); -#endif ev = &evlist[0]; +#endif } else { ev = opr_queue_Shift(&freeEvents.list, struct rxevent, q); MUTEX_EXIT(&freeEvents.lock); --------------NghvM6GxASRR0l120BJFVKAZ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 8/16/2022 2:50 AM, Ben Huntsman (ben@huntsmans.net) wrote:

CRASH INFORMATION:
CPU 0 CSA F00000002FF47600 at time of crash, error code for LEDs: 30000000

pvthread+01DB00 STACK:

[0000E864]___memset64+00005C ()

[F1000000C04C1AF4]rxevent_alloc+000094 ()

Try fixing the misplaced #endif.

diff --git a/src/rx/rx_event.c b/src/rx/rx_event.c
--- a/src/rx/rx_event.c
+++ b/src/rx/rx_event.c
@@ -126,8 +126,8 @@ rxevent_alloc(void)
        mrec->next = freeEvents.mallocs;
        freeEvents.mallocs = mrec;
        MUTEX_EXIT(&freeEvents.lock);
-#endif
        ev = &evlist[0];
+#endif
     } else {
        ev = opr_queue_Shift(&freeEvents.list, struct rxevent, q);
        MUTEX_EXIT(&freeEvents.lock);

--------------NghvM6GxASRR0l120BJFVKAZ-- --------------ms030508040609020605000505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DHEwggXSMIIEuqADAgECAhBAAYJpmi/rPn/F0fJyDlzMMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEz MB4XDTIyMDgwNDE2MDQ0OFoXDTI1MTAzMTE2MDM0OFowcDEvMC0GCgmSJomT8ixkAQETH0Ew MTQxMEQwMDAwMDE4MjY5OUEyRkQyMDAwMjMzQ0QxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRt YW4xFTATBgNVBAoTDEF1cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCkC7PKBBZnQqDKPtZPMLAy77zo2DPvwtGnd1hNjPvbXrpGxUb3 xHZRtv179LHKAOcsY2jIctzieMxf82OMyhpBziMPsFAG/ukihBMFj3/xEeZVso3K27pSAyyN fO/wJ0rX7G+ges22Dd7goZul8rPaTJBIxbZDuaykJMGpNq4PQ8VPcnYZx+6b+nJwJJoJ46kI EEfNh3UKvB/vM0qtxS690iAdgmQIhTl+qfXq4IxWB6b+3NeQxgR6KLU4P7v88/tvJTpxIKkg 9xj89ruzeThyRFd2DSe3vfdnq9+g4qJSHRXyTft6W3Lkp7UWTM4kMqOcc4VSRdufVKBQNXjG IcnhAgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAwgYQGCCsGAQUFBwEBBHgwdjAwBggr BgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUF BzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWEx My5wN2MwHwYDVR0jBBgwFoAULbfeG1l+KpguzeHUG+PFEBJe6RQwCQYDVR0TBAIwADCCASsG A1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIBFj5odHRwczov L3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRt bDCBugYIKwYBBQUHAgIwga0MgapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4g aXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRp ZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8v dmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTMuY3JsMB8GA1UdEQQY MBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBQB+nzqgljLocLTsiUn2yWqEc2s gjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJwV eycprp8Ox1npiTyfwc5QaVaqtoe8Dcg2JXZc0h4DmYGW2rRLHp8YL43snEV93rPJVk6B2v4c WLeQfaMrnyNeEuvHx/2CT44cdLtaEk5zyqo3GYJYlLcRVz6EcSGHv1qPXgDT0xB/25etwGYq utYF4Chkxu4KzIpq90eDMw5ajkexw+8ARQz4N5+d6NRbmMCovd7wTGi8th/BZvz8hgKUiUJo Qle4wDxrdXdnIhCP7g87InXKefWgZBF4VX21t2+hkc04qrhIJlHrocPG9mRSnnk2WpsY0MXt a8ivbVKtfpY7uSNDZSKTDi1izEFH5oeQdYRkgIGb319a7FjslV8wggaXMIIEf6ADAgECAhBA AXA7OrqBjMk8rp4OuNQSMA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK EwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAe Fw0yMDAyMTIyMTA3NDlaFw0zMDAyMTIyMTA3NDlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK EwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAu6sUO01SDD99PM+QdZkNxKxJNt0NgQE+Zt6ixaNP0JKSjTd+SG5L wqxBWjnOgI/3dlwgtSNeN77AgSs+rA4bK4GJ75cUZZANUXRKw/et8pf9Qn6iqgB63OdHxBN/ 15KbM3HR+PyiHXQoUVIevCKW8nnlWnnZabT1FejOhRRKVUg5HACGOTfnCOONrlxlg+m1Vjgn o1uNqNuLM/jkD1z6phNZ/G9IfZGI0ppHX5AA/bViWceX248VmefNhSR14ADZJtlAAWOi2un0 3bqrBPHA9nDyXxI8rgWLfUP5rDy8jx2hEItg95+ORF5wfkGUq787HBjspE86CcaduLka/Bk2 VwIDAQABo4IChzCCAoMwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwgYkG CCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVu dHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t L3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C 5yZUyI42djCCASQGA1UdIASCARswggEXMIIBEwYEVR0gADCCAQkwSgYIKwYBBQUHAgEWPmh0 dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRl eC5odG1sMIG6BggrBgEFBQcCAjCBrQyBqlRoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMg YmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIElkZW5UcnVzdCdzIFRydXN0SUQgQ2Vy dGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20v Y2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEoGA1UdHwRDMEEwP6A9oDuGOWh0 dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL2NvbW1lcmNpYWxyb290Y2ExLmNy bDAdBgNVHQ4EFgQULbfeG1l+KpguzeHUG+PFEBJe6RQwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4ICAQB/7BKcygLX6Nl4a03cDHt7TLdPxCzFvDF2 bkVYCFTRX47UfeomF1gBPFDee3H/IPlLRmuTPoNt0qjdpfQzmDWN95jUXLdLPRToNxyaoB5s 0hOhcV6H08u3FHACBif55i0DTDzVSaBv0AZ9h1XeuGx4Fih1Vm3Xxz24GBqqVudvPRLyMJ7u 6hvBqTIKJ53uCs3dyQLZT9DXnp+kJv8y7ZSAY+QVrI/dysT8avtn8d7k7azNBkfnbRq+0e88 QoBnel6u+fpwbd5NLRHywXeH+phbzULCa+bLPRMqJaW2lbhvSWrMHRDy3/d8HvgnLCBFK2s4 Spns4YCN4xVcbqlGWzgolHCKUH39vpcsDo1ymZFrJ8QR6ihIn8FmJ5oKwAnnd/G6ADXFC9bu db9+532phSAXOZrrecIQn+vtP366PC+aClAPsIIDJDsotS5z4X2JUFsNIuEgXGqhiKE7SuZb rFG9sdcLprSlJN7TsRDc0W2b9nqwD+rj/5MN0C+eKwha+8ydv0+qzTyxPP90KRgaegGowC4d UsZyTk2n4Z3MuAHX5nAZL/Vh/SyDj/ajorV44yqZBzQ3ChKhXbfUSwe2xMmygA2Z5DRwMRJn p/BscizYdNk2WXJMTnH+wVLN8sLEwEtQR4eTLoFmQvrK2AMBS9kW5sBkMzINt/ZbbcZ3F+eA MDGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUG A1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwDQYJYIZIAWUDBAIBBQCg ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgxNjEy MzQwOVowLwYJKoZIhvcNAQkEMSIEIFkhMGGw1LmfsCnWwxkbQMv8tDtLv6cyvBBiQH0ZH+Bv MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAkOOC CnVet3V8Emaam2RL27Rab/xU9xNzqOgc6sjESX0juMPE0yiTimEEF5A40f9DPQYSBIk0ASPt 3fFcAZbMs0fj4LVd2E2wW/IyQ32DnC/qdupAX3M8E6Iro64U0QEjP3FLUoOuaz8SQvv6+St9 2M0T7zefeGF4q9jqkH7qmWg9Tun7dFEscUfD7TREYJ0MWsdAdRViT9tkB5ehOucz9lY8twk+ oPX+YMHCWvXjGiHifOxN/BzRxN+ve6OQS+POd/8m++hYXSRE53YacpWa2s6VJXXMo+w1EPIA ybSJFpNLVA//pwiIRUlO/TJmMYnpmJmcs9krPBlu46k6qCXG9AAAAAAAAA== --------------ms030508040609020605000505-- From kaduk@mit.edu Tue Aug 16 15:56:19 2022 From: kaduk@mit.edu (Benjamin Kaduk) Date: Tue, 16 Aug 2022 07:56:19 -0700 Subject: [OpenAFS-devel] Latest build kernel panic on AIX 6.1 6100-09-12 In-Reply-To: <681890d0-1dfb-3d65-18c7-d91006db2659@auristor.com> References: <681890d0-1dfb-3d65-18c7-d91006db2659@auristor.com> Message-ID: <20220816145619.GS24514@kduck.mit.edu> On Tue, Aug 16, 2022 at 08:34:09AM -0400, Jeffrey E Altman wrote: > On 8/16/2022 2:50 AM, Ben Huntsman (ben@huntsmans.net) wrote: > > CRASH INFORMATION: > > CPU 0 CSA F00000002FF47600 at time of crash, error code for LEDs: 30000000 > > pvthread+01DB00 STACK: > > [0000E864]___memset64+00005C () > > [F1000000C04C1AF4]rxevent_alloc+000094 () > > > Try fixing the misplaced #endif.� > > > diff --git a/src/rx/rx_event.c b/src/rx/rx_event.c > --- a/src/rx/rx_event.c > +++ b/src/rx/rx_event.c > @@ -126,8 +126,8 @@ rxevent_alloc(void) > �� mrec->next = freeEvents.mallocs; > �� freeEvents.mallocs = mrec; > �� MUTEX_EXIT(&freeEvents.lock); > -#endif > �� ev = &evlist[0]; > +#endif > �� } else { > �� ev = opr_queue_Shift(&freeEvents.list, struct rxevent, q); > �� MUTEX_EXIT(&freeEvents.lock); Well that's a pretty obvious fix, yes. Tracking at https://gerrit.openafs.org/15106 for now. -Ben From ben@huntsmans.net Tue Aug 16 16:19:39 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Tue, 16 Aug 2022 15:19:39 +0000 Subject: [OpenAFS-devel] Latest build kernel panic on AIX 6.1 6100-09-12 In-Reply-To: <20220816145619.GS24514@kduck.mit.edu> References: <681890d0-1dfb-3d65-18c7-d91006db2659@auristor.com> <20220816145619.GS24514@kduck.mit.edu> Message-ID: --_000_MWHPR0701MB36745A4BE3E25403A2BFD64CA76B9MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hey there! Thank you, I will give that a try. Dumb question though, how do I cherry-pick that commit into my topic bra= nch? Thanks! -Ben ________________________________ From: Benjamin Kaduk Sent: Tuesday, August 16, 2022 7:56 AM To: Jeffrey E Altman Cc: Ben Huntsman ; openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] Latest build kernel panic on AIX 6.1 6100-09-1= 2 On Tue, Aug 16, 2022 at 08:34:09AM -0400, Jeffrey E Altman wrote: > On 8/16/2022 2:50 AM, Ben Huntsman (ben@huntsmans.net) wrote: > > CRASH INFORMATION: > > CPU 0 CSA F00000002FF47600 at time of crash, error code for LEDs: 30000= 000 > > pvthread+01DB00 STACK: > > [0000E864]___memset64+00005C () > > [F1000000C04C1AF4]rxevent_alloc+000094 () > > > Try fixing the misplaced #endif. > > > diff --git a/src/rx/rx_event.c b/src/rx/rx_event.c > --- a/src/rx/rx_event.c > +++ b/src/rx/rx_event.c > @@ -126,8 +126,8 @@ rxevent_alloc(void) > mrec->next =3D freeEvents.mallocs; > freeEvents.mallocs =3D mrec; > MUTEX_EXIT(&freeEvents.lock); > -#endif > ev =3D &evlist[0]; > +#endif > } else { > ev =3D opr_queue_Shift(&freeEvents.list, struct rxevent, q); > MUTEX_EXIT(&freeEvents.lock); Well that's a pretty obvious fix, yes. Tracking at https://gerrit.openafs.org/15106 for now. -Ben --_000_MWHPR0701MB36745A4BE3E25403A2BFD64CA76B9MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hey there!

Thank you, I will give that a try.

Dumb question though, how do I cherry-pick that commit into my= topic branch?

Thanks!

-Ben

From: Benjamin Kaduk <ka= duk@mit.edu>
Sent: Tuesday, August 16, 2022 7:56 AM
To: Jeffrey E Altman <jaltman@auristor.com>
Cc: Ben Huntsman <ben@huntsmans.net>; openafs-devel@openafs.or= g <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] Latest build kernel panic on AIX 6.1 61= 00-09-12

On Tue, Aug 16, 2022 at 08:34:09AM -0400, Jeffrey = E Altman wrote:
> On 8/16/2022 2:50 AM, Ben Huntsman (ben@huntsmans.net) wrote:
> > CRASH INFORMATION:
> > CPU 0 CSA F00000002FF47600 at time of crash, error code for LEDs:= 30000000
> > pvthread+01DB00 STACK:
> > [0000E864]___memset64+00005C ()
> > [F1000000C04C1AF4]rxevent_alloc+000094 ()
> >
> Try fixing the misplaced #endif.
>
>
> diff --git a/src/rx/rx_event.c b/src/rx/rx_event.c
> --- a/src/rx/rx_event.c
> +++ b/src/rx/rx_event.c
> @@ -126,8 +126,8 @@ rxevent_alloc(void)
>         mrec->next =3D freeEvent= s.mallocs;
>         freeEvents.mallocs =3D mrec= ;
>         MUTEX_EXIT(&freeEvents.= lock);
> -#endif
>         ev =3D &evlist[0];
> +#endif
>      } else {
>         ev =3D opr_queue_Shift(&= ;freeEvents.list, struct rxevent, q);
>         MUTEX_EXIT(&freeEvents.= lock);

Well that's a pretty obvious fix, yes.

Tracking at https://gerrit.openafs.org/15106 for now.

-Ben

--_000_MWHPR0701MB36745A4BE3E25403A2BFD64CA76B9MWHPR0701MB3674_-- From kaduk@mit.edu Tue Aug 16 16:46:36 2022 From: kaduk@mit.edu (Benjamin Kaduk) Date: Tue, 16 Aug 2022 08:46:36 -0700 Subject: [OpenAFS-devel] Latest build kernel panic on AIX 6.1 6100-09-12 In-Reply-To: References: <681890d0-1dfb-3d65-18c7-d91006db2659@auristor.com> <20220816145619.GS24514@kduck.mit.edu> Message-ID: <20220816154636.GT24514@kduck.mit.edu> On Tue, Aug 16, 2022 at 03:19:39PM +0000, Ben Huntsman wrote: > Hey there! > Thank you, I will give that a try. > > Dumb question though, how do I cherry-pick that commit into my topic branch? Well ... in this case, since it was a simple+obvious fix I already merged it into master, so you can just re-fetch the tip of master. But in the general case, you'd need to be managing patches locally, presumably with cherry-pick. (The project in general uses a cherry-pick-based workflow; the only times I remember using merge commits are in the aftermath of security releases, e.g., if I need to make a release that's "previous release plus security fix" but the existing release branch is not suitable, and then I merge the security-fix branch back in.) Gerrit exposes each revision of each changeset as a distinct ref that's fetchable -- in the upper right of the page there's a "Download" dropdown that gives the command to fetch and checkout/cherry-pick/etc. the specific change in question. I'll also note that often a given change in gerrit is part of a stack of changes, so you may need to grab predecessor commits as well as the named one (but this one was standalone). -Ben From ben@huntsmans.net Tue Aug 16 16:48:09 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Tue, 16 Aug 2022 15:48:09 +0000 Subject: [OpenAFS-devel] Gerrit login? Message-ID: --_000_MWHPR0701MB36744389CB16A767F8B64AE4A76B9MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi guys- One more dumb question... how exactly does one log into Gerrit? I'd prefer to use my AzureAD/Office365 info if that is an option, but Go= ogle is a possibility as well. I tried entering both usernames in the regi= stration screen, but neither works. Thank you! -Ben --_000_MWHPR0701MB36744389CB16A767F8B64AE4A76B9MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi guys-

One more dumb question... how exactly does one log into Gerrit= ?

I'd prefer to use my AzureAD/Office365 info if that is an opti= on, but Google is a possibility as well. I tried entering both userna= mes in the registration screen, but neither works.

Thank you!

-Ben

--_000_MWHPR0701MB36744389CB16A767F8B64AE4A76B9MWHPR0701MB3674_-- From kaduk@mit.edu Tue Aug 16 16:53:28 2022 From: kaduk@mit.edu (Benjamin Kaduk) Date: Tue, 16 Aug 2022 08:53:28 -0700 Subject: [OpenAFS-devel] Gerrit login? In-Reply-To: References: Message-ID: <20220816155328.GU24514@kduck.mit.edu> Hi Ben, On Tue, Aug 16, 2022 at 03:48:09PM +0000, Ben Huntsman wrote: > Hi guys- > One more dumb question... how exactly does one log into Gerrit? > I'd prefer to use my AzureAD/Office365 info if that is an option, but Google is a possibility as well. I tried entering both usernames in the registration screen, but neither works. At the moment we're on an older version of the gerrit software due to the java version on the donated VM hosting it. So the ecosystem of supported OpenID providers has evolved a fair amount since the UI was frozen for our version. I think most people are currently using a Launchpad account to login, though I believe that other providers can work. When I do manage to get the version of gerrit updated, there are some changes in the authentication stack and authentication methods that I think would open up more options in this space, but I haven't looked closely enough to be sure, yet. -Ben From shadow@gmail.com Tue Aug 16 16:56:54 2022 From: shadow@gmail.com (Daria Phoebe Brashear) Date: Tue, 16 Aug 2022 11:56:54 -0400 Subject: [OpenAFS-devel] Gerrit login? In-Reply-To: <20220816155328.GU24514@kduck.mit.edu> References: <20220816155328.GU24514@kduck.mit.edu> Message-ID: On Tue, Aug 16, 2022 at 11:54 AM Benjamin Kaduk (kaduk@mit.edu) wrote: > > Hi Ben, > > On Tue, Aug 16, 2022 at 03:48:09PM +0000, Ben Huntsman wrote: > > Hi guys- > > One more dumb question... how exactly does one log into Gerrit? > > I'd prefer to use my AzureAD/Office365 info if that is an option, but Google is a possibility as well. I tried entering both usernames in the registration screen, but neither works. > > At the moment we're on an older version of the gerrit software due to the > java version on the donated VM hosting it. So the ecosystem of supported > OpenID providers has evolved a fair amount since the UI was frozen for our > version. > > I think most people are currently using a Launchpad account to login, > though I believe that other providers can work. > > When I do manage to get the version of gerrit updated, there are some > changes in the authentication stack and authentication methods that I think > would open up more options in this space, but I haven't looked closely > enough to be sure, yet. While other options will exist, Launchpad offers the best integration in modern Gerrit, and I suggest signing up with that because even after an upgrade you'll still be in good shape. -- Daria Phoebe Brashear AuriStor, Inc dariaphoebe.com From ben@huntsmans.net Tue Aug 16 17:30:03 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Tue, 16 Aug 2022 16:30:03 +0000 Subject: [OpenAFS-devel] Latest build kernel panic on AIX 6.1 6100-09-12 In-Reply-To: <20220816154636.GT24514@kduck.mit.edu> References: <681890d0-1dfb-3d65-18c7-d91006db2659@auristor.com> <20220816145619.GS24514@kduck.mit.edu> <20220816154636.GT24514@kduck.mit.edu> Message-ID: --_000_MWHPR0701MB367432E912977C828DB0CC18A76B9MWHPR0701MB3674_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Awesome! Ok, I switched back to master, did a git pull, then rebased my to= pic on origin/master and recompiled. We got further, but still panic: # /opt/openafs/sbin/afsd -stat 300 -dcache 100 -daemons 2 -volumes 50 afs: Binding rx to 0.0.0.0:7001 Starting AFS cache scan...afsd: All AFS daemons started. Here's the stack trace from the kernel dump: CRASH INFORMATION: CPU 0 CSA F00000002FF47600 at time of crash, error code for LEDs: 30000000 pvthread+01B000 STACK: [F1000000C04A2DB0]afs_mount+0001F0 (F1000A03E0251110, F1000A03E0911C7C, F1000000C04A2BC0) [F1000000C0499CB0]vfs_mount+000090 (F1000A03E0251110, F1000A03E0911C7C) [00014D70].hkey_legacy_gate+00004C () [006155AC]vfs_mount+00002C (??, ??) [00701D7C]smount+0004FC (??) [00702AC8]vmount+000248 (??, ??) [00003888]mfspurr_sc_flih01+0000E4 () [kdb_get_virtual_memory] no real storage @ 2FF1F4F8 [10001918]10001918 () [kdb_read_mem] no real storage @ FFFFFFFFFFF6130 And here's the mst: Machine State Save Area iar : F1000000C04A2DB0 msr : 8000000000009032 cr : 22222024 lr : F1000000C04A2D78 ctr : 0000000000043740 xer : 20000008 mq : DEADBEEF asr : FFFFFFFFFFFFFFFF amr : 0008C00000000000 r0 : F1000000C04A2D78 r1 : F00000002FF471F0 r2 : F1000000C05955A0 r3 : 0000000000000001 r4 : 0000000000000000 r5 : 000000000000000D r6 : F1000A03E0911C7C r7 : 0000000000000000 r8 : 0000000000000000 r9 : 0000000000000007 r10 : 003B32F62EFD4E61 r11 : 0008C00000000000 r12 : 0000000000014F54 r13 : F1000A03E04A1400 r14 : 0000000000000009 r15 : 000000002FF22CAC r16 : 000000002FF22CD4 r17 : 00000000DEADBEEF r18 : 00000000DEADBEEF r19 : 00000000000034E0 r20 : FFFFFFFFFFFFFFFF r21 : FFFFFFFFFFFFFFFF r22 : F1000A03E0251110 r23 : F3FCC00000000000 r24 : 00000000009EA3A8 r25 : 0000000000000000 r26 : 0000000000000001 r27 : FFFFFFFFFFFFFFFF r28 : 0000000000000000 r29 : 0000000000000000 r30 : 0000000000000000 r31 : F1000000C0560B10 prev 0000000000000000 stackfix 0000000000000000 int_ticks 0000 cfar F1000000C04A2B7C kjmpbuf 0000000000000000 excbranch 0000000000000000 no_pfault 00 intpri 0B backt 00 flags 00 hw_fru_id 00000000 hw_cpu_id 00000000 fpscr 0000000000000000 fpscrx 00000000 fpowner 00 fpeu 01 fpinfo 00 alloc F000 o_iar F1000000C04A2DB0 o_toc F1000000C05955A0 o_arg1 0000000000000001 o_vaddr 0000000000000004 krlockp 0000000000000000 rmgrwa F1000816B0035E20 amrstackhigh F00000002FFCCFF0 amrstacklow F00000002FFCC000 amrstackcur F00000002FFCCFE0 amrstackfix 0000000000000000 kstackhigh 0000000000000000 kstacksize 00000000 frrstart 700DFEED00000000 frrend 700DFEED00000000 frrcur 700DFEED00000000 frrstatic 0000 kjmpfrroff 0000 frrovcnt 0000 frrbarrcnt 0000 frrmask 00 callrmgr 00 Except : excp_type 00000086 EXCEPT_PROT orgea 0000000000000004 dsisr 000000000A000000 bit set: DSISR_PROT DSISR_S= T vmh 0000000010002510 curea 0000000000000004 pftyp 4000000000000106 Looks like we're getting close now! Thanks! -Ben ________________________________ From: Benjamin Kaduk Sent: Tuesday, August 16, 2022 8:46 AM To: Ben Huntsman Cc: Jeffrey E Altman ; openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] Latest build kernel panic on AIX 6.1 6100-09-1= 2 On Tue, Aug 16, 2022 at 03:19:39PM +0000, Ben Huntsman wrote: > Hey there! > Thank you, I will give that a try. > > Dumb question though, how do I cherry-pick that commit into my topic b= ranch? Well ... in this case, since it was a simple+obvious fix I already merged it into master, so you can just re-fetch the tip of master. But in the general case, you'd need to be managing patches locally, presumably with cherry-pick. (The project in general uses a cherry-pick-based workflow; the only times I remember using merge commits are in the aftermath of security releases, e.g., if I need to make a release that's "previous release plus security fix" but the existing release branch is not suitable, and then I merge the security-fix branch back in.) Gerrit exposes each revision of each changeset as a distinct ref that's fetchable -- in the upper right of the page there's a "Download" dropdown that gives the command to fetch and checkout/cherry-pick/etc. the specific change in question. I'll also note that often a given change in gerrit is part of a stack of changes, so you may need to grab predecessor commits as well as the named one (but this one was standalone). -Ben --_000_MWHPR0701MB367432E912977C828DB0CC18A76B9MWHPR0701MB3674_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Awesome! Ok, I switched back to master, did a git pull, then rebased = my topic on origin/master and recompiled. We got further, but still p= anic:

# /opt/openafs/sbin/afsd -stat 300 -dcache 100 -daemons 2 -volumes 50

afs: Binding rx to 0.0.0.0:7001

Starting AFS cache scan...afsd: All AFS daemons started.

Here's the stack trace from the kernel dump:

CRASH INFORMATION:

CPU 0 CSA F00000002FF47600 at time of crash, error code for LEDs: 3000= 0000

pvthread+01B000 STACK:

[F1000000C04A2DB0]afs_mount+0001F0 (F1000A03E0251110, F1000A03E0911C7C= ,

F1000000C04A2BC0)

[F1000000C0499CB0]vfs_mount+000090 (F1000A03E0251110, F1000A03E0911C7C= )

[00014D70].hkey_legacy_gate+00004C ()

[006155AC]vfs_mount+00002C (??, ??)

[00701D7C]smount+0004FC (??)

[00702AC8]vmount+000248 (??, ??)

[00003888]mfspurr_sc_flih01+0000E4 ()

[kdb_get_virtual_memory] no real storage @ 2FF1F4F8

[10001918]10001918 ()

[kdb_read_mem] no real storage @ FFFFFFFFFFF6130

And here's the mst:

Machine State Save Area

iar : F1000000C04A2DB0 msr : 8000000000009032 &nbs= p;cr : 22222024

lr : F1000000C04A2D78 ctr : 0000000000043740= xer : 20000008

mq : DEADBEEF asr : FFFFFFFFFFFFFFFF a= mr : 0008C00000000000

r0 : F1000000C04A2D78 r1 : F00000002FF471F0 r2= : F1000000C05955A0

r3 : 0000000000000001 r4 : 0000000000000000 r5= : 000000000000000D

r6 : F1000A03E0911C7C r7 : 0000000000000000 r8= : 0000000000000000

r9 : 0000000000000007 r10 : 003B32F62EFD4E61 r11 : 0= 008C00000000000

r12 : 0000000000014F54 r13 : F1000A03E04A1400 r14 : 000000= 0000000009

r15 : 000000002FF22CAC r16 : 000000002FF22CD4 r17 : 000000= 00DEADBEEF

r18 : 00000000DEADBEEF r19 : 00000000000034E0 r20 : FFFFFF= FFFFFFFFFF

r21 : FFFFFFFFFFFFFFFF r22 : F1000A03E0251110 r23 : F3FCC0= 0000000000

r24 : 00000000009EA3A8 r25 : 0000000000000000 r26 : 000000= 0000000001

r27 : FFFFFFFFFFFFFFFF r28 : 0000000000000000 r29 : 000000= 0000000000

r30 : 0000000000000000 r31 : F1000000C0560B10

prev 0000000000000000 stackfix 0000000000000= 000 int_ticks 0000

cfar F1000000C04A2B7C

kjmpbuf 0000000000000000 excbranch 0000000000000000 no_pfault 0= 0

intpri 0B = ; backt 00 f= lags 00

hw_fru_id 00000000 hw_cpu_id 00000000

fpscr 0000000000000000 fpscrx 00000000 &nbs= p; fpowner 00

fpeu 01 = fpinfo 00 &nb= sp; alloc F000

o_iar F1000000C04A2DB0 o_toc F1000000C0595= 5A0

o_arg1 0000000000000001 o_vaddr 0000000000000004

krlockp 0000000000000000 rmgrwa F1000816B0035E20

amrstackhigh F00000002FFCCFF0 amrstacklow F00000002FFCC00= 0

amrstackcur F00000002FFCCFE0 amrstackfix 000000000000000= 0

kstackhigh 0000000000000000 kstacksize 00000= 000

frrstart 700DFEED00000000 frrend 700DFEED00000000

frrcur 700DFEED00000000 frrstatic 0000 kjmpfrroff 0000

frrovcnt 0000 frrbarrcnt 0000 frrmask 00 callrmgr 00

Except :

excp_type 00000086 EXCEPT_PROT

orgea 0000000000000004 dsisr 000000000A000000 bit set: DSI= SR_PROT DSISR_ST

vmh 0000000010002510 curea 0000000000000004 pftyp 4000000= 000000106

Looks like we're getting close now!

Thanks!

-Ben

From: Benjamin Kaduk <ka= duk@mit.edu>
Sent: Tuesday, August 16, 2022 8:46 AM
To: Ben Huntsman <ben@huntsmans.net>
Cc: Jeffrey E Altman <jaltman@auristor.com>; openafs-devel@ope= nafs.org <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] Latest build kernel panic on AIX 6.1 61= 00-09-12

On Tue, Aug 16, 2022 at 03:19:39PM +0000, Ben Hunt= sman wrote:
> Hey there!
> Thank you, I will give that a try.
>
> Dumb question though, how do I cherry-pick that comm= it into my topic branch?

Well ... in this case, since it was a simple+obvious fix I already merged it into master, so you can just re-fetch the tip of master.

But in the general case, you'd need to be managing patches locally,
presumably with cherry-pick. (The project in general uses a
cherry-pick-based workflow; the only times I remember using merge commits are in the aftermath of security releases, e.g., if I need to make a
release that's "previous release plus security fix" but the exist= ing
release branch is not suitable, and then I merge the security-fix branch back in.) Gerrit exposes each revision of each changeset as a distinc= t ref
that's fetchable -- in the upper right of the page there's a "Download= "
dropdown that gives the command to fetch and checkout/cherry-pick/etc. the<= br> specific change in question. I'll also note that often a given change= in
gerrit is part of a stack of changes, so you may need to grab predecessor commits as well as the named one (but this one was standalone).

-Ben

--_000_MWHPR0701MB367432E912977C828DB0CC18A76B9MWHPR0701MB3674_-- From ben@huntsmans.net Tue Aug 16 20:52:58 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Tue, 16 Aug 2022 19:52:58 +0000 Subject: [OpenAFS-devel] Gerrit login? In-Reply-To: References: <20220816155328.GU24514@kduck.mit.edu> Message-ID: --_000_MWHPR0701MB3674E2802ED282FF510E3609A76B9MWHPR0701MB3674_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Daria- That works. I did that and got set up and was able to push my changes t= o get OpenAFS building on AIX to gerrit. Hopefully some of this will be accepted! Thank you! -Ben ________________________________ From: Daria Phoebe Brashear Sent: Tuesday, August 16, 2022 8:56 AM To: Benjamin Kaduk (kaduk@mit.edu) Cc: Ben Huntsman ; openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] Gerrit login? On Tue, Aug 16, 2022 at 11:54 AM Benjamin Kaduk (kaduk@mit.edu) wrote: > > Hi Ben, > > On Tue, Aug 16, 2022 at 03:48:09PM +0000, Ben Huntsman wrote: > > Hi guys- > > One more dumb question... how exactly does one log into Gerrit? > > I'd prefer to use my AzureAD/Office365 info if that is an option, bu= t Google is a possibility as well. I tried entering both usernames in the = registration screen, but neither works. > > At the moment we're on an older version of the gerrit software due to the > java version on the donated VM hosting it. So the ecosystem of supported > OpenID providers has evolved a fair amount since the UI was frozen for ou= r > version. > > I think most people are currently using a Launchpad account to login, > though I believe that other providers can work. > > When I do manage to get the version of gerrit updated, there are some > changes in the authentication stack and authentication methods that I thi= nk > would open up more options in this space, but I haven't looked closely > enough to be sure, yet. While other options will exist, Launchpad offers the best integration in modern Gerrit, and I suggest signing up with that because even after an upgrade you'll still be in good shape. -- Daria Phoebe Brashear AuriStor, Inc dariaphoebe.com --_000_MWHPR0701MB3674E2802ED282FF510E3609A76B9MWHPR0701MB3674_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Daria-

That works. I did that and got set up and was able to pu= sh my changes to get OpenAFS building on AIX to gerrit.

Hopefully some of this will be accepted!

Thank you!

-Ben

From: Daria Phoebe Brashear= <shadow@gmail.com>
Sent: Tuesday, August 16, 2022 8:56 AM
To: Benjamin Kaduk (kaduk@mit.edu) <kaduk@mit.edu>
Cc: Ben Huntsman <ben@huntsmans.net>; openafs-devel@openafs.or= g <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] Gerrit login?

On Tue, Aug 16, 2022 at 11:54 AM Benjamin Kaduk (k= aduk@mit.edu)
<kaduk@mit.edu> wrote:
>
> Hi Ben,
>
> On Tue, Aug 16, 2022 at 03:48:09PM +0000, Ben Huntsman wrote:
> > Hi guys-
> > One more dumb question... how exactly does one = log into Gerrit?
> > I'd prefer to use my AzureAD/Office365 info if = that is an option, but Google is a possibility as well. I tried enter= ing both usernames in the registration screen, but neither works.
>
> At the moment we're on an older version of the gerrit software due to = the
> java version on the donated VM hosting it. So the ecosystem of s= upported
> OpenID providers has evolved a fair amount since the UI was frozen for= our
> version.
>
> I think most people are currently using a Launchpad account to login,<= br> > though I believe that other providers can work.
>
> When I do manage to get the version of gerrit updated, there are some<= br> > changes in the authentication stack and authentication methods that I = think
> would open up more options in this space, but I haven't looked closely=
> enough to be sure, yet.

While other options will exist, Launchpad offers the best integration
in modern Gerrit, and I suggest signing up with that
because even after an upgrade you'll still be in good shape.

--
Daria Phoebe Brashear
AuriStor, Inc
dariaphoebe.com

--_000_MWHPR0701MB3674E2802ED282FF510E3609A76B9MWHPR0701MB3674_-- From jaltman@auristor.com Tue Aug 16 21:33:29 2022 From: jaltman@auristor.com (Jeffrey E Altman) Date: Tue, 16 Aug 2022 16:33:29 -0400 Subject: [OpenAFS-devel] Latest build kernel panic on AIX 6.1 6100-09-12 In-Reply-To: References: <681890d0-1dfb-3d65-18c7-d91006db2659@auristor.com> <20220816145619.GS24514@kduck.mit.edu> <20220816154636.GT24514@kduck.mit.edu> Message-ID: This is a cryptographically signed message in MIME format. --------------ms040506010600030303030802 Content-Type: multipart/alternative; boundary="------------m8pDyAU9IRJq9QArgjPJ1rel" --------------m8pDyAU9IRJq9QArgjPJ1rel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 8/16/2022 12:30 PM, Ben Huntsman (ben@huntsmans.net) wrote: > Awesome! Ok, I switched back to master, did a git pull, then rebased > my topic on origin/master and recompiled. We got further, but still > panic: > > # /opt/openafs/sbin/afsd -stat 300 -dcache 100 -daemons 2 -volumes 50 > afs: Binding rx to 0.0.0.0:7001 > Starting AFS cache scan...afsd: All AFS daemons started. > > > Here's the stack trace from the kernel dump: > > CRASH INFORMATION: > CPU 0 CSA F00000002FF47600 at time of crash, error code for LEDs: 30000000 > pvthread+01B000 STACK: > [F1000000C04A2DB0]afs_mount+0001F0 (F1000A03E0251110, F1000A03E0911C7C, > F1000000C04A2BC0) > [F1000000C0499CB0]vfs_mount+000090 (F1000A03E0251110, F1000A03E0911C7C) > At this point you are in AIX specific code. More than likely the requirements of the 'afs_mount' function defined in src/afs/AIX/osi_vfsops.c have changed since AIX 6.1 TL5. This unlikely to be the only place where there is interface breakage. Jeffrey Altman --------------m8pDyAU9IRJq9QArgjPJ1rel Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 8/16/2022 12:30 PM, Ben Huntsman (ben@huntsmans.net) wrote:

Awesome! Ok, I switched back to master, did a git pull, then rebased my topic on origin/master and recompiled. We got further, but still panic:

# /opt/openafs/sbin/afsd -stat 300 -dcache 100 -daemons 2 -volumes 50
afs: Binding rx to 0.0.0.0:7001

Starting AFS cache scan...afsd: All AFS daemons started.

Here's the stack trace from the kernel dump:

CRASH INFORMATION:
CPU 0 CSA F00000002FF47600 at time of crash, error code for LEDs: 30000000

pvthread+01B000 STACK:

[F1000000C04A2DB0]afs_mount+0001F0 (F1000A03E0251110, F1000A03E0911C7C,

F1000000C04A2BC0)

[F1000000C0499CB0]vfs_mount+000090 (F1000A03E0251110, F1000A03E0911C7C)

At this point you are in AIX specific code. More than likely the requirements of the 'afs_mount' function defined in src/afs/AIX/osi_vfsops.c have changed since AIX 6.1 TL5.

This unlikely to be the only place where there is interface breakage.

Jeffrey Altman

--------------m8pDyAU9IRJq9QArgjPJ1rel-- --------------ms040506010600030303030802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DHEwggXSMIIEuqADAgECAhBAAYJpmi/rPn/F0fJyDlzMMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEz MB4XDTIyMDgwNDE2MDQ0OFoXDTI1MTAzMTE2MDM0OFowcDEvMC0GCgmSJomT8ixkAQETH0Ew MTQxMEQwMDAwMDE4MjY5OUEyRkQyMDAwMjMzQ0QxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRt YW4xFTATBgNVBAoTDEF1cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCkC7PKBBZnQqDKPtZPMLAy77zo2DPvwtGnd1hNjPvbXrpGxUb3 xHZRtv179LHKAOcsY2jIctzieMxf82OMyhpBziMPsFAG/ukihBMFj3/xEeZVso3K27pSAyyN fO/wJ0rX7G+ges22Dd7goZul8rPaTJBIxbZDuaykJMGpNq4PQ8VPcnYZx+6b+nJwJJoJ46kI EEfNh3UKvB/vM0qtxS690iAdgmQIhTl+qfXq4IxWB6b+3NeQxgR6KLU4P7v88/tvJTpxIKkg 9xj89ruzeThyRFd2DSe3vfdnq9+g4qJSHRXyTft6W3Lkp7UWTM4kMqOcc4VSRdufVKBQNXjG IcnhAgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAwgYQGCCsGAQUFBwEBBHgwdjAwBggr BgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUF BzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWEx My5wN2MwHwYDVR0jBBgwFoAULbfeG1l+KpguzeHUG+PFEBJe6RQwCQYDVR0TBAIwADCCASsG A1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIBFj5odHRwczov L3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRt bDCBugYIKwYBBQUHAgIwga0MgapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4g aXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRp ZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8v dmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTMuY3JsMB8GA1UdEQQY MBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBQB+nzqgljLocLTsiUn2yWqEc2s gjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJwV eycprp8Ox1npiTyfwc5QaVaqtoe8Dcg2JXZc0h4DmYGW2rRLHp8YL43snEV93rPJVk6B2v4c WLeQfaMrnyNeEuvHx/2CT44cdLtaEk5zyqo3GYJYlLcRVz6EcSGHv1qPXgDT0xB/25etwGYq utYF4Chkxu4KzIpq90eDMw5ajkexw+8ARQz4N5+d6NRbmMCovd7wTGi8th/BZvz8hgKUiUJo Qle4wDxrdXdnIhCP7g87InXKefWgZBF4VX21t2+hkc04qrhIJlHrocPG9mRSnnk2WpsY0MXt a8ivbVKtfpY7uSNDZSKTDi1izEFH5oeQdYRkgIGb319a7FjslV8wggaXMIIEf6ADAgECAhBA AXA7OrqBjMk8rp4OuNQSMA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK EwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAe Fw0yMDAyMTIyMTA3NDlaFw0zMDAyMTIyMTA3NDlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK EwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAu6sUO01SDD99PM+QdZkNxKxJNt0NgQE+Zt6ixaNP0JKSjTd+SG5L wqxBWjnOgI/3dlwgtSNeN77AgSs+rA4bK4GJ75cUZZANUXRKw/et8pf9Qn6iqgB63OdHxBN/ 15KbM3HR+PyiHXQoUVIevCKW8nnlWnnZabT1FejOhRRKVUg5HACGOTfnCOONrlxlg+m1Vjgn o1uNqNuLM/jkD1z6phNZ/G9IfZGI0ppHX5AA/bViWceX248VmefNhSR14ADZJtlAAWOi2un0 3bqrBPHA9nDyXxI8rgWLfUP5rDy8jx2hEItg95+ORF5wfkGUq787HBjspE86CcaduLka/Bk2 VwIDAQABo4IChzCCAoMwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwgYkG CCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVu dHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t L3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C 5yZUyI42djCCASQGA1UdIASCARswggEXMIIBEwYEVR0gADCCAQkwSgYIKwYBBQUHAgEWPmh0 dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRl eC5odG1sMIG6BggrBgEFBQcCAjCBrQyBqlRoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMg YmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIElkZW5UcnVzdCdzIFRydXN0SUQgQ2Vy dGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20v Y2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEoGA1UdHwRDMEEwP6A9oDuGOWh0 dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL2NvbW1lcmNpYWxyb290Y2ExLmNy bDAdBgNVHQ4EFgQULbfeG1l+KpguzeHUG+PFEBJe6RQwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4ICAQB/7BKcygLX6Nl4a03cDHt7TLdPxCzFvDF2 bkVYCFTRX47UfeomF1gBPFDee3H/IPlLRmuTPoNt0qjdpfQzmDWN95jUXLdLPRToNxyaoB5s 0hOhcV6H08u3FHACBif55i0DTDzVSaBv0AZ9h1XeuGx4Fih1Vm3Xxz24GBqqVudvPRLyMJ7u 6hvBqTIKJ53uCs3dyQLZT9DXnp+kJv8y7ZSAY+QVrI/dysT8avtn8d7k7azNBkfnbRq+0e88 QoBnel6u+fpwbd5NLRHywXeH+phbzULCa+bLPRMqJaW2lbhvSWrMHRDy3/d8HvgnLCBFK2s4 Spns4YCN4xVcbqlGWzgolHCKUH39vpcsDo1ymZFrJ8QR6ihIn8FmJ5oKwAnnd/G6ADXFC9bu db9+532phSAXOZrrecIQn+vtP366PC+aClAPsIIDJDsotS5z4X2JUFsNIuEgXGqhiKE7SuZb rFG9sdcLprSlJN7TsRDc0W2b9nqwD+rj/5MN0C+eKwha+8ydv0+qzTyxPP90KRgaegGowC4d UsZyTk2n4Z3MuAHX5nAZL/Vh/SyDj/ajorV44yqZBzQ3ChKhXbfUSwe2xMmygA2Z5DRwMRJn p/BscizYdNk2WXJMTnH+wVLN8sLEwEtQR4eTLoFmQvrK2AMBS9kW5sBkMzINt/ZbbcZ3F+eA MDGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUG A1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwDQYJYIZIAWUDBAIBBQCg ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgxNjIw MzMyOVowLwYJKoZIhvcNAQkEMSIEIDr0YW3DGnRXW+g/I1Oazbhl+Xe7+to4lcx2SzKCEdct MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAlFg5 tTmRw83jCykT9rUK6pG14DtUyU5C+kpEIF+S2N9aaen86SJOvOOs8OFuNu3ToJLT9Edy7BV3 kzi3ax5QWrukxWfqxPIZFgwq6bevqJ25yDYSc4tF7rTo3wEwF1TPqpEmf4IHD6cjQZUM16R1 GnMDUTFW8l85+30wecYkiMWaDsclMuAV4qtjbQO/YiSjxf4K3mf1mehqZ6OeJYBX/trkdp20 2eHH2wqPArlk0yYAiJYJre4Lh9rLRvDHhVBm2TwFyDG6krPAIdmrUPy/o0JnGTSdPBAyaq3R UZpkmSZGFQJVB6QuFnC9YPDm/T733YT314ax+Hp5d9GeRq1RxQAAAAAAAA== --------------ms040506010600030303030802-- From ben@huntsmans.net Wed Aug 17 01:02:53 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Wed, 17 Aug 2022 00:02:53 +0000 Subject: [OpenAFS-devel] PERLUAFS? Message-ID: --_000_MWHPR0701MB367439672899B8824C397E72A76B9MWHPR0701MB3674_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi there- I pushed my changes to get OpenAFS building on AIX, but some of the chan= ges are failing the BuildBot verification: PERLUAFS/ukernel_swig_perl.c: In function =91swig_uafs_ParseArgs=92: PERLUAFS/ukernel_swig_perl.c:1585:9: warning: implicit declaration of funct= ion =91afs_com_err=92 [-Wimplicit-function-declaration] 1585 | afs_com_err("AFS::ukernel", code, "parsing line: '%s'", lin= e); | ^~~~~~~~~~~ But what is PERLUAFS and where is that even coming from? I'm not sure how = to resolve. Thank you. -Ben --_000_MWHPR0701MB367439672899B8824C397E72A76B9MWHPR0701MB3674_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi there-

I pushed my changes to get OpenAFS building on AIX, but some o= f the changes are failing the BuildBot verification:

PERLUAFS/ukernel_swig_perl.c: In function =91swig_uafs_ParseArgs=92:

PERLUAFS/ukernel_swig_perl.c:1585:9: warning: implicit declaration of = function =91afs_com_err=92 [-Wimplicit-function-declaration]

1585 | afs_com_err("AFS::ukerne= l", code, "parsing line: '%s'", line);

| ^~~~~~~~~~~

But what is PERLUAFS and where is that even coming from? I'm not sure= how to resolve.

Thank you.

-Ben

--_000_MWHPR0701MB367439672899B8824C397E72A76B9MWHPR0701MB3674_-- From kaduk@mit.edu Wed Aug 17 02:30:55 2022 From: kaduk@mit.edu (Benjamin Kaduk) Date: Tue, 16 Aug 2022 18:30:55 -0700 Subject: [OpenAFS-devel] PERLUAFS? In-Reply-To: References: Message-ID: <20220817013055.GV24514@kduck.mit.edu> On Wed, Aug 17, 2022 at 12:02:53AM +0000, Ben Huntsman wrote: > Hi there- > I pushed my changes to get OpenAFS building on AIX, but some of the changes are failing the BuildBot verification: > > PERLUAFS/ukernel_swig_perl.c: In function ‘swig_uafs_ParseArgs’: > PERLUAFS/ukernel_swig_perl.c:1585:9: warning: implicit declaration of function ‘afs_com_err’ [-Wimplicit-function-declaration] > 1585 | afs_com_err("AFS::ukernel", code, "parsing line: '%s'", line); > | ^~~~~~~~~~~ > > But what is PERLUAFS and where is that even coming from? I'm not sure how to resolve. It's a scheme to use SWIG to produce perl bindings for the userspace AFS client [library]. You almost certainly don't need it, and can pass --without-swig to configure to skip trying to do anything with it. -Ben From ben@huntsmans.net Wed Aug 17 02:59:58 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Wed, 17 Aug 2022 01:59:58 +0000 Subject: [OpenAFS-devel] PERLUAFS? In-Reply-To: <20220817013055.GV24514@kduck.mit.edu> References: <20220817013055.GV24514@kduck.mit.edu> Message-ID: --_000_MWHPR0701MB3674933507CBD6E633A8B939A76A9MWHPR0701MB3674_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I certainly don't need it. But the error is the failure message on the bui= ldbot build logs for those that have failed. What do I need to do to fix t= he build for them? Thank you! -Ben ________________________________ From: Benjamin Kaduk Sent: Tuesday, August 16, 2022 6:30 PM To: Ben Huntsman Cc: openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] PERLUAFS? On Wed, Aug 17, 2022 at 12:02:53AM +0000, Ben Huntsman wrote: > Hi there- > I pushed my changes to get OpenAFS building on AIX, but some of the ch= anges are failing the BuildBot verification: > > PERLUAFS/ukernel_swig_perl.c: In function =91swig_uafs_ParseArgs=92: > PERLUAFS/ukernel_swig_perl.c:1585:9: warning: implicit declaration of fun= ction =91afs_com_err=92 [-Wimplicit-function-declaration] > 1585 | afs_com_err("AFS::ukernel", code, "parsing line: '%s'", l= ine); > | ^~~~~~~~~~~ > > But what is PERLUAFS and where is that even coming from? I'm not sure ho= w to resolve. It's a scheme to use SWIG to produce perl bindings for the userspace AFS client [library]. You almost certainly don't need it, and can pass --without-swig to configure to skip trying to do anything with it. -Ben --_000_MWHPR0701MB3674933507CBD6E633A8B939A76A9MWHPR0701MB3674_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I certainly don't need it. But the error is the failure message on th= e buildbot build logs for those that have failed. What do I need to d= o to fix the build for them?

Thank you!

-Ben

From: Benjamin Kaduk <ka= duk@mit.edu>
Sent: Tuesday, August 16, 2022 6:30 PM
To: Ben Huntsman <ben@huntsmans.net>
Cc: openafs-devel@openafs.org <openafs-devel@openafs.org>
Subject: Re: [OpenAFS-devel] PERLUAFS?

On Wed, Aug 17, 2022 at 12:02:53AM +0000, Ben Hunt= sman wrote:
> Hi there-
> I pushed my changes to get OpenAFS building on AIX, = but some of the changes are failing the BuildBot verification:
>
> PERLUAFS/ukernel_swig_perl.c: In function =91swig_uafs_ParseArgs=92: > PERLUAFS/ukernel_swig_perl.c:1585:9: warning: implicit declaration of = function =91afs_com_err=92 [-Wimplicit-function-declaration]
> 1585 | afs_com_e= rr("AFS::ukernel", code, "parsing line: '%s'", line); > | &nb= sp; ^~~~~~~~~~~
>
> But what is PERLUAFS and where is that even coming from? I'm not= sure how to resolve.

It's a scheme to use SWIG to produce perl bindings for the userspace AFS client [library]. You almost certainly don't need it, and can pass --without-swig to configure to skip trying to do anything with it.

-Ben

--_000_MWHPR0701MB3674933507CBD6E633A8B939A76A9MWHPR0701MB3674_-- From jaltman@auristor.com Wed Aug 17 03:09:17 2022 From: jaltman@auristor.com (Jeffrey E Altman) Date: Tue, 16 Aug 2022 22:09:17 -0400 Subject: [OpenAFS-devel] PERLUAFS? In-Reply-To: References: <20220817013055.GV24514@kduck.mit.edu> Message-ID: This is a cryptographically signed message in MIME format. --------------ms060806060103080109080204 Content-Type: multipart/alternative; boundary="------------aVM2AvcyNqIYIZe9qxP4lcN3" --------------aVM2AvcyNqIYIZe9qxP4lcN3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 8/16/2022 9:59 PM, Ben Huntsman (ben@huntsmans.net) wrote: > I certainly don't need it. But the error is the failure message on > the buildbot build logs for those that have failed. What do I need to > do to fix the build for them? > > Thank you! > > -Ben The change that introduced the failure is https://gerrit.openafs.org/#/c/15109/2. Something in that change is causing afs_com_err() to be called from uafs_ParseArgs() when it wasn't previously or is preventing the inclusion of the afs_com_err() prototype. --------------aVM2AvcyNqIYIZe9qxP4lcN3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 8/16/2022 9:59 PM, Ben Huntsman (ben@huntsmans.net) wrote:

I certainly don't need it. But the error is the failure message on the buildbot build logs for those that have failed. What do I need to do to fix the build for them?

Thank you!

-Ben

The change that introduced the failure is https://gerrit.openafs.org/#/c/15109/2.

Something in that change is causing afs_com_err() to be called from uafs_ParseArgs() when it wasn't previously or is preventing the inclusion of the afs_com_err() prototype.

--------------aVM2AvcyNqIYIZe9qxP4lcN3-- --------------ms060806060103080109080204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DHEwggXSMIIEuqADAgECAhBAAYJpmi/rPn/F0fJyDlzMMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEz MB4XDTIyMDgwNDE2MDQ0OFoXDTI1MTAzMTE2MDM0OFowcDEvMC0GCgmSJomT8ixkAQETH0Ew MTQxMEQwMDAwMDE4MjY5OUEyRkQyMDAwMjMzQ0QxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRt YW4xFTATBgNVBAoTDEF1cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCkC7PKBBZnQqDKPtZPMLAy77zo2DPvwtGnd1hNjPvbXrpGxUb3 xHZRtv179LHKAOcsY2jIctzieMxf82OMyhpBziMPsFAG/ukihBMFj3/xEeZVso3K27pSAyyN fO/wJ0rX7G+ges22Dd7goZul8rPaTJBIxbZDuaykJMGpNq4PQ8VPcnYZx+6b+nJwJJoJ46kI EEfNh3UKvB/vM0qtxS690iAdgmQIhTl+qfXq4IxWB6b+3NeQxgR6KLU4P7v88/tvJTpxIKkg 9xj89ruzeThyRFd2DSe3vfdnq9+g4qJSHRXyTft6W3Lkp7UWTM4kMqOcc4VSRdufVKBQNXjG IcnhAgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAwgYQGCCsGAQUFBwEBBHgwdjAwBggr BgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUF BzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWEx My5wN2MwHwYDVR0jBBgwFoAULbfeG1l+KpguzeHUG+PFEBJe6RQwCQYDVR0TBAIwADCCASsG A1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIBFj5odHRwczov L3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRt bDCBugYIKwYBBQUHAgIwga0MgapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4g aXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRp ZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8v dmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTMuY3JsMB8GA1UdEQQY MBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBQB+nzqgljLocLTsiUn2yWqEc2s gjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJwV eycprp8Ox1npiTyfwc5QaVaqtoe8Dcg2JXZc0h4DmYGW2rRLHp8YL43snEV93rPJVk6B2v4c WLeQfaMrnyNeEuvHx/2CT44cdLtaEk5zyqo3GYJYlLcRVz6EcSGHv1qPXgDT0xB/25etwGYq utYF4Chkxu4KzIpq90eDMw5ajkexw+8ARQz4N5+d6NRbmMCovd7wTGi8th/BZvz8hgKUiUJo Qle4wDxrdXdnIhCP7g87InXKefWgZBF4VX21t2+hkc04qrhIJlHrocPG9mRSnnk2WpsY0MXt a8ivbVKtfpY7uSNDZSKTDi1izEFH5oeQdYRkgIGb319a7FjslV8wggaXMIIEf6ADAgECAhBA AXA7OrqBjMk8rp4OuNQSMA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK EwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAe Fw0yMDAyMTIyMTA3NDlaFw0zMDAyMTIyMTA3NDlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK EwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAu6sUO01SDD99PM+QdZkNxKxJNt0NgQE+Zt6ixaNP0JKSjTd+SG5L wqxBWjnOgI/3dlwgtSNeN77AgSs+rA4bK4GJ75cUZZANUXRKw/et8pf9Qn6iqgB63OdHxBN/ 15KbM3HR+PyiHXQoUVIevCKW8nnlWnnZabT1FejOhRRKVUg5HACGOTfnCOONrlxlg+m1Vjgn o1uNqNuLM/jkD1z6phNZ/G9IfZGI0ppHX5AA/bViWceX248VmefNhSR14ADZJtlAAWOi2un0 3bqrBPHA9nDyXxI8rgWLfUP5rDy8jx2hEItg95+ORF5wfkGUq787HBjspE86CcaduLka/Bk2 VwIDAQABo4IChzCCAoMwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwgYkG CCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVu dHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t L3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C 5yZUyI42djCCASQGA1UdIASCARswggEXMIIBEwYEVR0gADCCAQkwSgYIKwYBBQUHAgEWPmh0 dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRl eC5odG1sMIG6BggrBgEFBQcCAjCBrQyBqlRoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMg YmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIElkZW5UcnVzdCdzIFRydXN0SUQgQ2Vy dGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20v Y2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEoGA1UdHwRDMEEwP6A9oDuGOWh0 dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL2NvbW1lcmNpYWxyb290Y2ExLmNy bDAdBgNVHQ4EFgQULbfeG1l+KpguzeHUG+PFEBJe6RQwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4ICAQB/7BKcygLX6Nl4a03cDHt7TLdPxCzFvDF2 bkVYCFTRX47UfeomF1gBPFDee3H/IPlLRmuTPoNt0qjdpfQzmDWN95jUXLdLPRToNxyaoB5s 0hOhcV6H08u3FHACBif55i0DTDzVSaBv0AZ9h1XeuGx4Fih1Vm3Xxz24GBqqVudvPRLyMJ7u 6hvBqTIKJ53uCs3dyQLZT9DXnp+kJv8y7ZSAY+QVrI/dysT8avtn8d7k7azNBkfnbRq+0e88 QoBnel6u+fpwbd5NLRHywXeH+phbzULCa+bLPRMqJaW2lbhvSWrMHRDy3/d8HvgnLCBFK2s4 Spns4YCN4xVcbqlGWzgolHCKUH39vpcsDo1ymZFrJ8QR6ihIn8FmJ5oKwAnnd/G6ADXFC9bu db9+532phSAXOZrrecIQn+vtP366PC+aClAPsIIDJDsotS5z4X2JUFsNIuEgXGqhiKE7SuZb rFG9sdcLprSlJN7TsRDc0W2b9nqwD+rj/5MN0C+eKwha+8ydv0+qzTyxPP90KRgaegGowC4d UsZyTk2n4Z3MuAHX5nAZL/Vh/SyDj/ajorV44yqZBzQ3ChKhXbfUSwe2xMmygA2Z5DRwMRJn p/BscizYdNk2WXJMTnH+wVLN8sLEwEtQR4eTLoFmQvrK2AMBS9kW5sBkMzINt/ZbbcZ3F+eA MDGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUG A1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwDQYJYIZIAWUDBAIBBQCg ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgxNzAy MDkxN1owLwYJKoZIhvcNAQkEMSIEIPBkPZDJgY9xolSzHUUnupWJaTsVIF+vKOjUFDRYSxvk MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEABpBI Ku5HDCDy043FFPx9Ub+gA35q43VhI6Jm+qlUOvdR4EzF3jrWlVv9OIWsGNpCAuVltrnpPPl/ jDdBPjzXbcBi7hdegHGABTfmIryz8oY0nJL4j2Kp9MEgfMMpblUdu+t/sc+ZyBiKWhc1FRoh lmW3rXwCCf/gynrKDJSw7ZQK1tiZKfKtHhllC9/+uJ3g5I+pWjsKT1wKqorsG7VWbvlNzcf+ EbeGmkpPmT+hwtYdXcxVPg2ipOgCCMUs31EXUKa/qCuXop7dz6i0B4QHQ7qBdmUpcSODy4P6 DIwzwxsMggiAbHilsNELcvk195BWb9vZmJxWulAEQOTCACYLEQAAAAAAAA== --------------ms060806060103080109080204-- From kaduk@mit.edu Wed Aug 17 03:22:13 2022 From: kaduk@mit.edu (Benjamin Kaduk) Date: Tue, 16 Aug 2022 19:22:13 -0700 Subject: [OpenAFS-devel] PERLUAFS? In-Reply-To: References: <20220817013055.GV24514@kduck.mit.edu>

Message-ID: <20220817022213.GW24514@kduck.mit.edu> On Tue, Aug 16, 2022 at 10:09:17PM -0400, Jeffrey E Altman wrote: > On 8/16/2022 9:59 PM, Ben Huntsman (ben@huntsmans.net) wrote: > > I certainly don't need it.� But the error is the failure message on > > the buildbot build logs for those that have failed.� What do I need to > > do to fix the build for them? > > > > Thank you! > > > > -Ben > > The change that introduced the failure is > https://gerrit.openafs.org/#/c/15109/2. (It seems that the same buildbot errors showed in PS1 of that change as well, unsurprising given that the diff from PS1 to PS2 is just in the commit message.) > Something in that change is causing afs_com_err() to be called from > uafs_ParseArgs() when it wasn't previously or is preventing the > inclusion of the afs_com_err() prototype. > It is probably most expedient to bisect based on which files are getting patched, then chunks within the file in question. -Ben From ben@huntsmans.net Wed Aug 17 16:29:42 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Wed, 17 Aug 2022 15:29:42 +0000 Subject: [OpenAFS-devel] buildbot segfault Message-ID: --_000_MWHPR0701MB367463F6CA2804B2A24C3AAFA76A9MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable During a build test, build bot gerrit-dev-macos10-14-x86_64 had a segfault = during the build. The other three macos machines built fine. Is this like= ly a problem with the build bot, or the code change? Is there a way to mak= e just that one bot try the build again? Thanks. -Ben --_000_MWHPR0701MB367463F6CA2804B2A24C3AAFA76A9MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

During a build test, build bot gerrit-dev-macos10-14-x86_64 had a segf= ault during the build. The other three macos machines built fine.&nbs= p; Is this likely a problem with the build bot, or the code change? I= s there a way to make just that one bot try the build again?

Thanks.

-Ben

--_000_MWHPR0701MB367463F6CA2804B2A24C3AAFA76A9MWHPR0701MB3674_-- From kaduk@mit.edu Wed Aug 17 16:39:27 2022 From: kaduk@mit.edu (Benjamin Kaduk) Date: Wed, 17 Aug 2022 08:39:27 -0700 Subject: [OpenAFS-devel] buildbot segfault In-Reply-To: References: Message-ID: <20220817153927.GZ24514@kduck.mit.edu> On Wed, Aug 17, 2022 at 03:29:42PM +0000, Ben Huntsman wrote: > During a build test, build bot gerrit-dev-macos10-14-x86_64 had a segfault during the build. The other three macos machines built fine. Is this likely a problem with the build bot, or the code change? Is there a way to make just that one bot try the build again? There is, but IIRC it requires a login to the buildbot UI. Mike Meffie (cc'd) would probably remember more of the details, but I think the short form is that if you point us to the change we can push the button. -Ben From mmeffie@sinenomine.net Wed Aug 17 17:01:59 2022 From: mmeffie@sinenomine.net (Michael Meffie) Date: Wed, 17 Aug 2022 12:01:59 -0400 Subject: [OpenAFS-devel] buildbot segfault In-Reply-To: <20220817153927.GZ24514@kduck.mit.edu> References: <20220817153927.GZ24514@kduck.mit.edu> Message-ID: <20220817120159.be143f1a45c595df9a033a27@sinenomine.net> On Wed, 17 Aug 2022 08:39:27 -0700 Benjamin Kaduk wrote: > On Wed, Aug 17, 2022 at 03:29:42PM +0000, Ben Huntsman wrote: > > During a build test, build bot gerrit-dev-macos10-14-x86_64 had a segfault during the build. The other three macos machines built fine. Is this likely a problem with the build bot, or the code change? Is there a way to make just that one bot try the build again? > > There is, but IIRC it requires a login to the buildbot UI. > Mike Meffie (cc'd) would probably remember more of the details, but I think > the short form is that if you point us to the change we can push the > button. Marcio and I see it. clang crashed during the build. We are investigating. Thanks for the heads up! -- Michael Meffie From ben@huntsmans.net Wed Aug 24 19:06:22 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Wed, 24 Aug 2022 18:06:22 +0000 Subject: [OpenAFS-devel] AIX build works! Message-ID: --_000_MWHPR0701MB36748233A362DB63CB6E678EA7739MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone- With the last change I put up on gerrit this morning, the AIX build comp= letes on AIX 6.1 6100-09-12! And, while I'm still trying to get the Kerbre= os setup ironed out, loading the kernel extension and starting afsd doesn't= cause a panic anymore! So it appears to be mostly working! The one odd thing I did have to do is to manually add "-lk5crypto" to th= e Kerberos libs in src/config/Makefile.config, as I couldn't get the config= ure script to detect it properly. I'm not sure if that's an issue with IBM= 's Kerberos implementation, or with the OpenAFS configure script... Do I need to do anything next get the changes under the aix-6.1-build-fi= x topic accepted? Thank you all for your help so far! -Ben --_000_MWHPR0701MB36748233A362DB63CB6E678EA7739MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi everyone-

With the last change I put up on gerrit this morning, the AIX = build completes on AIX 6.1 6100-09-12! And, while I'm still trying to get the Kerbreos setup ironed out, loading the k= ernel extension and starting afsd doesn't cause a panic anymore! So i= t appears to be mostly working!

The one odd thing I did have to do is to manually add "-= lk5crypto" to the Kerberos libs in src/config/Makefile.config, as I couldn't get the configure script to detect it properly. I'm no= t sure if that's an issue with IBM's Kerberos implementation, or with the O= penAFS configure script...

Do I need to do anything next get the changes under the aix-6= .1-build-fix topic accepted?

Thank you all for your help so far!

-Ben

<= br>

--_000_MWHPR0701MB36748233A362DB63CB6E678EA7739MWHPR0701MB3674_-- From mmeffie@sinenomine.net Thu Aug 25 17:58:04 2022 From: mmeffie@sinenomine.net (Michael Meffie) Date: Thu, 25 Aug 2022 12:58:04 -0400 Subject: [OpenAFS-devel] OpenAFS release team weekly meeting Message-ID: <20220825125804.7b64e14839e902e2178a5ba8@sinenomine.net> OpenAFS release team weekly meeting Date: August 25, 2022 Participants: - Stephan Wiesand, OpenAFS Release Manager - Cheyenne Wills - Michael Meffie - Mark Vitale (Ben Kaduk is out today) (Apologies on the recent lapse in note taking. Logs are available in the link below.) The weekly release team meetings are held on Thursdays at 16:00 UTC (12:00 EDT) in release-team@conference.openafs.org on jabber. Please request login information if you would like to participate. Logs are available at: https://conference.openafs.org/release-team@conference.openafs.org/ NEWS ==== Stable (1.8.x) ============== * Stephan has prepared 1.8.9pre1 * NEWS file to be finalized and then Stephan will request Ben to make a tag for the release. * 14903 pulled up to 1.8.x branch in gerrit for review: 14903 LINUX: Use bitwise & for f_flags test Development (1.9.x/master) ========================== * Patches for AIX 6.1 support submitted by Ben Huntsman (thank you Ben Huntsman). * Patches to avoid fileserver deadlock submitted and then updated by Mark Vitale. * Changes to support linux 6.0 in progress. May be ready in time for 1.8.9, but we will not block 1.8.9 on it. Recent Changes ============== See https://gerrit.openafs.org/ for changes. Merged onto 'openafs-stable-1_8_x' branch since 2022-06-09: 15096 linux: Call put_page if errors in aops->readpages 15095 Linux-5.19: Remove flags from aops->write_begin 15094 Linux-5.19: Rename aops readpage to read_folio 15093 Linux: Introduce file mapping readpage helpers 15054 cf: Use -Werror when checking for -Wno-* flags 15065 Linux-5.18: replace readpages with readahead 15064 Prevent sscanf format widths from overrunning array 15063 opr: replace AFS_STRINGIZE with opr_stringize 15062 lwp: Ignore dangling-pointer warning in process.c 15061 afs: Avoid always-false NULL test on AFSTOV(avc) 15060 afs: introduce get_dcache_readahead 15059 afs: introduce afs_alloc_ncr/afs_free_ncr 15058 Linux-5.18 replace set_page_dirty with dirty_folio 15057 afsd: Avoid fscanf overflows when paring cacheinfo 15056 vol: Use asprintf in _namei_examine_special 15055 autoconf: fix detection for fallthrough attribute 14946 Linux-5.17: Kernel build uses -Wcast-function-type 15053 cf: Use common macro to test compiler flags 15052 LINUX: Don't panic on some file open errors 15051 afs: Introduce afs_IsDCacheFresh 15047 Change klog.krb5 -lifetime option help description 14945 Linux-5.17: kernel func complete_and_exit renamed 14991 clang-13: remove unused variables flagged by clang 14990 clang-10: ignore fallthrough warning in generated code 14989 LINUX: Honor --enable-checking for libafs 14987 ptserver: Fix CreateEntry() stringop-overflow warnings 14986 libadmin: Fix isAlias may be uninitialized warning 14985 bucoord: Fix doDispatch() array-parameter gcc warning 14984 Fix PrintInode() mismatched array parameter warnings 14983 pts: Fix stringop-overflow warnings 14982 ptserver: Fix CreateEntry() mismatched array parameter warning 14981 ubik: Fix ubeacon_updateUbikNetworkAddress() mismatched array parameter warning 14980 klog.krb5 -lifetime is not implemented 14979 ubik: do not reuse the offset variable for the sync site address 15037 afs: Remove redundant AFS_LINUX_ENV test 14978 Cleanup AFS_*LINUX_ENV usage 14977 Change AFS*_LINUXnn_ENV to AFS*_LINUX_ENV 14976 Remove AFS_PARISC_LINUX24_ENV references 14974 afs: Always define our own osi_timeval32_t 14972 afs: Move osi_GetTime out of param.h 14975 UKERNEL: remove redundant declaration of osi_GetTime 14971 Convert all osi_timeval_t to osi_timeval32_t 14973 UKERNEL: remove dead code osi_SetTime 14970 clang-10: use AFS_FALLTHROUGH for case fallthrough 14969 Add more 'fall through' switch comments 14968 vos: Properly print volume transaction flags 14967 autoconf: attribute type checks 14966 autoconf: check for format __attribute__ to avoid warnings 14944 Use autoconf-archive m4 from src/external 14943 Import of code from autoconf-archive 14942 Add autoconf-archive to src/external 14988 autoconf: import gcc function attribute check macro 14921 FBSD: Use GENERIC kernel headers by default 14920 FBSD: Avoid recursive osi_VM_StoreAllSegments lock 14878 Add sysname, files and header entries for FreeBSD 12.3 14880 tests: Accommodate c-tap-harness 4.7 14879 Import of code from c-tap-harness 14911 dir: Explicitly 'make all' in src/dir/test 14910 dir: make dtest buildable again 14909 build: declare test targets as phony 14815 rx: Remove delays in multi_End_Ignore 14814 fs: Avoid unnecessary cell DNS lookups 14813 afs: clarify cold and warm shutdown logic 14594 warn when starting without keys 14965 autoconf: Remove/update obsolete autoconf macros 14964 configure.ac: Add missing double include guard Updated for 'openafs-stable-1_8_x' branch since 2022-06-09: 14810 Make OpenAFS 1.8.9pre1 15126 Update NEWS for 1.8.9pre1 Merged onto 'master' branch since 2022-06-09: 15120 doc: Remove stray sect2 end tag 14903 LINUX: Use bitwise & for f_flags test 14889 autoconf: Additional library test for ncurses 14993 afs: Cleanup AFS_S390X_ENV statement 15116 export: Install kernel utilities with execute permissions on AIX 15107 afs: Fix missing def for timestruc_t on AIX 15106 rxevent: fix mismatched #endif 15070 viced: Verify primary host address 15092 systemd: do not load the 'openafs' module on boot 15066 viced: Show correct port/valid in state_analyzer 14818 bozo: Use buffered I/O to send notifier data 14833 bozo: Set instance output parameters with strdup 14797 bozo: Add bnode_GetNotifier() 15068 linux: Call put_page if errors in aops->readpages 15076 build: package ltmain.sh in the libafs_tree 14743 afs: Replace strcpy &co by safer alternatives 14585 cf: Run AFS_LT_INIT after setting CC 15041 Linux-5.19: Remove flags from aops->write_begin 15040 Linux-5.19: Rename aops readpage to read_folio 15039 Linux: Introduce file mapping readpage helpers 15049 autoconf: Remove redundant exit statements 15048 autoconf: Remove unused SUBARCH variable 14953 Linux-5.18: replace readpages with readahead 15046 CODING: Fix a couple of typos 15045 Change klog.krb5 -lifetime option help description 14766 bozo: Let the bnode operations allocate output strings 15043 bozo: Check for negative simple bnode parameter index 13136 Prevent sscanf format widths from overrunning array 15029 opr: replace AFS_STRINGIZE with opr_stringize 14957 lwp: Ignore dangling-pointer warning in process.c 14956 afs: Avoid always-false NULL test on AFSTOV(avc) 15031 bozo: Return BZDOM when BOZO_EnumerateInstance index is negative 15030 bozo: Use BZIO for out of memory errors 14962 afs: introduce get_dcache_readahead 15025 finale: Use unified_afs.o from objdir 14954 afs: introduce afs_alloc_ncr/afs_free_ncr 14902 afs: Use literal NULL for NULL function pointer 14901 cf: Avoid nested C functions built by autoconf 14900 cf: Use -Werror when checking for -Wno-* flags Updated for 'master' branch since 2022-06-09: 15121 klog: klog.krb5 -lifetime option 15122 afs: Use strlcat, strlcpy from roken to replace snprintf 15118 rx: Only use printf in the AIX kernel 15114 AIX: Fix install of 64-bit kernel module 15112 fsint: export symbol needed by fileserver 15110 export: Ignore additional build products generated on AIX 15125 viced: Avoid blocking multi_Rx in MultiProbeAlternateAddress_r 15124 viced: Avoid blocking multi_Rx in MultiBreakCallBackAlternateAddress_r 15123 viced: Avoid blocking multi_Rx in MultiBreakCallBack_r 15117 viced: Update host package lock precedence 13723 bozo: add -skip-root-check option 15119 BUILD: Ensure that make clean actually cleans all products 15113 util: Add missing symbol for AIX build 15108 afs: Fix missing def for pinned_heap on AIX 15105 cmd: Reset CMD_PROCESSED flag on parsing error 14679 butc: Fix problems found by static analysis 14653 volser: fix filecount and diskused during restores 14776 volser: Introduce struct RestoreInfo 14720 prdb_check: Check if creator of entries exists 14350 volser: introduce GetLockedEntry 14353 volser: clean up and clarify storeEntry usage 14356 volser: Always fetch locked entry in CheckVolume 14355 volser: refactor CheckVolume 14354 volser: ensure proper entry locking for 'vos restore' 14352 volser: convert UV_ReleaseVolume to call GetLockedEntry 15104 afsd: respect -confdir when parsing NetInfo & NetRestrict 15101 viced: remove dead code 'zerofid' 15103 util: Enable threadIdLogging for loglevel >=5 15102 afs: fix indentation and whitespace 15100 afs: prevent afs_xinterface lock leak and deadlock 13154 Close files when completed 15098 backup: Make backup tests build again 15097 backup: Remove obsolete test programs 15067 doc: Use make to build the man pages 15085 viced: Keep host locked after h_Lookup_r 15084 viced: rx_GetSpecific before alloc'ing identity 14941 venus: Convert binaries from LWP to pthreads 15083 viced: Introduce h_AllocIdent_r 15042 afs: Update VCHash comments on not hashing on uniq 15044 afs: Flush vcaches sooner if cache is stressed 14961 afs: Prioritize removal of unlinked vcaches 14949 afs: Convert afs_vhashT to use struct afs_q 15027 afs: Make FlushReclaimedVcaches() Darwin specific 15088 cmd: Introduce cmd_Tokenize(), cmd_Split(), and cmd_Join() 15087 tests: Verify cmd_ParseLine() output in libcmd tests 15086 libcmd: Fix memory leak in cmd_Parse() 15091 bos: Construct salvager command line with cmd_Join() 15089 bozo: Parse command lines with cmd_Tokenize() and cmd_Split() 15090 doc: update the DAFS GraphViz (.dot) diagrams 15082 viced: Lock host in MBCBAA 15081 viced: Handle addInterface_r addr conflicts 15080 viced: Introduce h_replacePrimaryAddr_r 15079 viced: Remove h_FreeConnection workarounds 15078 viced: h_AHTAHT_r after setting interface 15077 viced: Add fsstate2json.py 15075 viced: Avoid reconcileHosts_r during state restore 15074 viced: Add 'behavior' arg to h_AHTAHT_r 15073 viced: Improve removeAddress_r valid-address check 15072 viced: Restore hashtables after index remapping 15071 viced: Make GetHT return a held ref 12744 Do not merge: Check buildbot verification 14711 vos: Check start-of-dump magic in vos restore 14710 vos: Check end-of-dump magic before deleting volume 15069 vos: Open dump file before deleting volume in vos restore 14861 afs: Clean up indentation in afs.h 14895 bubasics: use config variable $(AR) to build libbubasics.a 13810 Remove non-JAVA refs to TOP_JLIBDIR 15038 Avoid more out of bounds indexing when checking volume names 15050 autoconf: Honor --enable-kernel-module 14907 volser: Don't provide dumps from the future 14937 volser: Warn on incremental dumps from the future 14778 vos: Avoid dumping volume to tty 14758 vos: Check end of dump magic when file is seekable 14777 usd: Add USD_IOCTL() is seekable check 14756 vos: Fix vos dump and restore dump file close error messages 14760 vos: Check for tty in vos restore 14759 vos: Add prefix to vos restore -overwrite constants 14757 vos: Get stdin and stdout block sizes with USD_IOCTL() 14054 tests: create c-tap tests for the directory package 15036 macos: Fix 'Parameter' tab on PrefPane 15035 macos: Fix 'CellServDB Editor' tab on PrefPane 15034 macos: Fix 'start/stop' option on PrefPane 15033 macos: Fix 'start at login' option on PrefPane 15032 macos: Add privileged helper tool for PrefPane 15026 rx: Check rxi_AddRpcStat currentFunc bounds 14587 macos: AFSBackgrounder: improve detection of afs mount status 14588 macos: AFSBackgrounder: report details of failed command 14586 macos: AFSBackgrounder: fail build for method not found 14591 macos: remove dead OpenAFS prefpane code -- Michael Meffie From ben@huntsmans.net Thu Aug 25 23:15:18 2022 From: ben@huntsmans.net (Ben Huntsman) Date: Thu, 25 Aug 2022 22:15:18 +0000 Subject: [OpenAFS-devel] AIX 7.1 build works! Message-ID: --_000_MWHPR0701MB36742A3DD926A3517BFA76CAA7729MWHPR0701MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone- It only took a few more updates to get the build completing on AIX 7.1, = and it works there too! I now have a working cell with one AIX 6.1 server = and one AIX 7.1 client! I'll push the changes for a 7.1 once the 6.1 patches get accepted, in or= der to avoid needing to rebase. Thank you all who have helped out with this! -Ben --_000_MWHPR0701MB36742A3DD926A3517BFA76CAA7729MWHPR0701MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi everyone-

It only took a few more updates to get the build completing on= AIX 7.1, and it works there too! I now have a working cell with one = AIX 6.1 server and one AIX 7.1 client!

I'll push the changes for a 7.1 once the 6.1 patches get accep= ted, in order to avoid needing to rebase.

Thank you all who have helped out with this!

-Ben

--_000_MWHPR0701MB36742A3DD926A3517BFA76CAA7729MWHPR0701MB3674_--