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
<moham...@akhlaghi.org> 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
><moham...@akhlaghi.org> 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
>
>
