Spack links with RPATHs. It also allows you to have sub-DAG(s) built with different compiler(s). It's not the default, but it's easy to specify if you need it:
spack install tool%intel ^wx%gcc You can also encode that in the package if it really requires gcc. We've played with RUNPATH at LLNL and it's not as easy as you might think to swap it in for RPATH. The compiler options for RUNPATH are less consistent and I'm not sure it's supported on all of them, though I haven't checked recently. I've not yet encountered a compiler without RPATH support -- have you? RedHat recently asked us about getting rid of RPATH and we told them no pretty emphatically. The main issue with RUNPATH is the one mentioned in the Qt blog below. Its semantics differ from RPATH for indirect dependencies -- it's easy for system libs to leak into a RUNPATH'd binary. Personally I think this is broken. If you want your executables to "just work", use RPATH. The other thing about RUNPATH is that it allows your users to shoot themselves in the foot with LD_LIBRARY_PATH. They never remember that they stuck that line in their bashrc that one time for that one code, and blam everything's broken. RPATH puts the precedence in the hands of the tool, which knows how to link, at least in theory. Combining RPATH with lmod hierarchies is something we talked about at the hackathon. I haven't thought too deeply about this but I think RPATHs would really simplify the management code that goes into hierarchical modules - for deps that are not "in" the hierarchy (e.g. Boost), if you RPATH them you don't have to generate code to load/unload them on swap if, say, one leaf needs one boost version and another leaf requires a different boost version. Todd ________________________________ From: [email protected] on behalf of Alan O'Cais Sent: Tuesday, January 05, 2016 2:24:39 AM To: [email protected] Subject: Re: [easybuild] next EasyBuild conf call: Wed Jan 6th 2016, 5pm CET How about some further discussion on RPATH/RUNPATH, what's involved in supporting it and whether or not it's a good idea (since RPATH is actually depreciated for about 15 years in favour of RUNPATH but still typically respected https://sourceware.org/ml/binutils/2012-05/msg00025.html). From what it I understand RUNPATH will ensure a binary always find it's libs but gives priority to LD_LIBRARY_PATH, how things really function is not that straightforward though (see "Why does this happen?" in http://blog.qt.io/blog/2011/10/28/rpath-and-runpath/). Personally I think I might be favour of creating an abstraction layer between the module view (default, hierarchy,...) and the installations and combining this with RUNPATH. I don't see a good reason to change where things get installed based on the module naming scheme, all we really need is the ability to translate between the default naming scheme and other naming schemes (which is trivial since if we know the installation path for the default, we can grab all the installed eb files from within). If you couple this with RUNPATH, every executable/lib will just work even if you cherry pick the modules you want to expose to users. This would have huge advantages in the sense that we could use different naming schemes for different groups on the same system and the same installations. It would also remove the disadvantages currently imposed by hierarchical schemes (wxwidgets only builds with GCC and since I can't/shouldn't load GCC and intel at once in a proper hierarchical scheme, nothing that requires wxwidgets can be built for intel, this restriction doesn't exist for the default naming scheme and would be solved in the hierarchical scheme with RUNPATH). Alan Alan On 5 January 2016 at 10:33, Kenneth Hoste <[email protected]<mailto:[email protected]>> wrote: Dear EasyBuilders, The next EasyBuild conf call is planned for tomorrow, Wed Jan 6th 2016, at 5pm CET. (Google+ event: https://plus.google.com/events/cv4pst7c0s9kbrgnofca4dkdgvs) Topics I have in mind include: * 2016a common toolchains * support for eb --new-pr (WIP) * cfr. https://github.com/hpcugent/easybuild-framework/pull/1528 * workaround for issues with Python packages being picked up from the OS (WIP) * cfr. https://github.com/hpcugent/easybuild-easyblocks/pull/786 * open Q&A Suggestions for other topics are welcome, as usual. Please let me know in one way or another if you're planning to attend. More details on the EasyBuild conf calls are available at https://github.com/hpcugent/easybuild/wiki/Conference-calls . regards, Kenneth -- Dr. Alan O'Cais Application Support Juelich Supercomputing Centre Forschungszentrum Juelich GmbH 52425 Juelich, Germany Phone: +49 2461 61 5213 Fax: +49 2461 61 6656 E-mail: [email protected]<mailto:[email protected]> WWW: http://www.fz-juelich.de/ias/jsc/EN ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------
