core packages: long interpreter lines with long nix store path prefix

[martinvahi]

The details are accidentally at the Nix bugtrack, but I closed the original flaw report due to suggestions that it does not belong to the list of Nix package manager flaws.

[falsifian]

I'm guessing this has to do with long ELF interpreter paths.

Notice that both of the "bad interpreter paths" are cut off at 76 characters: /opt/2dot7TiB_k8vaketas/ts2/mittevarundatav/_home/m_local/bin_p/Nix/paketiho and /opt/2dot7TiB_k8vaketas/ts2/mittevarundatav/_home/m_local/bin_p/Nix/nix_hoid

Has anyone seen issues with long ELF interpreter paths before? Paging a couple of recent PatchELF contributors: @edolstra, @darealshinji.

Meanwhile, a question and a couple of things you might be able to try:

• Question: have you been able to install anything at all?
• If you want to save some headache, you might be able to use PRoot to simulate having everything under /nix/store. I have not tried these instructions.
• If you can't get /nix/store, can you at least get a path that is almost that short? (Ideally you shouldn't have to, but this could help diagnose the problem.)

[vcunat]

I don't think it's about ELF but about shebang lengths (note the error is in gcc wrapper). When we patchShebang to absolute bin/env, you get the nix store prefix twice in the line. I this case the prefix is far too long, as the typical limit is 127 characters (imposed by the kernel). I think we've discussed the issue here already, but I'm unable to find it.

As suggested, PRoot would have additional advantage of being able to get binaries from Hydra.

[falsifian]

Thanks @vcunat. What is the purpose of using env in the shebang paths here? I thought it was typically used when the absolute path wasn't known, e.g. #!/usr/bin/env python when you know the path to env but not to python.

[falsifian]

And, more to the point, in theory could #!/a/b/0123/env /a/b/5678/python be replaced with #!/a/b/8abc/env_and_python_wrapper by making a wrapper script in each case?

[vcunat]

What is the purpose of using env in the shebang paths here?

Maybe env isn't even used in these particular cases, but it will certainly be needed in some, as discussed in #6227, /usr/bin/env is not present in chroots so can't be used during build (that would be one way to improve this problem).

But in this case the store prefix is so long that even single occurrence is a problem - 113 characters up to the dash after hash, and then you need package name with version and the inner path... Note that the limit of 127 is in the kernel, so we can't affect that on non-NixOS. I don't see what can be done except for shortening the path somehow (e.g. via proot).

[martinvahi]

After some experimentation I got the hello to work by offering

/home/ts2/inst/nix

as the

./configure --prefix=/home/ts2/inst/nix

However, I suspect that it is not the only issue. For example, the

<nix installation home>/etc/profiles.d/nix.sh

seemed to be not working, if the Nix installation path was

./configure --prefix=/opt/nix
# id est outside of $HOME

So, may be there is a mixture of issues at play.

[vcunat]

Yeah, well, I think only a rather small fraction of users have non-standard nix store prefix (I'm not counting prooted users), so there might be multiple bugs undiscovered.

[martinvahi]

I'm not sure, if it is relevant here, but if You use Python somewhere in the guts of the Nix, then there's the issue of Python string lengths. In theory there is practically no limit, but in practice the Mercurial had a limit that if the file path was significantly longer than about 1024 characters, then it did not work any more and it is possible to find other, similar, observations about Python from the wild-wild-web.

[vcunat]

No, we just use C++ and perl for some relatively simple wrappers (and slowly getting rid of perl NixOS/nix#341).

@martinvahi: note the related report I linked now.

[jagajaga]

Wasn't this fixed yet?

[vcunat]

No, I don't think any step has been taken towards this. And I can't see what could be done about it, except for work-arounds to use shorter path for nix store.

[darealshinji]

Notice that both of the "bad interpreter paths" are cut off at 76 characters: /opt/2dot7TiB_k8vaketas/ts2/mittevarundatav/_home/m_local/bin_p/Nix/paketiho and /opt/2dot7TiB_k8vaketas/ts2/mittevarundatav/_home/m_local/bin_p/Nix/nix_hoid

If the problem is really that the paths are too long and you don't know how to fix it yet, does it help if you're using symbolic links as shortcuts? I.e. /opt/6RthxJ -> /opt/2dot7TiB_k8vaketas/ts2/mittevarundatav/_home/m_local/bin_p/Nix/paketiho

[Profpatsch]

nix is not really made for having the store deeper than in /nix/store, since shebang lines are restricted to 127 bytes by the linux kernel (see linux-headers…/include/linux/limits.h)
As far as I know, having the nix store anywhere else is not supported.

As such I’m gonna close this issue now, feel free to reopen if some other solution is found.

[martinvahi]

A citation from the @Profpatsch answer:

nix is not really made for having the store deeper than
in /nix/store, since shebang lines are restricted to 127 bytes
by the linux kernel (see linux-headers…/include/linux/limits.h)
As far as I know, having the nix store anywhere else is not supported.

May be one workaround to the default 127 shebang length limit
might be that in stead of using

#!<a very long path to the program that runs the script>

the /nix/store/<the world of Nix> long path analogue
<very long path to the /nix/store analogue>
might be made accessible by

export NIX_CUSTOM_STORE="<very long path to the /nix/store analogue>"

and the shebangs at the Nix scripts would look like

#!/opt/nix_utilities/exec_script <the relative path within the classical /nix/store>

The /opt/nix_utilities/exec_script would read in the
value of the environment variable NIX_CUSTOM_STORE by doing

bash -c "cd $NIX_CUSTOM_STORE ; <the relative path within the classical /nix/store>"

The NIX_CUSTOM_STORE might allow easy switching between
multiple Nix store instances.

It's just a wild, untested, idea.
Thank You for reading my comment.