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
