Re: Accounting for SHELL in ./configure

[Mohammad Akhlaghi]

> 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