Todd, it is an interesting idea to use RPATH deeper in the hierarchy. I think you know the use case pretty well here. Are you planning on attending the call or maybe we can arrange one to include your input?
I would add that it might be worthwhile talking about $ORIGIN and relocation. This is one thing that conda does reasonably well and is an interesting feature, especially for distributing binaries. It does seem like an area where we can work with spack and specifically the dependency resolution code. On Tue, Jan 5, 2016 at 3:32 PM Xavier Besseron <[email protected]> wrote: > Dear all, > > I would also be in favor of having a discussion about RPATH/RUNPATH/etc. > I'm not totally sure it is doable, but I believe it should be investigated. > > However, I'm not sure that the next EasyBuild conf call will be the right > place to discuss this (unless we want it to last for one hour). > Kenneth, do you want to include this topic in the agenda? > > If you plan to discuss this, during this EasyBuild conf call, or at > another dedicated conf call, please tell us because I will interested to > join the discussion. > > > Xavier > > > > > On Tue, Jan 5, 2016 at 12:31 PM, Gamblin, Todd <[email protected]> wrote: > >> 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]> 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] >> 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 >> >> ------------------------------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------------------------ >> >> > > > -- > Dr Xavier BESSERON > Research associate > FSTC, University of Luxembourg > Campus Kirchberg, Office E-007 > Phone: +352 46 66 44 5418 > http://luxdem.uni.lu/ > >
