Hi all, We can certainly start discussing RPATH & co, and fork off a dedicated conf call later if needed. So yes, consider it part of the agenda for tomorrow's conf call.
K. > On 05 Jan 2016, at 21:31, 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/ >
