libc: use runtimes dir as base for cmake

[nickdesaulniers]

Fixes: #325

[nickdesaulniers]

@mikhailramalho can you please rm -rf * the contents of the libc-riscv32-qemu-yocto-fullbuild-dbg buildbot's build dir? The cmakecache is stale again as a result of this change.

[mikhailramalho]

Done, cmake is passing now but running the tests is failing: https://lab.llvm.org/buildbot/#/builders/196/builds/2315/steps/4/logs/stdio

Did the path to the tests change? rsync seems to be confused now

[nickdesaulniers]

Did the path to the tests change?

Maybe. I guess I'm surprised to see rsync involved; I would guess that's specific to the libc-riscv32-qemu-yocto-fullbuild-dbg buildbot? Can you reset rsync on the receiving end then if the paths for the tests did change? Perhaps that's necessary for the buildbot whenever resetting the cmake cache?

---

I'm also curious about the contents of /home/libcrv32buildbot/cross.sh. Is that the massive command line invocation for qemu? Looks like you set that script for -DCMAKE_CROSSCOMPILING_EMULATOR.

[mikhailramalho]

Hi @nickdesaulniers, sorry it took me so long to answer, I was OoO.

Did the path to the tests change?

Maybe. I guess I'm surprised to see rsync involved; I would guess that's specific to the libc-riscv32-qemu-yocto-fullbuild-dbg buildbot? Can you reset rsync on the receiving end then if the paths for the tests did change? Perhaps that's necessary for the buildbot whenever resetting the cmake cache?

Yes, we rsync the tests to qemu and call them via ssh.

I'm also curious about the contents of /home/libcrv32buildbot/cross.sh. Is that the massive command line invocation for qemu? Looks like you set that script for -DCMAKE_CROSSCOMPILING_EMULATOR.

Kinda, it copies the tests via rsync, builds the test call to be sent via ssh (the ENV vars and arguments), and calls the test:

$ cat cross.sh 
#!/bin/bash

#set -e -x

exit 0

ENV_VARS=$(env | grep -v -e "PWD" -e "GNOME_SHELL_SESSION_MODE" -e "LC_" -e "LOGNAME" -e "HOME" -e "USER" | sed 's/\([^=]*\)=\(.*\)/\1="\2"/' | tr '\n' ' ')

FULL_EXECUTABLE_PATH=$1
shift

ARGS=''
for i in "$@"
do
    ARGS+=" \"$i\""
done

RELATIVE_PATH=(${FULL_EXECUTABLE_PATH//build/ })
EXECUTABLE_DIR=$(dirname "${RELATIVE_PATH[1]}")

rsync -zcqav --ignore-errors --exclude=*CMakeFiles* --exclude=*cmake_install* --exclude=*.libc.a -e 'ssh -p 10222' ${RELATIVE_PATH}/ libcrv32buildbot@localhost:~/tests

ssh -o LogLevel=ERROR -o "UserKnownHostsFile=/dev/null" -o "StrictHostKeyChecking=no" libcrv32buildbot@localhost -p10222 "cd ~/tests/$EXECUTABLE_DIR && $ENV_VARS ~/tests/${RELATIVE_PATH[1]} $ARGS;"

[nickdesaulniers]

Hi @nickdesaulniers, sorry it took me so long to answer, I was OoO.

No worries. Any idea though what's going wrong still? Or what's causing the bot to fail?

Maybe --ignore-errors in the command line invocation of rsync is masking actual issues here?

Can you PTAL?

[mikhailramalho]

Yeah, for some reason rsync doesn't have permissions anymore in the qemu image to create directories, I'm not sure why.

[nickdesaulniers]

Is there anything in https://stackoverflow.com/questions/667992/rsync-error-failed-to-set-times-on-foo-bar-operation-not-permitted that helps?

Perhaps somehow libcrv32buildbot isn't the owner of /home/libcrv32buildbot/tests/? Can you see if maybe:

$ ssh -o LogLevel=ERROR -o "UserKnownHostsFile=/dev/null" -o "StrictHostKeyChecking=no" libcrv32buildbot@localhost -p10222 "chown -R libcrv32buildbot /home/libcrv32buildbot/tests"

resolves this?

[mikhailramalho]

Is there anything in stackoverflow.com/questions/667992/rsync-error-failed-to-set-times-on-foo-bar-operation-not-permitted that helps?

Perhaps somehow libcrv32buildbot isn't the owner of /home/libcrv32buildbot/tests/? Can you see if maybe:

$ ssh -o LogLevel=ERROR -o "UserKnownHostsFile=/dev/null" -o "StrictHostKeyChecking=no" libcrv32buildbot@localhost -p10222 "chown -R libcrv32buildbot /home/libcrv32buildbot/tests"

resolves this?

It was the right owner, but I couldn't write to the directory with that user. I recreated the user and home dir and it works now.

I hope the filesystem is not corrupted (it happened to me before locally). I'll keep an eye out for any strange behavior.

btw, we are no longer running the full test suite, just the unit tests.

[nickdesaulniers]

Cool, buildbot is back to green. Sorry my changes may have somehow triggered the breakage. Thanks for taking the time to reset the buildbot.