Re: "libmpfr.so.4" not found

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Wed, Oct 03, 2018 at 06:53:07AM +0700, Robert Elz wrote:
>     Date:        Tue, 2 Oct 2018 20:44:00 +0200
>     From:        Joerg Sonnenberger <joerg%bec.de@localhost>
>     Message-ID:  <20181002184400.GA17205%britannica.bec.de@localhost>
> 
>   | I have no idea what you are talking about. The configure script is used
>   | during tools build because we hardly know what the build host wants.
> 
> That is true of all of the tools part of the build, yet most of it seems to
> survive just fine without using anything autoconf related, and while I
> haven't looked at it closely, it is hard to imagine that a compression
> tool should care all that much about the system, we certainly don't
> want it selecting the locations of anything, about all it should be doing,
> I'd expect, is locating a compiler to use.

When was the last time you really looked into the tools build? We are
currently running a total of about 36 instances of configure. Half of
them or so might be in gcc, but there are a lot of things that run it.
One of the platform specific things xz is trying to do is avoid
overloading the host system by using too much RAM, just to give an
example.

> But if it actually worked properly, and configured things for various
> different build environments (all by itself) then I woulodn't care (there
> are, I think, one or two other configure scripts run as part of the tools
> build, and I never get bothered by any of them.,)

It works properly. Having a broken awk around is not something I
generally consider a configuration I care much about. Note: broken awk,
not limited awk.

>   | The regular xz build system (incl. configure) is perfectly willing to do
>   | out-of-source builds. A read-only src directory certainly works fine
>   | here, i.e. doing a ro-null mount.
> 
> Try it when the shell used doesn't implement $LINENO (as one example).
> The first thing it does is make a "config.lineno" (in ".,") which it then uses
> instead of the original script.   Aside from being how configure scripts work,
> I can't imagine any useful purpose during a tools build of knowing what the
> line number of somethng that fails - nothing should be failing, or we have
> not done a good job of making the tools build environment, it should work
> everywhere.   That part of the script should simply be dropped, and if
> $LINENO doesn't work, then it doesn't, who cares?
> 
> After making it put the config.lineno file elsewhere (for simplicity, I just
> shoved it in /tmp. but that's not the right way) then it tried to make config.log, 
> and after that config.status, and then I gave up trying...o

Yes, the configure writes to the current directory. That's how it is
meant to be used. The current directory in the case of the tools builds
is the objdir. configure doesn't have to care about that. The one place
where it does matter would be the Makefiles, but those are using
VPATH/.PATH or similar tools.

Joerg

Joerg