| Summary: | bootstrap-prefix.sh masks LD_LIBRARY_PATH | ||
|---|---|---|---|
| Product: | Gentoo/Alt | Reporter: | Martin Mokrejš <mmokrejs> |
| Component: | Other | Assignee: | Gentoo non-Linux Team <alt> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | bash -x bootstrap-prefix.sh | ||
|
Description
Martin Mokrejš
2018-03-12 13:17:42 UTC
Created attachment 523558 [details] bash -x bootstrap-prefix.sh On line 139 it shows the script still bother about system-wide bash, installed in /bin/bash. 139 ++ env -i HOME=/home/mmokrejs /bin/bash -l I explicitly compiled bash-4.4 in my $HOME/bash-4.4 and pointed PATH to it, before calling bootstrap-prefix.sh . Therefore, this is a bug IMO. Anyway, the LD_LIBRARY_PATH was cleared in bootstrap-prefix.sh so I am not surprised of the error. $ echo $LD_LIBRARY_PATH /apps/all/Bash/4.4-intel-2017b/lib:/apps/all/libreadline/7.0/lib:/apps/all/ncurses/6.0/lib:/apps/all/imkl/2017.4.239-iimpi-2017b/mkl/lib/intel64:/apps/all/imkl/2017.4.239-iimpi-2017b/lib/intel64:/apps/all/impi/2017.4.239-iccifort-2017.5.239-GCC-6.3.0-2.27/lib64:/apps/all/ifort/2017.5.239-GCC-6.3.0-2.27/compilers_and_libraries_2017.5.239/linux/compiler/lib/intel64:/apps/all/icc/2017.5.239-GCC-6.3.0-2.27/compilers_and_libraries_2017.5.239/linux/compiler/lib/intel64:/apps/all/binutils/2.27-GCCcore-6.3.0/lib:/apps/all/GCCcore/6.3.0/lib/gcc/x86_64-pc-linux-gnu/6.3.0:/apps/all/GCCcore/6.3.0/lib64:/apps/all/GCCcore/6.3.0/lib:/apps/all/Lua/5.1.4-8/lib $ I suggest emptying LD_LIBRARY_PATH as long as bash can be executed succesfully. Or, fix https://wiki.gentoo.org/wiki/Project:Prefix and make it clear I am supposed to prepare a static binary. Finally, make it clear if/whether modules are supported or not. Seems not. I think we should lift the ban for <bash-4.2 in stage1, because we build bash there. Then we don't need these cludgy workarounds. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=bdb73088dff33872b9f18a81fcc353aacab2e4c2 commit bdb73088dff33872b9f18a81fcc353aacab2e4c2 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2018-03-13 08:11:31 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2018-03-13 08:11:31 +0000 scripts/bootstrap-prefix: lift restriction on bash-4.2 Allow older bash (like 2.59 or 3.00) to be used in chost, interactive, stage1, since the latter builds bash in such a way that stage2 and 3 can use more advanced features. Bug: https://bugs.gentoo.org/650278 Bug: https://bugs.gentoo.org/650284 scripts/bootstrap-prefix.sh | 36 ++++++++++++++++++++---------------- 1 file changed, 20 insertions(+), 16 deletions(-)} @heroxbd: if we would launch bash --norc --noprofile for stage1 here, we'd still have this fail, as we wipe out LD_LIBRARY_PATH, which is the reason I decided to keep running in the existing interpreter. (In reply to Martin Mokrejš from comment #1) > Created attachment 523558 [details] > bash -x bootstrap-prefix.sh > > On line 139 it shows the script still bother about system-wide bash, > installed in /bin/bash. > > 139 ++ env -i HOME=/home/mmokrejs /bin/bash -l That's probably an expansion from env -i HOME=$HOME $SHELL -l In other words, we can't tell, can we? Your SHELL var doesn't point to the shell you're using for some reason. > I explicitly compiled bash-4.4 in my $HOME/bash-4.4 and pointed PATH to it, > before calling bootstrap-prefix.sh . Therefore, this is a bug IMO. No. your shell need not to be in PATH, SHELL should point to it though. > Finally, make it clear if/whether modules are supported or not. Seems not. I'm not really familiar with modules. In what way do they conflict with the bootstrap? If we can compile bash from source, with our settings to make it read from the offset location, we should be safe as we no longer rely on any behaviour from host, no? (In reply to Fabian Groffen from comment #4) > @heroxbd: if we would launch bash --norc --noprofile for stage1 here, we'd > still have this fail, as we wipe out LD_LIBRARY_PATH, which is the reason I > decided to keep running in the existing interpreter. Okay, I see your point. > (In reply to Martin Mokrejš from comment #1) > > Created attachment 523558 [details] > > bash -x bootstrap-prefix.sh > > > > On line 139 it shows the script still bother about system-wide bash, > > installed in /bin/bash. > > > > 139 ++ env -i HOME=/home/mmokrejs /bin/bash -l > > That's probably an expansion from > > env -i HOME=$HOME $SHELL -l > > In other words, we can't tell, can we? Your SHELL var doesn't point to the > shell you're using for some reason. > > > I explicitly compiled bash-4.4 in my $HOME/bash-4.4 and pointed PATH to it, > > before calling bootstrap-prefix.sh . Therefore, this is a bug IMO. > > No. your shell need not to be in PATH, SHELL should point to it though. > > > Finally, make it clear if/whether modules are supported or not. Seems not. > I'm not really familiar with modules. In what way do they conflict with the > bootstrap? If we can compile bash from source, with our settings to make it > read from the offset location, we should be safe as we no longer rely on any > behaviour from host, no? Modules is a fancy way to manage a load of environment variable, in the niche of academia. If we rely on our own bash, we are safe. (In reply to Fabian Groffen from comment #4) > @heroxbd: if we would launch bash --norc --noprofile for stage1 here, we'd > still have this fail, as we wipe out LD_LIBRARY_PATH, which is the reason I > decided to keep running in the existing interpreter. > > (In reply to Martin Mokrejš from comment #1) > > Created attachment 523558 [details] > > bash -x bootstrap-prefix.sh > > > > On line 139 it shows the script still bother about system-wide bash, > > installed in /bin/bash. > > > > 139 ++ env -i HOME=/home/mmokrejs /bin/bash -l > > That's probably an expansion from > > env -i HOME=$HOME $SHELL -l > > In other words, we can't tell, can we? Your SHELL var doesn't point to the > shell you're using for some reason. The parent OS I used to call bootstrapprefix.sh says: $ echo $SHELL /bin/bash $ grep -H SHELL /etc/bashrc /etc/profile .bashrc .bash_profile $ There is one match but I assume irrelevant: /etc/crontab:SHELL=/bin/bash Isn't my SHELL inherited from /etc/passwd and in my case called by sshd during login? > > I explicitly compiled bash-4.4 in my $HOME/bash-4.4 and pointed PATH to it, > > before calling bootstrap-prefix.sh . Therefore, this is a bug IMO. > > No. your shell need not to be in PATH, SHELL should point to it though. Interesting, I could try override the SHELL with HOME/bash-4.4/bash . I gave it a try with this version: $ ls -latr bootstrap-prefix.sh -rwxr-xr-x 1 mmokrejs mmokrejs 89699 Mar 12 12:00 bootstrap-prefix.sh $ $ bootstrap-prefix.sh --version !!! This script requires GNU bash 4.2 or newer to run. !!! You are using /bin/bash which is 4.1.2(2)-release !!! If you don't have a newer one, please bootstrap bash 4.2 first: !!! https://wiki.gentoo.org/wiki/Project:Prefix/Bootstrap !!! You can prepend a better bash's location to your PATH, or call !!! this script with the alternative bash like so: !!! /path/to/bash-4.2 bootstrap-prefix.sh $ $ sha1sum bootstrap-prefix.sh 787395f75da4a2223fcc0a932ab035ead9193377 bootstrap-prefix.sh $ $ export PREFIX=/var/tmp/mmokrejs $ export SHELL=$HOME/bash-4.4/bash $ bash bootstrap-prefix.sh /var/tmp/mmokrejs !!! This script requires GNU bash 4.2 or newer to run. !!! You are using /bin/bash which is 4.1.2(2)-release !!! If you don't have a newer one, please bootstrap bash 4.2 first: !!! https://wiki.gentoo.org/wiki/Project:Prefix/Bootstrap !!! You can prepend a better bash's location to your PATH, or call !!! this script with the alternative bash like so: !!! /path/to/bash-4.2 bootstrap-prefix.sh $ $ $SHELL bootstrap-prefix.sh . .vir. d$b .d$$$$$$b. .cd$$b. .d$$b. d$$$$$$$$$$$b .d$$b. .d$$b. $$$$( )$$$b d$$$()$$$. d$$$$$$$b Q$$$$$$$P$$$P.$$$$$$$b. .$$$$$$$b. Q$$$$$$$$$$B$$$$$$$$P" d$$$PQ$$$$b. $$$$. .$$$P' `$$$ .$$$P' `$$$ "$$$$$$$P Q$$$$$$$b d$$$P Q$$$$b $$$$b $$$$b..d$$$ $$$$b..d$$$ d$$$$$$P" "$$$$$$$$ Q$$$ Q$$$$ $$$$$ `Q$$$$$$$P `Q$$$$$$$P $$$$$$$P `""""" "" "" Q$$$P "Q$$$P" "Q$$$P" `Q$$P" """ Welcome to the Gentoo Prefix interactive installer! ... During emerging bash I saw the "usual" errors caused by our system-wide calls of LMOD stuff from /etc/profile. Well, this bug was about bootstrap-prefix.sh messing up with LD_LIBRARY_PATH and possibly other variables needed to get the bash running, nevertheless I tried to bootstrap using the a bit outdated script but current portage. I failed, see bug #651036 . > > > Finally, make it clear if/whether modules are supported or not. Seems not. > > I'm not really familiar with modules. In what way do they conflict with the > bootstrap? If we can compile bash from source, with our settings to make it > read from the offset location, we should be safe as we no longer rely on any > behaviour from host, no? They alter PATH and LD_LIBRARY_PATH, maybe more. I bootstrap zaps the contents of those variables the say bash provided in a special PATH by modules will stop working if the LD_LIBRARY_PATH is mangled. There is also lmod software, but that is probably not any different in this regard. It is a package manaement system, allowing you to import different namespaces (for example to switch between various versions of applications and the system automatically imports needed dependencies). In this regard, you do not have issues with non-FHS paths, file collisions, etc. The tools are just installed in their own, separate directories. Using modules/lmod typically a lot of software (with many versions) are deployed in cluster environments. (In reply to Martin Mokrejš from comment #6) > > $ export PREFIX=/var/tmp/mmokrejs > $ export SHELL=$HOME/bash-4.4/bash > $ bash bootstrap-prefix.sh /var/tmp/mmokrejs > !!! This script requires GNU bash 4.2 or newer to run. Which bash is used in your PATH? Do a which -a bash before `bash bootstrap-prefix.sh /var/tmp/mmokrejs`. |
