Skip to content
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

spack path length too long for Python scripts that use #! #54

Closed
lee218llnl opened this issue Jun 9, 2015 · 9 comments
Closed

spack path length too long for Python scripts that use #! #54

lee218llnl opened this issue Jun 9, 2015 · 9 comments
Labels
bug Something isn't working

Comments

@lee218llnl
Copy link
Contributor

I suspect this will be an issue in general with spack python builds given the inherently long path:

rzalastor1@lee218:/collab/usr/gapps/python/build/spack/opt/spack/chaos_5_x86_64_ib/gcc-4.4.7/python-2.7.10-yqkr6m74axh3nafjscgtjb3zj3htx3fe/bin/ipython
bash: /collab/usr/gapps/python/build/spack/opt/spack/chaos_5_x86_64_ib/gcc-4.4.7/python-2.7.10-yqkr6m74axh3nafjscgtjb3zj3htx3fe/bin/ipython: /collab/usr/gapps/python/build/spack/opt/spack/chaos_5_x86_64_ib/gcc-4.4.7/pyt: bad interpreter: Permission denied

@tgamblin
Copy link
Member

tgamblin commented Jun 9, 2015

@lee218llnl we could get rid of 42 characters of that particular path by getting rid of the prefix. e.g., we could install by default into $spack/opt/spack/. The only problem is that you lose human readability that way. That could be solved with Matt's views. I had thought about making a minimal install location, and using views for actually browsing, but it seemed like we could get the best of both worlds.

I know @mplegendre likes the default paths. @mplegendre: any thoughts on this? Looks like the default length for shebang paths in Linux is 128 bytes 👎 http://lxr.free-electrons.com/source/include/uapi/linux/binfmts.h#L18

@jprotze
Copy link
Contributor

jprotze commented Jun 9, 2015

The alternative would be using some wrapper script to handle oversized
shebangs as in:

http://stackoverflow.com/questions/10813538/shebang-line-limit-in-bash-and-linux-kernel

  • Joachim

Am 09.06.2015 um 13:43 schrieb Todd Gamblin:

@lee218llnl https://github.com/lee218llnl we could get rid of 42
characters of that particular path by getting rid of the prefix. e.g.,
we could install by default into $spack/opt/spack/. The only problem is
that you lose human readability that way. That could be solved with
Matt's views. I had thought about making a minimal install location, and
using views for actually browsing, but it seemed like we could get the
best of both worlds.

I know @mplegendre https://github.com/mplegendre likes the default
paths. @mplegendre https://github.com/mplegendre: any thoughts on
this? Looks like the default length for shebang paths in Linux is 128
bytes 👎
http://lxr.free-electrons.com/source/include/uapi/linux/binfmts.h#L18


Reply to this email directly or view it on GitHub
#54 (comment).

Dipl.-Inf. Joachim Protze

IT Center
Group: High Performance Computing
Division: Computational Science and Engineering
RWTH Aachen University
Seffenter Weg 23
D 52074 Aachen (Germany)
Tel: +49 241 80- 24765
Fax: +49 241 80-624765
protze@itc.rwth-aachen.de
www.itc.rwth-aachen.de

@tgamblin
Copy link
Member

tgamblin commented Jun 9, 2015

I think that's more of a pain because we'd have to implement wrapper generation in Spack for everything installed as a script. I suppose I can imagine how to implement that, but it does change the way the package is installed. I worry that this would break assumptions for some packages, though. Imagine a package where the author wants to patch an installed script, but Spack replaces it with a wrapper. I suppose if spack does that only after all build tasks it would be ok, but I still think it might be hard to maintain...

@cyrush
Copy link
Member

cyrush commented Nov 10, 2015

This bit us on chaos5 LLNL LC systems -- the kernel limit is actually 80 chars (after the shebang).

For our path we were getting cut off before the the hash even starts.

@tgamblin tgamblin added the bug Something isn't working label Dec 20, 2015
tgamblin added a commit that referenced this issue Mar 5, 2016
This does several things:

- Add `sbang`: a script to run scripts with long shebang lines.
  - Documentation for `sbang` is in `bin/sbang`.

- Add an `sbang` hook that filters the `bin` directory after install
  and modifies any scripts wtih shebangs that are too long to use
  `sbang` instead.

- `sbang` is at the top level, so it should be runnable (not much we
  can do if spack itself is too deep for shebang)
  - `sbang`, when used as the interpreter, runs the *second* shebang
    line it finds in a script.
  - shoud fix issues with too long shebang paths.
@tgamblin
Copy link
Member

tgamblin commented Mar 5, 2016

@cyrush: not sure the kernel limit is actually 80 chars, but that is what is printed out if this error happens. Want to test the fix I pushed? #497

@cyrush
Copy link
Member

cyrush commented Mar 6, 2016

@tgamblin great timing -- we are meeting all day Tuesday to resolve build system issues. I will test this then.

@mathstuf
Copy link
Contributor

I've seen shebangs being rewritten, so this should be fine now?

@tgamblin
Copy link
Member

Yes. We've had a number of reports of this being fixed. Reopen if not.

@cyrush
Copy link
Member

cyrush commented Apr 28, 2016

sorry for not reporting back -- we are successfully using the fix

matz-e added a commit to matz-e/spack that referenced this issue Sep 3, 2018
climbfuji added a commit to climbfuji/spack that referenced this issue May 3, 2022
Bug fix for setting correct hash length for modulefiles
greenc-FNAL added a commit to greenc-FNAL/spack that referenced this issue Oct 25, 2022
* root: fix behavior with system packages

* Fix style
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants