Re: Accounting for SHELL in ./configure
bind mount (and anything invoking mount) requires root privilege, except for fusemount and some removable medium use cases - even that is often disabled based on site policy. Using proot-me seems to be no better than the original poster's - depending on a peculiar way of doing things maintained by a small set of individuals... The sort of thing that the initial poster tries to do, is to use a combination of docker / CI on github and other free-hosting dev platform with docker CI runners, or something like that. https://github.com/actions/runner-images I personally use docker against the ubuntu runner to grab a fefora linux docker image, and build fedora stuff there inside a fedora container running on a ubuntu host: https://github.com/HinTak/Qt6WE-OT-SVG/blob/10937a258aa3bd90533f4b9d6f67b0c61ca435e4/.github/workflows/ci.yml#L14 And here is arch linux's: https://github.com/archlinux/archlinux-docker And please stop posting links on the academic papers and promoting your papers. Not interested... On Friday, 3 May 2024 at 18:38:53 BST, Matsumura, George wrote: 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: > >
Re: Accounting for SHELL in ./configure
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 > > >
Re: Accounting for SHELL in ./configure
>> 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 Thanks, but *this* was clear :-) I want to see the error messages you've encountered together with the corresponding command-line input while trying to use your standard work-around. Werner
Re: Accounting for SHELL in ./configure
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
Re: Accounting for SHELL in ./configure
>> Please describe your setup carefully before jumping to quick >> solutions. > > The problem occurred on an Arch GNU/Linux, and the '/bin/sh > --version' is GNU Bash 5.2.26 and I installed FreeType 2.11.0. After > checking the Git repository and noticing that my particular problem > occurred there also, I linked the Git repository instead of the > details of the tarball I downloaded. But you are right, I should > have given more details on the circumstances; sorry about that. But you still doesn't show us an *exact* recipe or log files that demonstrates the problem you encounter. It's always hard to discuss things on such a theoretical level without have an example to test. Your suggested fix of doing ``` CFG=$CFG SHELL=$SHELL $MAKE setup unix ``` (if I understand you correctly) in the top-level `configure` script is trivial, and I'm certainly not opposed to apply that. However, we would like to really understand the big picture. Werner
Re: Accounting for SHELL in ./configure
I dare say your problem does not happen to thousands of Arch Linux users who try to compile freetype. One thing on the security aspect of sh and GNU Bash - you are aware that GNU Bash itself behaves differently, depending on what you call the binary, right? If you build GNU Bash yourself, then rename the binary from "bash" to "mybash" or some random thing, "mysh" or "myhackshell", it works differently? It is by design - it detects what it is called as, and behaves differently: dropping GNU extension behavior and behaves more like pure non-GNU sh if you rename the binary, to emulate the older/stricter/more-limited shell. You are basically trying to do what another project "Linux from Scratch", tried to do 10+ years ago - randomly changing LD_LIBRARY_PATH and other environment variables that the compiler and other part of the build machinery needs, in the hope of "reproducing builds". Mostly it is 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?" The typical Linux system has thousands of packages... (last I count, 9000+ on fedora). Have fun going through the rest... On Friday, 3 May 2024 at 00:11:41 BST, Mohammad Akhlaghi wrote: Thanks Hin-Tak, I will be updating the version of FreeType shortly, this was for an older project. The main purpose of going through all this trouble is long-term reproducibility of our scientific publications/results. Unfortunately that is something most operating system package managers ignore. I have published a paper on it in IEEE's Computing in Science and Engineering journal: https://doi.org/10.1109/MCSE.2021.3072860 This problem didn't happen for +100 other packages; and we are trying our best to follow POSIX/Unix standards and it has been successful so far ;-). Cheers, Mohammad On 5/3/24 12:33 AM, Hin-Tak Leung wrote: > Hmm, why are you trying to compile an older version of freetype (2.11.x), >when arch linux ships 2.13.x ? > Anyway, here is how the Arch Linux people build freetype - they use meson > instead of autoconf (PKGBUILD itself is largely a shell script with, divided > into shell script routines): > https://gitlab.archlinux.org/archlinux/packaging/packages/freetype2/-/blob/main/PKGBUILD?ref_type=heads > > PKGBUILD itself is a somewhat old package building system from BSD. > If you play with LD_LIBRARY_PATH, you are on your own... you are digging a > hole for yourself playing with that, and the hole is just deeper and deeper. > Mostly I would follow my Linux's system packaging system on how libraries are > built (so that my built result different only by my intended changes from > what's shipped by the linux distro). In your case, i would probably try to > adapt the above PKGBUILD script if i were you. > That said, i think your problem is self-inflicted - you do one thing you > shouldn't, found that it broke, and instead of just stop and revert, you do a > few more things you shouldn't and break a few more things, then do a few more > bad things, then you try to ask, why it doesn't work... > /bin/sh is hardcoded on many scripts and doesn't allow overrides, as it is a > security issue . You just should not go down the path of building bash > yourself. (And freetype's autoconf build system should have just worked > flawlessly). > > On Thursday, 2 May 2024 at 15:16:39 BST, Mohammad Akhlaghi > wrote: > > Dear Alexei, Werner and Hin-Tak, > > Thank you for the comments; I appreciate the prompt replies :-). > >> There is this peculiar autogen.sh to be run initially... Still fails? How? > > I had indeed read the README, but it had only instructed using > 'autogen.sh' when "... building a git snapshot or checkout, *not* if you > grabbed the sources of an official release." > > Since I had got the tarball as an official release (not from a Git > snapshot), I followed the instructions and ignored this step. > >> Please describe your setup carefully before jumping to quick solutions. > > The problem occurred on an Arch GNU/Linux, and the '/bin/sh --version' > is GNU Bash 5.2.26 and I installed FreeType 2.11.0. After checking the > Git repository and noticing that my particular problem occurred there > also, I linked the Git repository instead of the details of the tarball > I downloaded. But you are right, I should have given more details on the > circumstances; sorry about that. > >> ... nor have you shown any output of the failure. And what do you >> mean with a 'faulty shell', mentioned in a previous e-mail? > > The libraries in '/usr/lib' have conflicts with some of my other > software, so I have replaced that with my custom environment in > 'LD_LIBRARY_PATH'. However, '/bin/sh' needs to link with the readline > library in '/usr/lib' to run. As a result, any time '/bin/sh' is run, it > will fail with a linking error. > > Because of this, I need to set the 'SHELL' environment variable so the > programs do not build with '/bin/sh', but
Re: Accounting for SHELL in ./configure
> > The main purpose of going through all this trouble is long-term > reproducibility of our scientific publications/results. Reproducibility is not equal to determinism.
Re: Accounting for SHELL in ./configure
Thanks Hin-Tak, I will be updating the version of FreeType shortly, this was for an older project. The main purpose of going through all this trouble is long-term reproducibility of our scientific publications/results. Unfortunately that is something most operating system package managers ignore. I have published a paper on it in IEEE's Computing in Science and Engineering journal: https://doi.org/10.1109/MCSE.2021.3072860 This problem didn't happen for +100 other packages; and we are trying our best to follow POSIX/Unix standards and it has been successful so far ;-). Cheers, Mohammad On 5/3/24 12:33 AM, Hin-Tak Leung wrote: Hmm, why are you trying to compile an older version of freetype (2.11.x), when arch linux ships 2.13.x ? Anyway, here is how the Arch Linux people build freetype - they use meson instead of autoconf (PKGBUILD itself is largely a shell script with, divided into shell script routines): https://gitlab.archlinux.org/archlinux/packaging/packages/freetype2/-/blob/main/PKGBUILD?ref_type=heads PKGBUILD itself is a somewhat old package building system from BSD. If you play with LD_LIBRARY_PATH, you are on your own... you are digging a hole for yourself playing with that, and the hole is just deeper and deeper. Mostly I would follow my Linux's system packaging system on how libraries are built (so that my built result different only by my intended changes from what's shipped by the linux distro). In your case, i would probably try to adapt the above PKGBUILD script if i were you. That said, i think your problem is self-inflicted - you do one thing you shouldn't, found that it broke, and instead of just stop and revert, you do a few more things you shouldn't and break a few more things, then do a few more bad things, then you try to ask, why it doesn't work... /bin/sh is hardcoded on many scripts and doesn't allow overrides, as it is a security issue . You just should not go down the path of building bash yourself. (And freetype's autoconf build system should have just worked flawlessly). On Thursday, 2 May 2024 at 15:16:39 BST, Mohammad Akhlaghi wrote: Dear Alexei, Werner and Hin-Tak, Thank you for the comments; I appreciate the prompt replies :-). There is this peculiar autogen.sh to be run initially... Still fails? How? I had indeed read the README, but it had only instructed using 'autogen.sh' when "... building a git snapshot or checkout, *not* if you grabbed the sources of an official release." Since I had got the tarball as an official release (not from a Git snapshot), I followed the instructions and ignored this step. Please describe your setup carefully before jumping to quick solutions. The problem occurred on an Arch GNU/Linux, and the '/bin/sh --version' is GNU Bash 5.2.26 and I installed FreeType 2.11.0. After checking the Git repository and noticing that my particular problem occurred there also, I linked the Git repository instead of the details of the tarball I downloaded. But you are right, I should have given more details on the circumstances; sorry about that. ... nor have you shown any output of the failure. And what do you mean with a 'faulty shell', mentioned in a previous e-mail? The libraries in '/usr/lib' have conflicts with some of my other software, so I have replaced that with my custom environment in 'LD_LIBRARY_PATH'. However, '/bin/sh' needs to link with the readline library in '/usr/lib' to run. As a result, any time '/bin/sh' is run, it will fail with a linking error. Because of this, I need to set the 'SHELL' environment variable so the programs do not build with '/bin/sh', but use my custom shell (that I have also built from source in my custom directory: I do not have root permissions on this computer). To avoid hard-coded statements like '#!/bin/sh', before './configure'-ing the source codes, I first run a 'sed' and replace it with my custom shell. This process has worked on +100 of software packages that I am building from source for my project (which uses https://maneage.org). Only a handful of packages needed some special tweaking/hacks like this one with GNUMAKE in FreeType. I am very sorry again for not being too clear in my first comment and thanks again for the prompt replies :-). Cheers, Mohammad
Re: Accounting for SHELL in ./configure
Hmm, why are you trying to compile an older version of freetype (2.11.x), when arch linux ships 2.13.x ? Anyway, here is how the Arch Linux people build freetype - they use meson instead of autoconf (PKGBUILD itself is largely a shell script with, divided into shell script routines): https://gitlab.archlinux.org/archlinux/packaging/packages/freetype2/-/blob/main/PKGBUILD?ref_type=heads PKGBUILD itself is a somewhat old package building system from BSD. If you play with LD_LIBRARY_PATH, you are on your own... you are digging a hole for yourself playing with that, and the hole is just deeper and deeper. Mostly I would follow my Linux's system packaging system on how libraries are built (so that my built result different only by my intended changes from what's shipped by the linux distro). In your case, i would probably try to adapt the above PKGBUILD script if i were you. That said, i think your problem is self-inflicted - you do one thing you shouldn't, found that it broke, and instead of just stop and revert, you do a few more things you shouldn't and break a few more things, then do a few more bad things, then you try to ask, why it doesn't work... /bin/sh is hardcoded on many scripts and doesn't allow overrides, as it is a security issue . You just should not go down the path of building bash yourself. (And freetype's autoconf build system should have just worked flawlessly). On Thursday, 2 May 2024 at 15:16:39 BST, Mohammad Akhlaghi wrote: Dear Alexei, Werner and Hin-Tak, Thank you for the comments; I appreciate the prompt replies :-). > There is this peculiar autogen.sh to be run initially... Still fails? How? I had indeed read the README, but it had only instructed using 'autogen.sh' when "... building a git snapshot or checkout, *not* if you grabbed the sources of an official release." Since I had got the tarball as an official release (not from a Git snapshot), I followed the instructions and ignored this step. > Please describe your setup carefully before jumping to quick solutions. The problem occurred on an Arch GNU/Linux, and the '/bin/sh --version' is GNU Bash 5.2.26 and I installed FreeType 2.11.0. After checking the Git repository and noticing that my particular problem occurred there also, I linked the Git repository instead of the details of the tarball I downloaded. But you are right, I should have given more details on the circumstances; sorry about that. > ... nor have you shown any output of the failure. And what do you > mean with a 'faulty shell', mentioned in a previous e-mail? The libraries in '/usr/lib' have conflicts with some of my other software, so I have replaced that with my custom environment in 'LD_LIBRARY_PATH'. However, '/bin/sh' needs to link with the readline library in '/usr/lib' to run. As a result, any time '/bin/sh' is run, it will fail with a linking error. Because of this, I need to set the 'SHELL' environment variable so the programs do not build with '/bin/sh', but use my custom shell (that I have also built from source in my custom directory: I do not have root permissions on this computer). To avoid hard-coded statements like '#!/bin/sh', before './configure'-ing the source codes, I first run a 'sed' and replace it with my custom shell. This process has worked on +100 of software packages that I am building from source for my project (which uses https://maneage.org). Only a handful of packages needed some special tweaking/hacks like this one with GNUMAKE in FreeType. I am very sorry again for not being too clear in my first comment and thanks again for the prompt replies :-). Cheers, Mohammad
Re: Accounting for SHELL in ./configure
Dear Alexei, Werner and Hin-Tak, Thank you for the comments; I appreciate the prompt replies :-). There is this peculiar autogen.sh to be run initially... Still fails? How? I had indeed read the README, but it had only instructed using 'autogen.sh' when "... building a git snapshot or checkout, *not* if you grabbed the sources of an official release." Since I had got the tarball as an official release (not from a Git snapshot), I followed the instructions and ignored this step. Please describe your setup carefully before jumping to quick solutions. The problem occurred on an Arch GNU/Linux, and the '/bin/sh --version' is GNU Bash 5.2.26 and I installed FreeType 2.11.0. After checking the Git repository and noticing that my particular problem occurred there also, I linked the Git repository instead of the details of the tarball I downloaded. But you are right, I should have given more details on the circumstances; sorry about that. ... nor have you shown any output of the failure. And what do you mean with a 'faulty shell', mentioned in a previous e-mail? The libraries in '/usr/lib' have conflicts with some of my other software, so I have replaced that with my custom environment in 'LD_LIBRARY_PATH'. However, '/bin/sh' needs to link with the readline library in '/usr/lib' to run. As a result, any time '/bin/sh' is run, it will fail with a linking error. Because of this, I need to set the 'SHELL' environment variable so the programs do not build with '/bin/sh', but use my custom shell (that I have also built from source in my custom directory: I do not have root permissions on this computer). To avoid hard-coded statements like '#!/bin/sh', before './configure'-ing the source codes, I first run a 'sed' and replace it with my custom shell. This process has worked on +100 of software packages that I am building from source for my project (which uses https://maneage.org). Only a handful of packages needed some special tweaking/hacks like this one with GNUMAKE in FreeType. I am very sorry again for not being too clear in my first comment and thanks again for the prompt replies :-). Cheers, Mohammad
Re: Accounting for SHELL in ./configure
Besides what Werner said - name your system. Most of the world has converged on GNU bash, but Ubuntu/Debian uses dash, some older Solaris used ksh. Some really old unix system (tru64 came to mind) has genuine BSD sh. You wrote about lacking the privilege to be root, so I guess you are not using busybox. And I think FreeType can be built on the bare compiler command line without any build system, something like cc -o libfreetype.a -I./include -I... -I... */*/*.c If you set the includes and the file list (some files are not used in some platforms) right. On Thursday, 2 May 2024 at 03:49:03 BST, Werner LEMBERG wrote: Exactly. Mohammad, you have neither named your shell...
Re: Accounting for SHELL in ./configure
>> >> Do you mean here? >> >> https://gitlab.freedesktop.org/freetype/freetype/-/tree/master/builds/unix >> ... > > Please start at README and README.git or here: > https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/docs/INSTALL.UNIX > > There is this peculiar autogen.sh to be run initially... Still > fails? How? > > FreeType is successfully and routinely built on a wide variety of > platforms even without autotools. Please describe your setup > carefully before jumping to quick solutions. Exactly. Mohammad, you have neither named your shell, nor the FreeType version you use, nor have you shown any output of the failure. And what do you mean with a 'faulty shell', mentioned in a previous e-mail? We need a log file output and such things! Maybe some non-`sh` features have crept into the top-level `configure` script that can be easily fixed (though I'm not aware of any). Werner
Re: Accounting for SHELL in ./configure
On Wed, May 1, 2024 at 7:11 PM Mohammad Akhlaghi wrote: > > Do you mean here? > > https://gitlab.freedesktop.org/freetype/freetype/-/tree/master/builds/unix > ... Please start at README and README.git or here: https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/docs/INSTALL.UNIX There is this peculiar autogen.sh to be run initially... Still fails? How? FreeType is successfully and routinely built on a wide variety of platforms even without autotools. Please describe your setup carefully before jumping to quick solutions. Perhaps we can help. Alexei
Re: Accounting for SHELL in ./configure
Do you mean here? https://gitlab.freedesktop.org/freetype/freetype/-/tree/master/builds/unix There is only 'configure.raw' there; its contents are indeed Autoconf, but its name is non-standard, that is probably why I missed it ;-). The main point is that the 'configure' script at the top source directory is not generated by Autoconf; for someone who uses this './configure' script, it would help to put 'SHELL=$SHELL' after the '$MAKE' at the end. My problem was solved with the GNUMAKE hack; this is only as a suggestion/feedback to help future users who need to a custom shell. Thanks again for the prompt replies and for all the work on this important package :-). Cheers, Mohammad On 5/2/24 12:46 AM, Behdad Esfahbod wrote: I know all that. :) Check out builds/unix/configure.ac behdad http://behdad.org/ On Wed, May 1, 2024 at 4:40 PM Mohammad Akhlaghi wrote: I had set the 'SHELL' environment variable but still '/bin/sh' was used. The only way I could pass my SHELL to the Make command within the configure script was through the non-standard hack I mentioned before: GNUMAKE="make SHELL=$SHELL" Autoconf generates the './configure' script automatically though a 'configure.ac' file. But I don't see any 'configure.ac' in FreeType's source. For example here is the source code of a project that I maintain which uses Autoconf: https://git.savannah.gnu.org/cgit/gnuastro.git/tree The './configure' script is generated automatically from 'configure.ac' when building the tarball (since the configure script is automatically generated, we don't keep it under version control). Cheers, Mohammad On 5/1/24 11:17 PM, Behdad Esfahbod wrote: Scratch that. Where is it exactly failing? On Unix, the build system is essentially autoconf, so it should respect SHELL as you suggest. behdad http://behdad.org/ On Wed, May 1, 2024 at 3:15 PM Behdad Esfahbod wrote: Can you check if also setting CONFIG_SHELL helps? behdad http://behdad.org/ On Wed, May 1, 2024 at 3:06 PM Mohammad Akhlaghi wrote: The Autoconf-generated configure script, or even CMake, respect SHELL, so if a user gives it a problematic shell, they won't be able to build anything abd many programs will crash. But please consider the scenario mentioned before: when a user doesn't have root permissions to change '/bin/sh', they are left with non-standard hacks like what I did. When each program's build system respects 'SHELL', the user is free to use any shell they want with any program's build. Cheers, Mohammad On May 1, 2024 10:55:05 PM GMT+02:00, Behdad Esfahbod < beh...@behdad.org> wrote: I'm not talking about the user overriding the shell specifically. I'm talking about users who genuinely use a non-POSIX shell as their terminal shell. Then just running ./configure would fail if configure was to respect $SHELL. Or rather you're saying that only POSIX-compatible shells should set $SHELL. behdad http://behdad.org/ On Wed, May 1, 2024 at 2:45 PM Mohammad Akhlaghi < moham...@akhlaghi.org> wrote: Thanks Behdad, The problem is that I do not have root permissions on the system with the faulty '/bin/sh': I cannot change '/bin/sh' and need to build my programs with a custom shell. If the user specifies a wrong shell (not the default '/bin/sh'), it is their own responsibility that it is POSIX-compatible. The same way that a user can give a non-GNU Make executable to the GNUMAKE variable. In short, when a user changes defaults, it is their resposibility, not the developer's. So no need to worry about that; the important thing is to give users the freedon to customize for their custom environments (as GNU Autoconf does for example; but Autoconf is not used in FreeType). Cheers, Mohammad On May 1, 2024 10:25:54 PM GMT+02:00, Behdad Esfahbod < beh...@behdad.org> wrote: There's no guarantee that the user's shell is sh-compatible. autoconf really means sh here, because that's the shell the script is written for. Just symlink your favorite shell to sh then, if it's compatible. behdad http://behdad.org/ On Wed, May 1, 2024 at 2:13 PM Mohammad Akhlaghi < moham...@akhlaghi.org> wrote: Hi again, I was able to find a cleaner hack by running this command before the './configure' script: export GNUMAKE="make SHELL=$SHELL" Afterwards, FreeType successfully ran with my desired shell. But generally, it would greatly help those building FreeType from source if the configure script accounts for the 'SHELL' environment variable. Thanks a lot for all the nice work on FreeType, Cheers, Mohammad On 5/1/24 9:00 PM, Mohammad Akhlaghi wrote: Dear Freetype developers, I was trying to build FreeType from source and noticed that the './configure' script does not account for the 'SHELL' environment and will always use '/bin/sh'. Looking at the source of the './configure' script, I was able to fix the problem by manually adding a 'SHELL=$SHELL' in line 135 of the './configure' script:
Re: Accounting for SHELL in ./configure
I know all that. :) Check out builds/unix/configure.ac behdad http://behdad.org/ On Wed, May 1, 2024 at 4:40 PM Mohammad Akhlaghi wrote: > I had set the 'SHELL' environment variable but still '/bin/sh' was used. > The only way I could pass my SHELL to the Make command within the > configure script was through the non-standard hack I mentioned before: > GNUMAKE="make SHELL=$SHELL" > > Autoconf generates the './configure' script automatically though a > 'configure.ac' file. But I don't see any 'configure.ac' in FreeType's > source. For example here is the source code of a project that I maintain > which uses Autoconf: > > https://git.savannah.gnu.org/cgit/gnuastro.git/tree > > The './configure' script is generated automatically from 'configure.ac' > when building the tarball (since the configure script is automatically > generated, we don't keep it under version control). > > Cheers, > Mohammad > > On 5/1/24 11:17 PM, Behdad Esfahbod wrote: > > Scratch that. > > > > Where is it exactly failing? On Unix, the build system is essentially > > autoconf, so it should respect SHELL as you suggest. > > > > behdad > > http://behdad.org/ > > > > > > On Wed, May 1, 2024 at 3:15 PM Behdad Esfahbod > wrote: > > > >> Can you check if also setting CONFIG_SHELL helps? > >> > >> behdad > >> http://behdad.org/ > >> > >> > >> On Wed, May 1, 2024 at 3:06 PM Mohammad Akhlaghi > > >> wrote: > >> > >>> The Autoconf-generated configure script, or even CMake, respect SHELL, > so > >>> if a user gives it a problematic shell, they won't be able to build > >>> anything abd many programs will crash. > >>> > >>> But please consider the scenario mentioned before: when a user doesn't > >>> have root permissions to change '/bin/sh', they are left with > non-standard > >>> hacks like what I did. > >>> > >>> When each program's build system respects 'SHELL', the user is free to > >>> use any shell they want with any program's build. > >>> > >>> Cheers, > >>> Mohammad > >>> > >>> > >>> > >>> > >>> On May 1, 2024 10:55:05 PM GMT+02:00, Behdad Esfahbod < > beh...@behdad.org> > >>> wrote: > >>> > I'm not talking about the user overriding the shell specifically. I'm > talking about users who genuinely use a non-POSIX shell as their > terminal > shell. Then just running ./configure would fail if configure was to > respect > $SHELL. > > Or rather you're saying that only POSIX-compatible shells should set > $SHELL. > behdad > http://behdad.org/ > > > On Wed, May 1, 2024 at 2:45 PM Mohammad Akhlaghi < > moham...@akhlaghi.org> > wrote: > > > Thanks Behdad, > > > > The problem is that I do not have root permissions on the system with > > the faulty '/bin/sh': I cannot change '/bin/sh' and need to build my > > programs with a custom shell. > > > > If the user specifies a wrong shell (not the default '/bin/sh'), it > is > > their own responsibility that it is POSIX-compatible. The same way > that a > > user can give a non-GNU Make executable to the GNUMAKE variable. > > > > In short, when a user changes defaults, it is their resposibility, > not > > the developer's. So no need to worry about that; the important thing > is to > > give users the freedon to customize for their custom environments > (as GNU > > Autoconf does for example; but Autoconf is not used in FreeType). > > > > Cheers, > > Mohammad > > > > > > > > On May 1, 2024 10:25:54 PM GMT+02:00, Behdad Esfahbod < > > beh...@behdad.org> wrote: > > > >> There's no guarantee that the user's shell is sh-compatible. > autoconf > >> really means sh here, because that's the shell the script is > written for. > >> Just symlink your favorite shell to sh then, if it's compatible. > >> > >> behdad > >> http://behdad.org/ > >> > >> > >> On Wed, May 1, 2024 at 2:13 PM Mohammad Akhlaghi < > >> moham...@akhlaghi.org> wrote: > >> > >>> Hi again, > >>> > >>> I was able to find a cleaner hack by running this command before > the > >>> './configure' script: > >>> > >>> export GNUMAKE="make SHELL=$SHELL" > >>> > >>> Afterwards, FreeType successfully ran with my desired shell. > >>> > >>> But generally, it would greatly help those building FreeType from > >>> source > >>> if the configure script accounts for the 'SHELL' environment > variable. > >>> > >>> Thanks a lot for all the nice work on FreeType, > >>> Cheers, > >>> Mohammad > >>> > >>> On 5/1/24 9:00 PM, Mohammad Akhlaghi wrote: > Dear Freetype developers, > > I was trying to build FreeType from source and noticed that the > './configure' script does not account for the 'SHELL' environment > >>> and > will always use '/bin/sh'. > > Looking at the source of the './configure' script, I was able to > >>> fix the >
Re: Accounting for SHELL in ./configure
I had set the 'SHELL' environment variable but still '/bin/sh' was used. The only way I could pass my SHELL to the Make command within the configure script was through the non-standard hack I mentioned before: GNUMAKE="make SHELL=$SHELL" Autoconf generates the './configure' script automatically though a 'configure.ac' file. But I don't see any 'configure.ac' in FreeType's source. For example here is the source code of a project that I maintain which uses Autoconf: https://git.savannah.gnu.org/cgit/gnuastro.git/tree The './configure' script is generated automatically from 'configure.ac' when building the tarball (since the configure script is automatically generated, we don't keep it under version control). Cheers, Mohammad On 5/1/24 11:17 PM, Behdad Esfahbod wrote: Scratch that. Where is it exactly failing? On Unix, the build system is essentially autoconf, so it should respect SHELL as you suggest. behdad http://behdad.org/ On Wed, May 1, 2024 at 3:15 PM Behdad Esfahbod wrote: Can you check if also setting CONFIG_SHELL helps? behdad http://behdad.org/ On Wed, May 1, 2024 at 3:06 PM Mohammad Akhlaghi wrote: The Autoconf-generated configure script, or even CMake, respect SHELL, so if a user gives it a problematic shell, they won't be able to build anything abd many programs will crash. But please consider the scenario mentioned before: when a user doesn't have root permissions to change '/bin/sh', they are left with non-standard hacks like what I did. When each program's build system respects 'SHELL', the user is free to use any shell they want with any program's build. Cheers, Mohammad On May 1, 2024 10:55:05 PM GMT+02:00, Behdad Esfahbod wrote: I'm not talking about the user overriding the shell specifically. I'm talking about users who genuinely use a non-POSIX shell as their terminal shell. Then just running ./configure would fail if configure was to respect $SHELL. Or rather you're saying that only POSIX-compatible shells should set $SHELL. behdad http://behdad.org/ On Wed, May 1, 2024 at 2:45 PM Mohammad Akhlaghi wrote: Thanks Behdad, The problem is that I do not have root permissions on the system with the faulty '/bin/sh': I cannot change '/bin/sh' and need to build my programs with a custom shell. If the user specifies a wrong shell (not the default '/bin/sh'), it is their own responsibility that it is POSIX-compatible. The same way that a user can give a non-GNU Make executable to the GNUMAKE variable. In short, when a user changes defaults, it is their resposibility, not the developer's. So no need to worry about that; the important thing is to give users the freedon to customize for their custom environments (as GNU Autoconf does for example; but Autoconf is not used in FreeType). Cheers, Mohammad On May 1, 2024 10:25:54 PM GMT+02:00, Behdad Esfahbod < beh...@behdad.org> wrote: There's no guarantee that the user's shell is sh-compatible. autoconf really means sh here, because that's the shell the script is written for. Just symlink your favorite shell to sh then, if it's compatible. behdad http://behdad.org/ On Wed, May 1, 2024 at 2:13 PM Mohammad Akhlaghi < moham...@akhlaghi.org> wrote: Hi again, I was able to find a cleaner hack by running this command before the './configure' script: export GNUMAKE="make SHELL=$SHELL" Afterwards, FreeType successfully ran with my desired shell. But generally, it would greatly help those building FreeType from source if the configure script accounts for the 'SHELL' environment variable. Thanks a lot for all the nice work on FreeType, Cheers, Mohammad On 5/1/24 9:00 PM, Mohammad Akhlaghi wrote: Dear Freetype developers, I was trying to build FreeType from source and noticed that the './configure' script does not account for the 'SHELL' environment and will always use '/bin/sh'. Looking at the source of the './configure' script, I was able to fix the problem by manually adding a 'SHELL=$SHELL' in line 135 of the './configure' script: https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/configure?ref_type=heads#L135 Accounting for the user's given SHELL is common in many programs when building from source, so it would be good if you could account for it in future versions of FreeType also. Cheers, Mohammad
Re: Accounting for SHELL in ./configure
Scratch that. Where is it exactly failing? On Unix, the build system is essentially autoconf, so it should respect SHELL as you suggest. behdad http://behdad.org/ On Wed, May 1, 2024 at 3:15 PM Behdad Esfahbod wrote: > Can you check if also setting CONFIG_SHELL helps? > > behdad > http://behdad.org/ > > > On Wed, May 1, 2024 at 3:06 PM Mohammad Akhlaghi > wrote: > >> The Autoconf-generated configure script, or even CMake, respect SHELL, so >> if a user gives it a problematic shell, they won't be able to build >> anything abd many programs will crash. >> >> But please consider the scenario mentioned before: when a user doesn't >> have root permissions to change '/bin/sh', they are left with non-standard >> hacks like what I did. >> >> When each program's build system respects 'SHELL', the user is free to >> use any shell they want with any program's build. >> >> Cheers, >> Mohammad >> >> >> >> >> On May 1, 2024 10:55:05 PM GMT+02:00, Behdad Esfahbod >> wrote: >> >>> I'm not talking about the user overriding the shell specifically. I'm >>> talking about users who genuinely use a non-POSIX shell as their terminal >>> shell. Then just running ./configure would fail if configure was to respect >>> $SHELL. >>> >>> Or rather you're saying that only POSIX-compatible shells should set >>> $SHELL. >>> behdad >>> http://behdad.org/ >>> >>> >>> On Wed, May 1, 2024 at 2:45 PM Mohammad Akhlaghi >>> wrote: >>> Thanks Behdad, The problem is that I do not have root permissions on the system with the faulty '/bin/sh': I cannot change '/bin/sh' and need to build my programs with a custom shell. If the user specifies a wrong shell (not the default '/bin/sh'), it is their own responsibility that it is POSIX-compatible. The same way that a user can give a non-GNU Make executable to the GNUMAKE variable. In short, when a user changes defaults, it is their resposibility, not the developer's. So no need to worry about that; the important thing is to give users the freedon to customize for their custom environments (as GNU Autoconf does for example; but Autoconf is not used in FreeType). Cheers, Mohammad On May 1, 2024 10:25:54 PM GMT+02:00, Behdad Esfahbod < beh...@behdad.org> wrote: > There's no guarantee that the user's shell is sh-compatible. autoconf > really means sh here, because that's the shell the script is written for. > Just symlink your favorite shell to sh then, if it's compatible. > > behdad > http://behdad.org/ > > > On Wed, May 1, 2024 at 2:13 PM Mohammad Akhlaghi < > moham...@akhlaghi.org> wrote: > >> Hi again, >> >> I was able to find a cleaner hack by running this command before the >> './configure' script: >> >> export GNUMAKE="make SHELL=$SHELL" >> >> Afterwards, FreeType successfully ran with my desired shell. >> >> But generally, it would greatly help those building FreeType from >> source >> if the configure script accounts for the 'SHELL' environment variable. >> >> Thanks a lot for all the nice work on FreeType, >> Cheers, >> Mohammad >> >> On 5/1/24 9:00 PM, Mohammad Akhlaghi wrote: >> > Dear Freetype developers, >> > >> > I was trying to build FreeType from source and noticed that the >> > './configure' script does not account for the 'SHELL' environment >> and >> > will always use '/bin/sh'. >> > >> > Looking at the source of the './configure' script, I was able to >> fix the >> > problem by manually adding a 'SHELL=$SHELL' in line 135 of the >> > './configure' script: >> > >> > >> https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/configure?ref_type=heads#L135 >> > >> > Accounting for the user's given SHELL is common in many programs >> when >> > building from source, so it would be good if you could account for >> it in >> > future versions of FreeType also. >> > >> > Cheers, >> > Mohammad >> >>
Re: Accounting for SHELL in ./configure
Can you check if also setting CONFIG_SHELL helps? behdad http://behdad.org/ On Wed, May 1, 2024 at 3:06 PM Mohammad Akhlaghi wrote: > The Autoconf-generated configure script, or even CMake, respect SHELL, so > if a user gives it a problematic shell, they won't be able to build > anything abd many programs will crash. > > But please consider the scenario mentioned before: when a user doesn't > have root permissions to change '/bin/sh', they are left with non-standard > hacks like what I did. > > When each program's build system respects 'SHELL', the user is free to use > any shell they want with any program's build. > > Cheers, > Mohammad > > > > > On May 1, 2024 10:55:05 PM GMT+02:00, Behdad Esfahbod > wrote: > >> I'm not talking about the user overriding the shell specifically. I'm >> talking about users who genuinely use a non-POSIX shell as their terminal >> shell. Then just running ./configure would fail if configure was to respect >> $SHELL. >> >> Or rather you're saying that only POSIX-compatible shells should set >> $SHELL. >> behdad >> http://behdad.org/ >> >> >> On Wed, May 1, 2024 at 2:45 PM Mohammad Akhlaghi >> wrote: >> >>> Thanks Behdad, >>> >>> The problem is that I do not have root permissions on the system with >>> the faulty '/bin/sh': I cannot change '/bin/sh' and need to build my >>> programs with a custom shell. >>> >>> If the user specifies a wrong shell (not the default '/bin/sh'), it is >>> their own responsibility that it is POSIX-compatible. The same way that a >>> user can give a non-GNU Make executable to the GNUMAKE variable. >>> >>> In short, when a user changes defaults, it is their resposibility, not >>> the developer's. So no need to worry about that; the important thing is to >>> give users the freedon to customize for their custom environments (as GNU >>> Autoconf does for example; but Autoconf is not used in FreeType). >>> >>> Cheers, >>> Mohammad >>> >>> >>> >>> On May 1, 2024 10:25:54 PM GMT+02:00, Behdad Esfahbod >>> wrote: >>> There's no guarantee that the user's shell is sh-compatible. autoconf really means sh here, because that's the shell the script is written for. Just symlink your favorite shell to sh then, if it's compatible. behdad http://behdad.org/ On Wed, May 1, 2024 at 2:13 PM Mohammad Akhlaghi wrote: > Hi again, > > I was able to find a cleaner hack by running this command before the > './configure' script: > > export GNUMAKE="make SHELL=$SHELL" > > Afterwards, FreeType successfully ran with my desired shell. > > But generally, it would greatly help those building FreeType from > source > if the configure script accounts for the 'SHELL' environment variable. > > Thanks a lot for all the nice work on FreeType, > Cheers, > Mohammad > > On 5/1/24 9:00 PM, Mohammad Akhlaghi wrote: > > Dear Freetype developers, > > > > I was trying to build FreeType from source and noticed that the > > './configure' script does not account for the 'SHELL' environment > and > > will always use '/bin/sh'. > > > > Looking at the source of the './configure' script, I was able to fix > the > > problem by manually adding a 'SHELL=$SHELL' in line 135 of the > > './configure' script: > > > > > https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/configure?ref_type=heads#L135 > > > > Accounting for the user's given SHELL is common in many programs > when > > building from source, so it would be good if you could account for > it in > > future versions of FreeType also. > > > > Cheers, > > Mohammad > >
Re: Accounting for SHELL in ./configure
The Autoconf-generated configure script, or even CMake, respect SHELL, so if a user gives it a problematic shell, they won't be able to build anything abd many programs will crash. But please consider the scenario mentioned before: when a user doesn't have root permissions to change '/bin/sh', they are left with non-standard hacks like what I did. When each program's build system respects 'SHELL', the user is free to use any shell they want with any program's build. Cheers, Mohammad On May 1, 2024 10:55:05 PM GMT+02:00, Behdad Esfahbod wrote: >I'm not talking about the user overriding the shell specifically. I'm >talking about users who genuinely use a non-POSIX shell as their terminal >shell. Then just running ./configure would fail if configure was to respect >$SHELL. > >Or rather you're saying that only POSIX-compatible shells should set $SHELL. >behdad >http://behdad.org/ > > >On Wed, May 1, 2024 at 2:45 PM Mohammad Akhlaghi >wrote: > >> Thanks Behdad, >> >> The problem is that I do not have root permissions on the system with the >> faulty '/bin/sh': I cannot change '/bin/sh' and need to build my programs >> with a custom shell. >> >> If the user specifies a wrong shell (not the default '/bin/sh'), it is >> their own responsibility that it is POSIX-compatible. The same way that a >> user can give a non-GNU Make executable to the GNUMAKE variable. >> >> In short, when a user changes defaults, it is their resposibility, not the >> developer's. So no need to worry about that; the important thing is to give >> users the freedon to customize for their custom environments (as GNU >> Autoconf does for example; but Autoconf is not used in FreeType). >> >> Cheers, >> Mohammad >> >> >> >> On May 1, 2024 10:25:54 PM GMT+02:00, Behdad Esfahbod >> wrote: >> >>> There's no guarantee that the user's shell is sh-compatible. autoconf >>> really means sh here, because that's the shell the script is written for. >>> Just symlink your favorite shell to sh then, if it's compatible. >>> >>> behdad >>> http://behdad.org/ >>> >>> >>> On Wed, May 1, 2024 at 2:13 PM Mohammad Akhlaghi >>> wrote: >>> Hi again, I was able to find a cleaner hack by running this command before the './configure' script: export GNUMAKE="make SHELL=$SHELL" Afterwards, FreeType successfully ran with my desired shell. But generally, it would greatly help those building FreeType from source if the configure script accounts for the 'SHELL' environment variable. Thanks a lot for all the nice work on FreeType, Cheers, Mohammad On 5/1/24 9:00 PM, Mohammad Akhlaghi wrote: > Dear Freetype developers, > > I was trying to build FreeType from source and noticed that the > './configure' script does not account for the 'SHELL' environment and > will always use '/bin/sh'. > > Looking at the source of the './configure' script, I was able to fix the > problem by manually adding a 'SHELL=$SHELL' in line 135 of the > './configure' script: > > https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/configure?ref_type=heads#L135 > > Accounting for the user's given SHELL is common in many programs when > building from source, so it would be good if you could account for it in > future versions of FreeType also. > > Cheers, > Mohammad
Re: Accounting for SHELL in ./configure
I'm not talking about the user overriding the shell specifically. I'm talking about users who genuinely use a non-POSIX shell as their terminal shell. Then just running ./configure would fail if configure was to respect $SHELL. Or rather you're saying that only POSIX-compatible shells should set $SHELL. behdad http://behdad.org/ On Wed, May 1, 2024 at 2:45 PM Mohammad Akhlaghi wrote: > Thanks Behdad, > > The problem is that I do not have root permissions on the system with the > faulty '/bin/sh': I cannot change '/bin/sh' and need to build my programs > with a custom shell. > > If the user specifies a wrong shell (not the default '/bin/sh'), it is > their own responsibility that it is POSIX-compatible. The same way that a > user can give a non-GNU Make executable to the GNUMAKE variable. > > In short, when a user changes defaults, it is their resposibility, not the > developer's. So no need to worry about that; the important thing is to give > users the freedon to customize for their custom environments (as GNU > Autoconf does for example; but Autoconf is not used in FreeType). > > Cheers, > Mohammad > > > > On May 1, 2024 10:25:54 PM GMT+02:00, Behdad Esfahbod > wrote: > >> There's no guarantee that the user's shell is sh-compatible. autoconf >> really means sh here, because that's the shell the script is written for. >> Just symlink your favorite shell to sh then, if it's compatible. >> >> behdad >> http://behdad.org/ >> >> >> On Wed, May 1, 2024 at 2:13 PM Mohammad Akhlaghi >> wrote: >> >>> Hi again, >>> >>> I was able to find a cleaner hack by running this command before the >>> './configure' script: >>> >>> export GNUMAKE="make SHELL=$SHELL" >>> >>> Afterwards, FreeType successfully ran with my desired shell. >>> >>> But generally, it would greatly help those building FreeType from source >>> if the configure script accounts for the 'SHELL' environment variable. >>> >>> Thanks a lot for all the nice work on FreeType, >>> Cheers, >>> Mohammad >>> >>> On 5/1/24 9:00 PM, Mohammad Akhlaghi wrote: >>> > Dear Freetype developers, >>> > >>> > I was trying to build FreeType from source and noticed that the >>> > './configure' script does not account for the 'SHELL' environment and >>> > will always use '/bin/sh'. >>> > >>> > Looking at the source of the './configure' script, I was able to fix >>> the >>> > problem by manually adding a 'SHELL=$SHELL' in line 135 of the >>> > './configure' script: >>> > >>> > >>> https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/configure?ref_type=heads#L135 >>> > >>> > Accounting for the user's given SHELL is common in many programs when >>> > building from source, so it would be good if you could account for it >>> in >>> > future versions of FreeType also. >>> > >>> > Cheers, >>> > Mohammad >>> >>>
Re: Accounting for SHELL in ./configure
Thanks Behdad, The problem is that I do not have root permissions on the system with the faulty '/bin/sh': I cannot change '/bin/sh' and need to build my programs with a custom shell. If the user specifies a wrong shell (not the default '/bin/sh'), it is their own responsibility that it is POSIX-compatible. The same way that a user can give a non-GNU Make executable to the GNUMAKE variable. In short, when a user changes defaults, it is their resposibility, not the developer's. So no need to worry about that; the important thing is to give users the freedon to customize for their custom environments (as GNU Autoconf does for example; but Autoconf is not used in FreeType). Cheers, Mohammad On May 1, 2024 10:25:54 PM GMT+02:00, Behdad Esfahbod wrote: >There's no guarantee that the user's shell is sh-compatible. autoconf >really means sh here, because that's the shell the script is written for. >Just symlink your favorite shell to sh then, if it's compatible. > >behdad >http://behdad.org/ > > >On Wed, May 1, 2024 at 2:13 PM Mohammad Akhlaghi >wrote: > >> Hi again, >> >> I was able to find a cleaner hack by running this command before the >> './configure' script: >> >> export GNUMAKE="make SHELL=$SHELL" >> >> Afterwards, FreeType successfully ran with my desired shell. >> >> But generally, it would greatly help those building FreeType from source >> if the configure script accounts for the 'SHELL' environment variable. >> >> Thanks a lot for all the nice work on FreeType, >> Cheers, >> Mohammad >> >> On 5/1/24 9:00 PM, Mohammad Akhlaghi wrote: >> > Dear Freetype developers, >> > >> > I was trying to build FreeType from source and noticed that the >> > './configure' script does not account for the 'SHELL' environment and >> > will always use '/bin/sh'. >> > >> > Looking at the source of the './configure' script, I was able to fix the >> > problem by manually adding a 'SHELL=$SHELL' in line 135 of the >> > './configure' script: >> > >> > >> https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/configure?ref_type=heads#L135 >> > >> > Accounting for the user's given SHELL is common in many programs when >> > building from source, so it would be good if you could account for it in >> > future versions of FreeType also. >> > >> > Cheers, >> > Mohammad >> >>
Re: Accounting for SHELL in ./configure
There's no guarantee that the user's shell is sh-compatible. autoconf really means sh here, because that's the shell the script is written for. Just symlink your favorite shell to sh then, if it's compatible. behdad http://behdad.org/ On Wed, May 1, 2024 at 2:13 PM Mohammad Akhlaghi wrote: > Hi again, > > I was able to find a cleaner hack by running this command before the > './configure' script: > > export GNUMAKE="make SHELL=$SHELL" > > Afterwards, FreeType successfully ran with my desired shell. > > But generally, it would greatly help those building FreeType from source > if the configure script accounts for the 'SHELL' environment variable. > > Thanks a lot for all the nice work on FreeType, > Cheers, > Mohammad > > On 5/1/24 9:00 PM, Mohammad Akhlaghi wrote: > > Dear Freetype developers, > > > > I was trying to build FreeType from source and noticed that the > > './configure' script does not account for the 'SHELL' environment and > > will always use '/bin/sh'. > > > > Looking at the source of the './configure' script, I was able to fix the > > problem by manually adding a 'SHELL=$SHELL' in line 135 of the > > './configure' script: > > > > > https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/configure?ref_type=heads#L135 > > > > Accounting for the user's given SHELL is common in many programs when > > building from source, so it would be good if you could account for it in > > future versions of FreeType also. > > > > Cheers, > > Mohammad > >
Re: Accounting for SHELL in ./configure
Hi again, I was able to find a cleaner hack by running this command before the './configure' script: export GNUMAKE="make SHELL=$SHELL" Afterwards, FreeType successfully ran with my desired shell. But generally, it would greatly help those building FreeType from source if the configure script accounts for the 'SHELL' environment variable. Thanks a lot for all the nice work on FreeType, Cheers, Mohammad On 5/1/24 9:00 PM, Mohammad Akhlaghi wrote: Dear Freetype developers, I was trying to build FreeType from source and noticed that the './configure' script does not account for the 'SHELL' environment and will always use '/bin/sh'. Looking at the source of the './configure' script, I was able to fix the problem by manually adding a 'SHELL=$SHELL' in line 135 of the './configure' script: https://gitlab.freedesktop.org/freetype/freetype/-/blob/master/configure?ref_type=heads#L135 Accounting for the user's given SHELL is common in many programs when building from source, so it would be good if you could account for it in future versions of FreeType also. Cheers, Mohammad
