Greetings, I hope this is relevant and not besides the point, but I was thinking that you may be able to use proot to bind mount your shell to /bin/sh without root privileges:
https://proot-me.github.io/ Hopefully this would also be useful in other situations where the SHELL environment variable is not used. Regards, George On 5/3/24 06:37, Mohammad Akhlaghi wrote: >> But you still doesn't show us an *exact* recipe or log files that >> demonstrates the problem you encounter. > > Below you can see the error: (the Readline library that '/bin/sh' needed > was more recent than our custom Readline installation; so '/bin/sh' > could not find the function it needed within our closed environment) > > /bin/sh: symbol lookup error: /bin/sh: undefined symbol: > rl_trim_arg_from_keyseq > > In our general build system for GNU-based builds (including FreeType), > we have an 'export SHELL=/path/to/custom/bash' just before calling the > './configure' script; and they would all take the 'SHELL' environment > into account during the build; so the error above didn't happen for > them. But in FreeType, we noticed that the only way we could ask it to > use our custom shell was through the 'GNUMAKE' variable. > > It would be great if the configure script can let the user specify the > shell to be used for the build in the standard way (through the 'SHELL' > environment variable). > >> Reproducibility is not equal to determinism. > > All terms and goals are precisely defined in the paper (here is the > arXiv link of the paper with no non-free Javascript): > https://arxiv.org/abs/2006.03018 > >> I dare say your problem does not happen to thousands of Arch Linux >> users who try to compile freetype. > > This problem would happen to anyone who used older versions of > https://maneage.org/. It is independent of the operating system (we build > FreeType at a time that the Maneage environment is fully closed-off from > the host). > >> you are aware that GNU Bash itself behaves differently, depending >> on what you call the binary, right? > > Thanks for the reminder on this ;-). But that is not the problem because > as mentioned before '/bin/sh' fails to link/execute at all (see error > message that is quoted above). > >> You are basically trying to do what another project "Linux from >> Scratch", tried to do 10+ years ago > > We did indeed get a lot of help from the wonderful documentation of > Linux From Scratch for the very low-level tools (we also build GCC and > GNU Binutils for example). But I would say it that Maneage is more > similar to Gentoo or GNU Guix, since it executes the scripts to build > the custom software from source automatically: no manual intervention is > necessary. Its core difference with Gentoo or GNU Guix is that it > doesn't build the Kernel and does not need root permission. This is > fully described in the paper: > https://arxiv.org/abs/2006.03018 > >> randomly changing LD_LIBRARY_PATH and other environment variables > > Nothing is random in the changes we make! > >> ... a lot of requests to the community of the form of: "I want to >> build your software my funny way, why doesn't it work?" > > My original comment was not saying this! I found the fix with a > non-standard way and there is no more problem on the Maneage side. The > reason I contacted you was that the standard solution (to set the > 'SHELL' environment variable) worked on +100 other software, it was only > FreeType and two or three other packages that need some non-standard fix. > >> The typical Linux system has thousands of packages... (last I >> count, 9000+ on fedora). Have fun going through the rest.. > > Maneage is not meant to be a full operating system! Only a closed > environment for batch (non-interactive and non-GUI) scientific > operations. Here are the current list of software that we build: > > https://git.maneage.org/project.git/tree/reproduce/software/config/versions.conf > > Cheers, > Mohammad > > >
