Re: Accounting for SHELL in ./configure

[Matsumura, George]

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
> 
> 
>