I can try to hop on the call briefly at the beginning, but I won't be able to stay for the whole thing. I have some guests visiting LLNL who I have to meet about halfway through.
-Todd From: <[email protected]> on behalf of Robert Schmidt <[email protected]> Reply-To: "[email protected]" <[email protected]> List-Post: [email protected] Date: Tuesday, January 5, 2016 at 12:48 PM To: "[email protected]" <[email protected]> Subject: Re: [easybuild] next EasyBuild conf call: Wed Jan 6th 2016, 5pm CET > 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 <tel:%2B49%202461%2061%205213> >>> Fax: +49 2461 61 6656 <tel:%2B49%202461%2061%206656> >>> 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/ >>
