add explicit enabling/disabling of libffi with custom paths in LLVM easyblock

[Crivella]

Check if libffi is a dependency, if not disable using it or if yes explicitly add the location for FFI_INCLUDE_DIR and FFI_LIBRARY_DIR

• Fixes LLVM: Failures in building offload with ffi.h in non-standard location #3848

[Crivella]

@boegelbot please test @ jsc-zen3
EB_ARGS="--installpath /tmp/$USER/ebpr-3849 --from-pr 23429"
CORE_CNT=16

[boegelbot]

@Crivella: Request for testing this PR well received on jsczen3l1.int.jsc-zen3.fz-juelich.de

PR test command 'if [[ develop != 'develop' ]]; then EB_BRANCH=develop ./easybuild_develop.sh 2> /dev/null 1>&2; EB_PREFIX=/home/boegelbot/easybuild/develop source init_env_easybuild_develop.sh; fi; EB_PR=3849 EB_ARGS="--installpath /tmp/$USER/ebpr-3849 --from-pr 23429" EB_REPO=easybuild-easyblocks EB_BRANCH=develop /opt/software/slurm/bin/sbatch --job-name test_PR_3849 --ntasks="16" ~/boegelbot/eb_from_pr_upload_jsc-zen3.sh' executed!

• exit code: 0
• output:

Submitted batch job 7267

Test results coming soon (I hope)...

Details

- notification for comment with ID 3077544806 processed

Message to humans: this is just bookkeeping information for me,
it is of no use to you (unless you think I have a bug, which I don't).

[Crivella]

Report for the build of 20.1.5 in the companion pr

• add libffi as direct dependency in recent LLVM easyconfigs easybuild-easyconfigs#23429 (comment)

[Crivella]

@Thyre Thoughts on this, i think could lead to a similar problem we had for dlopening the CUDA/AMD libraries with offload.
In theory if libffi is not present and set to OFF i would expect to the offload to fall into the dlopen branch of the CMake logic, but this has not been tested (as we already bring libffi through other dependencies would require and ad-hoc build for it)
Not sure if there would ever be a case where you would want to compile LLVM without libffi and bring your own after?

[Thyre]

@Thyre Thoughts on this, i think could lead to a similar problem we had for dlopening the CUDA/AMD libraries with offload.

In theory if libffi is not present and set to OFF i would expect to the offload to fall into the dlopen branch of the CMake logic, but this has not been tested (as we already bring libffi through other dependencies would require and ad-hoc build for it)

Not sure if there would ever be a case where you would want to compile LLVM without libffi and bring your own after?

Not sure either, but I see a reason against it (for now): llvm/llvm-project#125449 (comment)

Seems like the whole libffi can be a bit brittle, and especially the dynamically loading part might be broken in recent versions. Would need to verify though.

If that would be fixed though, bringing in libffi dynamically should be just fine I think.

[ocaisa]

Testing done in easybuilders/easybuild-easyconfigs#23429

While there may be some lingering potential issues, they may only be realised in a scenario we don't have easyconfigs for.

[Thyre]

We should've probably checked if libffi is a dependency, right (via self.cfg.dependencies())?
I think the failure in easybuilders/easybuild-easyconfigs#23603 (comment) may well be caused by this change (though I don't know why not on jsc-zen3)