CVMFS client for RISC-V

[julianmorillo]

Hello, I can see in Getting Started that there is experimental support for RISC-V architecture. Are there any prebuilt CVMFS client package for RISC-V available somewhere? Or a way/instructions to build it from source? Thank you, Julián

[vvolkl]

No binary packages at the moment, unfortunately. I'd encourage you to build from source (see https://cvmfs.readthedocs.io/en/stable/cpt-quickstart.html#building-from-source) and report any problems you might encounter. You need some basic build-dependencies, for RHEL9 this should be exhaustive (see https://gitlab.cern.ch/cernvm/build-images/-/tree/master/docker?ref_type=heads for other distros):

        dnf -y install                     \
                       clang-analyzer          \
                       clang-tools-extra       \
                       cmake                   \
                       curl-devel              \
                       fuse-devel              \
                       fuse3-devel             \
                       gcc-c++                 \
                       gdb                     \
                       git                     \
                       golang                  \
                       hardlink                \
                       libattr-devel           \
                       libcap-devel            \
                       libffi-devel            \
                       libuuid-devel           \
                       make                    \
                       openssl-devel           \
                       python3-devel           \
                       rpm-build               \
                       ruby-devel              \
                       selinux-policy-devel    \
                       selinux-policy-targeted \
                       systemd                 \
                       which                   \
                       valgrind-devel          \
                       voms-devel              \
                       zlib-devel

attr fuse3 autofs httpd are also typically needed as runtime dependencies.

[julianmorillo]

Trying to build cvmfs from source in a RISC-V Fedora 37 system, I found out that the config.guess included in libressl-3.5.3 (as distributed with cvmfs) fails to detect the build system type. Downloading libressl-3.8.2.tar.gz into "externals/libcrypto" and changing both SSL_VERSION and CRYPTO_VERSION in bootstrap.sh file:

SSL_VERSION=3.8.2
CRYPTO_VERSION=3.8.2

worked for me, so probably it would be nice to update the libressl version distributed with cvmfs.

[julianmorillo]

I had the same problem with protobuf-2.6.1 (as distributed with cvmfs). In this case, the solution was:

• download protobuf-21.10-all.tar.gz into "externals/protobuf"
• rename it as protobuf-21.10.tar.gz
• making the following changes in bootstrap.sh:

  #PROTOBUF_VERSION=2.6.1
  PROTOBUF_VERSION=21.10

  and

  protobuf)
    #do_extract "protobuf"     "protobuf-${PROTOBUF_VERSION}.tar.bz2"
    do_extract "protobuf"     "protobuf-${PROTOBUF_VERSION}.tar.gz"
    #patch_external "protobuf" "fix-iterator-cxx17.patch"
    do_build "protobuf"
    ;;

• and adding "autoreconf" command to externals/protobuf/src/configureHook.sh:

  
  #!/bin/sh

21.10 version comes without configure script in place

autoreconf -vfi CFLAGS="$CVMFS_BASE_C_FLAGS -fPIC" CXXFLAGS="$CVMFS_BASE_CXX_FLAGS -fPIC" ./configure --without-zlib --disable-shared \ --prefix=$EXTERNALS_INSTALL_LOCATION

With this, I managed to do the complete build in a Fedora 37 RISC-V system. 
The only thing that bothers me is that I'm not sure about the implications at runtime of not doing the patch "**fix-iterator-cxx17.patch**" that was meant for 2.6.1 version.

[vvolkl]

@julianmorillo Great! Thanks for letting us know. Updating these dependencies can indeed have implications for the runtime. Can you open a PR with your changes? We may not immediately merge this, but we can run our test suite, this should give a clear picture if you can do these updates without creating problems at runtime.

[vvolkl]

It looks to me that the "fix-iterator-cxx17.patch" can be safely dropped if the build succeeds.

[julianmorillo]

@julianmorillo Great! Thanks for letting us know. Updating these dependencies can indeed have implications for the runtime. Can you open a PR with your changes? We may not immediately merge this, but we can run our test suite, this should give a clear picture if you can do these updates without creating problems at runtime.

@vvolkl Yes, sure. I'll do it. Thank you for your comments.

[jblomer]

The problem is that, as far as I know, the wire format between the two protobuf versions is not the same. At least this is what we'd need to verify: if sender and receiver can be on the two different protobuf versions.

[julianmorillo]

Ok, I see that updating these dependencies can represent a potential problem. As the issue was with the config.guess file included in them and not with the dependency versions themselves, I opted for a cleaner/safer solution: I just added an autoreconf -vfi command in the corresponding configureHook.sh file. So, in the end, it will be a very simple PR.