-
Notifications
You must be signed in to change notification settings - Fork 217
allow specifying location for RPATH wrapper scripts via rpath_wrappers_dir + also pass rpath_include_dirs when preparing build environment for extensions
#4596
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
3615517 to
bde0281
Compare
ed3800f to
5487954
Compare
|
This feature has been tested for EB 5 via easybuilders/easybuild-easyblocks#3661 |
| ext.toolchain.prepare(onlymod=self.cfg['onlytcmod'], silent=True, loadmod=False, | ||
| rpath_filter_dirs=self.rpath_filter_dirs) | ||
| rpath_filter_dirs=self.rpath_filter_dirs, | ||
| rpath_include_dirs=self.rpath_include_dirs, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The omission of this in the original call looks like a bug to me, so I have added it back...but I can't be 100%
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It likely doesn't actually matter as the wrappers will probably already have been prepared by the time this is called by an extension.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely a bug, I don't see a reason not to pass through rpath_include_dirs here.
See also call to self.toolchain.prepare in EasyBlock.prepare_step, where we do pass this down.
This is a genuine bug, and since this call to toolchain.prepare installs additional wrappers, the compiler wrapper from the parent is shadowed. Although I guess the RPATH wrapper script for the extension will use the RPATH wrapper script that was generated for the parent? Not sure about that (I'll check).
I'm a bit puzzled why this hasn't caused a whole bunch of problems, so it seems that somehow this hasn't actually been an issue in practice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure it has no impact, the wrappers have a protective clause to ensure that they do not wrap themselves.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It has no impact for 2nd extension, where we'll pick up on wrapper created for first extension.
But the RPATH wrapper that was created for the "parent" will no longer be found (because the build environment is reset before build environment for first extension is set up), and so the installation of extensions will be done with an incorrect RPATH wrapper script in which rpath_include_dirs is not picked up.
That's bad since $ORIGIN/../lib & co are specified that way (see how self.rpath_wrappers_dir is defined in EasyBlock.prepare_step).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hold on, the resetting of build environment before starting installation of extensions is not correct I think, I'm going through things in detail now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The rpath_include_dirs mechanism was implemented in #2358, which shows that it's only picked up by the "parent" toolchain.prepare, the call to toolchain.prepare for extensions was overlooked. That confirms to me this is a genuine bug.
I'm still a bit puzzled why this doesn't cause real trouble though, or how it has flown under the radar...
easybuild/tools/options.py
Outdated
| 'rpath-filter': ("List of regex patterns to use for filtering out RPATH paths", 'strlist', 'store', None), | ||
| 'rpath-override-dirs': ("Path(s) to be prepended when linking with RPATH (string, colon-separated)", | ||
| None, 'store', None), | ||
| 'rpath-wrappers-dir': ("Absolute path to directory to use for RPATH wrappers creation/use", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than adding an EasyBuild configuration option for this, we can just only give control over through an easyblock which can set self.rpath_wrappers_dir in the constructor, so there's no control from the outside to tweak the location of the generaed RPATH wrapper scripts.
…ing rpath_args.py into it
…m location for RPATH wrapper scripts is specified
boegel
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove `--rpath-wrapper-dir` configuration option + copy `rpath_args.py` script to avoid that RPATH wrapper scripts rely on external script
boegel
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
rpath_wrappers_dir + also pass rpath_include_dirs when preparing build environment for extensions
Based off of #4003