[OpenAFS-devel] GNU glibc >=2.26 and openafs

Post by Peter Gille
Hi,
in the recent release of GNU glibc 2.26[1] the sunrpc implementation was
deprecated. This means that if you do not use the
'--enable-obsolete-rpc' configure option when compiling glibc your
openafs compile will fail with a missing include[2], and probably some
further problems if you fix that.
In the release notes for glibc it states that you should instead use
alternative rpc implementations like TIRPC or rpcsvc-proto. As far as I
can see there is no support in the openafs configure script to use those
instead.
Would it be possible to use those alternative implementations if found?
Are they workable replacements for the old sunrpc?

I think that as of commit 7293ddf325b149cae60d3abe7199d08f196bd2b9
(so, quite some time ago), we are supposed to only be using the
in-tree XDR bits, at least for userspace builds. So it should be
easy to resolve this issue by just removing the offending include
directives -- I took a stab in the chain of patches ending at
https://gerrit.openafs.org/#/c/12802/ .

Post by Peter Gille
This is currently causing problems for my gentoo install where the
packagers have already switched off sunrpc support in glibc, and I
expect that other distributions will also turn this off in the future.

Well, it looks like 2.26 is only in debian experimental so far, so
my systems (on unstable) haven't picked it up yet. Could you give
the above patches a try and see if they help?

Thanks,

Ben

Peter Gille

2017-12-10 12:58:43 UTC

Post by Benjamin Kaduk
I think that as of commit 7293ddf325b149cae60d3abe7199d08f196bd2b9
(so, quite some time ago), we are supposed to only be using the
in-tree XDR bits, at least for userspace builds. So it should be
easy to resolve this issue by just removing the offending include
directives -- I took a stab in the chain of patches ending at
https://gerrit.openafs.org/#/c/12802/ .

Ah, ok. That was good news.

Post by Benjamin Kaduk
Well, it looks like 2.26 is only in debian experimental so far, so
my systems (on unstable) haven't picked it up yet.

Sure. It was released in August so I would have been surprised if any
major distro picked it up yet. Still, it's good to be prepared.
Especially since this turned out to be a fairly minor patch.

Post by Benjamin Kaduk
Could you give the above patches a try and see if they help?

They seem to work on 1.8.0_pre3 but I'm getting some unrelated linking
errors there so I can't actually run it at the moment.

Adapting the patches to apply to 1.6.22 seems to work except there is
one include that is missed in src/rxkad/rxkad_client.c, line 40.
Commenting that out as well gives a working compile and a running afs.

Post by Benjamin Kaduk
Thanks,
Ben

Thanks for the quick fix!

Cheers,
Peter

Benjamin Kaduk

2017-12-10 20:38:04 UTC

Ah, ok. That was good news.

Post by Benjamin Kaduk
Well, it looks like 2.26 is only in debian experimental so far, so
my systems (on unstable) haven't picked it up yet.

Sure. It was released in August so I would have been surprised if any
major distro picked it up yet. Still, it's good to be prepared.
Especially since this turned out to be a fairly minor patch.

Well, the Solaris buildbots don't seem to like it, with a pretty
opaque error message (at least to me), so it will probably need a
little more tweaking before it can land on master, but it's
definitely promising.

Post by Benjamin Kaduk
Could you give the above patches a try and see if they help?

They seem to work on 1.8.0_pre3 but I'm getting some unrelated linking
errors there so I can't actually run it at the moment.

Please tell me more about the linker errors on 1.8.0pre3! Until
now, the only known potential blocker for 1.8.0-final is the issue
with getcwd() failures on RHEL 7.4, so we'd really like to hear more
about peoples' experiences with the latest beta.

Post by Peter Gille
Adapting the patches to apply to 1.6.22 seems to work except there is
one include that is missed in src/rxkad/rxkad_client.c, line 40.
Commenting that out as well gives a working compile and a running afs.

Maybe 4659c5c9924171525454cd2a2280ed9370476998 fixed that one on
master.

Thanks for testing!

-Ben

Peter Gille

2017-12-11 08:53:48 UTC

Post by Benjamin Kaduk
Could you give the above patches a try and see if they help?

They seem to work on 1.8.0_pre3 but I'm getting some unrelated linking
errors there so I can't actually run it at the moment.

When compiling 1.8.0_pre3 + these patches with './configure && make' I
get the following error (without the patches it of course errors out
earlier AFAICT):

gcc -fPIC -O -I/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/src/config -I/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/include -I. -I. -o map.o -c map.c
gcc -L/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib -O -O -I/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/src/config -I/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/include -I. -I. -o ptserver ptserver.o ptutils.o ptprocs.o ptint.ss.o .lwp/ptint.xdr.o \
utils.o map.o /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libubik.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libauth.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/librxkad.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/librxstat.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/librx.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/liblwp.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libcmd.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libafscom_err.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libsys.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libaudit.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libafsutil.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libopr.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libafsrfc3961.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libafshcrypto_lwp.a -lroken -lresolv
/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libauth.a(userok.o): In function `ParseLine':
userok.c:(.text+0x147): undefined reference to `base64_decode'
/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libauth.a(userok.o): In function `afsconf_AddIdentity':
userok.c:(.text+0xbd9): undefined reference to `base64_encode'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:108: ptserver] Error 1
make[3]: Leaving directory '/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/src/ptserver'
make[2]: *** [Makefile:239: ptserver] Error 2
make[2]: Leaving directory '/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3'
make[1]: *** [Makefile:650: build] Error 2
make[1]: Leaving directory '/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3'
make: *** [Makefile:32: all] Error 2

If you want me to do some additional testing/reporting I can do that.

Cheers,
Peter

Benjamin Kaduk

2017-12-11 16:54:00 UTC

Post by Benjamin Kaduk
Could you give the above patches a try and see if they help?

They seem to work on 1.8.0_pre3 but I'm getting some unrelated linking
errors there so I can't actually run it at the moment.

When compiling 1.8.0_pre3 + these patches with './configure && make' I
get the following error (without the patches it of course errors out
gcc -fPIC -O -I/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/src/config -I/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/include -I. -I. -o map.o -c map.c
gcc -L/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib -O -O -I/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/src/config -I/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/include -I. -I. -o ptserver ptserver.o ptutils.o ptprocs.o ptint.ss.o .lwp/ptint.xdr.o \
utils.o map.o /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libubik.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libauth.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/librxkad.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/librxstat.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/librx.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/liblwp.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libcmd.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libafscom_err.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libsys.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libaudit.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libafsutil.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libopr.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libafsrfc3961.a /var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/lib/libafshcrypto_lwp.a -lroken -lresolv
userok.c:(.text+0x147): undefined reference to `base64_decode'
userok.c:(.text+0xbd9): undefined reference to `base64_encode'
collect2: error: ld returned 1 exit status

Ah, are you configuring with external/system roken? Current heimdal
roken has renamed these symbols to have an rk_ prefix, but our
in-tree snapshot is from before that change. Debian is dealing with
this via
https://anonscm.debian.org/cgit/pkg-k5-afs/openafs.git/tree/debian/patches/0003-Catch-up-to-roken-s-rename-of-base64-symbols.patch?h=experimental
.
I guess we could make configure smart enough to figure out which one
to use, now that I think about it. (I had mostly been assuming that
we would pull in a newer shapsnot of heimdal, but that work has not
been prioritized.)

-Ben

Benjamin Kaduk

2017-12-12 01:30:42 UTC

Post by Benjamin Kaduk
Ah, are you configuring with external/system roken? Current heimdal
roken has renamed these symbols to have an rk_ prefix, but our
in-tree snapshot is from before that change. Debian is dealing with
this via
https://anonscm.debian.org/cgit/pkg-k5-afs/openafs.git/tree/debian/patches/0003-Catch-up-to-roken-s-rename-of-base64-symbols.patch?h=experimental
.
I guess we could make configure smart enough to figure out which one
to use, now that I think about it. (I had mostly been assuming that
we would pull in a newer shapsnot of heimdal, but that work has not
been prioritized.)

Yes, apparently (right now I just do a straight ./configure with no
other options just to check if it compiles or not[1]). Possibly I should
adjust the flags to the configure script parameters somewhat?

Huh, I thought straight ./configure would use the internal roken.

Maybe you should send me (unicast) your config.log.

make[3]: Entering directory '/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/src/libafscp'
gcc -O -I/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/src/config -I/var/tmp/portage/net-fs/openafs-1.8.0_pre3-r1/work/openafs-1.8.0pre3/include -I. -I. -pthread -D_REENTRANT -DAFS_PTHREAD_ENV -o afscp_callback.o -c afscp_callback.c
This seems like some settings the configure script is trying to find,
but I'm not at all good at working with autotools. I tried this with
both Heimdal 7.4 and then I tried upgrading to the newly released 7.5
and got the same error.

This one seems pretty bizzare, as AC_SUBST() is supposed to cause
configure to expand that @KRB5_CPPFLAGS@ out to something useful.

Might be worth trying anew in a clean (freshly extracted, plus
patch) tree just in case something got confused somewhere.

Thanks for trying it out,

Ben

Peter Gille

2017-12-12 15:20:17 UTC

Huh, I thought straight ./configure would use the internal roken.
Maybe you should send me (unicast) your config.log.

I will send you a config.log of the working build (see below)
separately.

This one seems pretty bizzare, as AC_SUBST() is supposed to cause
Might be worth trying anew in a clean (freshly extracted, plus
patch) tree just in case something got confused somewhere.

Ah, ok. I tried it now by hand and things compiled without problems. I
did not try to run it yet, but it seems like it should work.

This issue was triggered by me being lazy and doing 'ebuild
openafs-1.8.0_pre3-r1.ebuild prepare' to automatically unpack and patch
the openafs sources. As it turns that also runs the following, which I
didn't expect:

eaclocal -I src/cf
eautoconf
eautoconf -o configure-libafs configure-libafs.ac
eautoheader

According to a colleague who has quite a lot of experience with openafs
and kerberos there are known issues with running the wrong version of
autoconf with the wrong version of heimdal, so he said that something
like this isn't entirely entirely unexpected.

Post by Benjamin Kaduk
Thanks for trying it out,

No problem.

Cheers,
Peter

Benjamin Kaduk

2017-12-12 22:34:42 UTC

Post by Benjamin Kaduk
Huh, I thought straight ./configure would use the internal roken.
Maybe you should send me (unicast) your config.log.

I will send you a config.log of the working build (see below)
separately.

Thanks. Apparently I was wrong, and straight ./configure does look
for system roken/hcrypto/etc.. In your case, the system roken was
usable but the system hcrypto was not (apparently it was not present
at all, since evp.h was not found).

This one seems pretty bizzare, as AC_SUBST() is supposed to cause
Might be worth trying anew in a clean (freshly extracted, plus
patch) tree just in case something got confused somewhere.

Ah, ok. I tried it now by hand and things compiled without problems. I
did not try to run it yet, but it seems like it should work.
This issue was triggered by me being lazy and doing 'ebuild
openafs-1.8.0_pre3-r1.ebuild prepare' to automatically unpack and patch
the openafs sources. As it turns that also runs the following, which I
eaclocal -I src/cf
eautoconf
eautoconf -o configure-libafs configure-libafs.ac
eautoheader
According to a colleague who has quite a lot of experience with openafs
and kerberos there are known issues with running the wrong version of
autoconf with the wrong version of heimdal, so he said that something
like this isn't entirely entirely unexpected.

I'm somewhat curious to know more about those cases, though only
idly curious, as I'm not convinced it's actually relevant here.
We're not using the heimdal configure.ac/etc., just the openafs
ones.

It is sounding like we should probably leave this particular issue
for now, unless/until the portage maintainer for openafs wants to
take up the issue. Does that sound okay?

Thanks again,

Ben

Peter Gille

2017-12-13 15:26:29 UTC