Conference call notes 20161012 - easybuilders/easybuild GitHub Wiki

(back to Conference calls)

Notes on the 61st EasyBuild conference call, Wednesday October 12th 2016 (5pm - 5.30pm CET)

Attendees

Alphabetical list of attendees (5):

  • Damian Alvarez Mallon (JSC, Germany)
  • Kenneth Hoste (HPC-UGent)
  • Adam Huffman (Francis Crick Institute, UK)
  • Guilherme Peretti Pezzi (CSCS, Switzerland)
  • Robert Schmidt (OHRI, Canada)

Agenda

Notes

EasyBuild demos
RPATH support
  • WIP PR @ https://github.com/hpcugent/easybuild-framework/pull/1942
  • includes finished Python script to determine -rpath= value + RPATH-specific extra sanity check
    • output of ldd, readelf on all binaries/libraries is checked in environment where $LD_LIBRARY_PATH is not defined
  • ready for testing...
  • avoid that LD_LIBRARY_PATH gets set via --filter-env-vars
    • cfr. https://github.com/hpcugent/easybuild-framework/pull/1943
    • chicken-or-egg situation: $LD_LIBRARY_PATH should no longer be defined for dependencies, but may still be required for whatever you're building with --rpath
    • modules can be regenerated with --module-only --force --filter-env-vars=LD_LIBRARY_PATH when switching to --rpath for all the things...
  • more (runtime) dependencies could be hoisted to build-only deps?
    • yes, but only if --rpath is enabled => troublesome for contributed easyconfig files
    • requires support for in-between type of dependencies, e.g. rpath_build_deps
      • these are build-only deps under --rpath
      • but remain runtime deps when --rpath is not used
      • better name?
    • can/should we detect automagically whether something is safe to use as build-only dep under --rpath?
      • if only lib and include subdirs are provided => build-only dep under --rpath?
      • maybe just a heuristic to use to determine what should be hoisted to rpath_build_deps...
Other