OpenAFS Master Repository branch, master, updated. openafs-devel-1_9_2-162-g67832fc
Gerrit Code Review
gerrit@openafs.org
Fri, 28 Feb 2025 11:26:39 -0500
The following commit has been merged in the master branch:
commit 67832fcd817e4b0febf7f1fde465e35d5cda7709
Author: Andrew Deason <adeason@sinenomine.net>
Date: Mon Feb 24 11:46:14 2025 -0600
Generate AFS_cvn.c in 'depinstall' targets
Currently, the 'depinstall' target of various subdirs generates various
headers and source files, but usually does not generate
AFS_component_version_number.c. One exception is src/afs, which has
generated AFS_component_version_number.c from depinstall since commit
782109a29b (no-copy-libafs-builds-20021015).
This can actually contribute to build errors. For example:
Our top-level 'libuafs' target depends on rx_depinstall and
afs_depinstall (among other targets). For afs_depinstall, this causes us
to generate src/afs/AFS_component_version_number.c,
src/afs/unified_afs.c, and some headers. For rx_depinstall, we don't
generate src/rx/AFS_component_version_number.c.
Inside src/libuafs, all of our build objects (LT_objs) depend on 'h', a
directory of header stubs we generate. The 'h' dir depends on all of the
*.c files in src/afs/, src/afs/VNOPS/, and src/rx/. After libuafs
finishes building (or while it's building, for a parallel build), we may
go into src/rx and 'make all', which will cause
AFS_component_version_number.c to be generated.
After all this is done, then we may have a
src/rx/AFS_component_version_number.c that is newer than
src/libuafs/libuafs.a. If we go into src/libuafs and 'make all' again,
this will cause us to rebuild everything in libuafs, because one of the
src/rx/*.c source files is newer than src/libuafs/h, and so we'll
recreate src/libuafs/h and rebuild all of our .lo objects and generate
libuafs.a again.
On DARWIN, if we try to generate libuafs.a when libuafs.a already
exists, this can fail if we are building for multiple architectures via
ARCHFLAGS. For example:
/bin/sh ../../libtool --quiet --mode=compile --tag=CC gcc -arch x86_64 -arch arm64 [...] -o xdr_len.lo
/bin/sh ../../libtool --quiet --mode=link --tag=CC gcc -static -g -Os -o libuafs.a [...]
ar: libuafs.a is a fat file (use libtool(1) or lipo(1) and ar(1) on it)
ar: libuafs.a: Inappropriate file type or format
make[3]: *** [libuafs.a] Error 1
All of this means that the build can fail sometimes with these simple
commands on DARWIN:
$ ARCHFLAGS='-arch x86_64 -arch arm64' ./configure [...]
$ make -j8
$ make dest
To avoid this, change the src/rx makefile to generate
AFS_component_version_number.c in 'make depinstall', so we know all of
our generated files are generated before building libuafs. There are
maybe some other issues with libtool throwing the error mentioned above,
but at least this avoids needing to rebuild all of libuafs
unnecessarily.
To try to keep things consistent, also change all other makefiles with
'depinstall' targets to generate AFS_component_version_number.c if they
ever generate AFS_component_version_number.c. For src/tptserver, just
remove the 'depinstall' target instead, since it is never actually used.
Thanks to mvitale@sinenomine.net for reporting and helping investigate
this issue.
Change-Id: Icf7ff75584a918f09afdb135242d6fe0ced83aa8
Reviewed-on: https://gerrit.openafs.org/16287
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
src/auth/Makefile.in | 3 ++-
src/dir/Makefile.in | 3 ++-
src/kauth/Makefile.in | 3 ++-
src/libacl/Makefile.in | 3 ++-
src/libafscp/Makefile.in | 3 ++-
src/lwp/Makefile.in | 3 ++-
src/ptserver/Makefile.in | 3 ++-
src/rx/Makefile.in | 3 ++-
src/sys/Makefile.in | 3 ++-
src/tptserver/Makefile.in | 4 +---
src/tvlserver/Makefile.in | 2 +-
src/ubik/Makefile.in | 3 ++-
src/util/Makefile.in | 3 ++-
src/vlserver/Makefile.in | 3 ++-
14 files changed, 26 insertions(+), 16 deletions(-)
--
OpenAFS Master Repository