[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new
From: |
John Mandereau |
Subject: |
Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new command `set?' |
Date: |
Sun, 27 Jan 2019 02:56:21 +0100 |
User-agent: |
Evolution 3.30.4 (3.30.4-1.fc29) |
Hi Knut,
On Wednesday 2019/01/23 12:54 +0100, Knut Petersen wrote:
> fatal error: failed files: "65/lily-bab68f98.ly"
>
> So lilypond fails because gs failed to convert 65/lily-bab68f98.ly.
I reproduced the same error with PRs 53-60 merged on Ubuntu 14.04.
[...]
> Summary up to now:
> ===================
>
> We build linux-64::lilypond-test, but target/linux-
> 64/root/usr/bin/../bin/gs fails during it's initialization because it
> does not look for shared libraries in target/linux-64/root/usr/lib
> and uses system libraries instead.
I agree with your analysis until this point.
> Look at PATH and LD_* variables passed to lilypond and gs
> =========================================================
>
> In both TRACE/TP.26267 an TRACE/TP.26268 we have proper PATH and
> GS_LIBRARY_DIR entries in the environment ...
>
>
> PATH=/home/knut/sources/gub/target/tools/root/usr/bin:/home/knut/sour
> ces/gub/target/linux-64/root/usr/bin:$PATH
> LD_LIBRARY_PATH=/home/knut/sources/gub/target/tools/root/usr/lib:/hom
> e/knut/sources/gub/target/linux-
> 64/root/usr/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
>
> Interesting.
> ============
>
> According to that PATH we should have executed
> target/tools/root/usr/bin/gs and not target/linux-
> 64/root/usr/bin/../bin/gs. Well, it seems lilypond does not look for
> a gs in PATH but executes ../bin/gs relative to the directory where
> its own executable is located. I'll have to verify that in the
> sources lates. And obviously LD_LIBRARY_PATH is not obeyed.
> What a mess.
What you quoted is probably not the actual LD_LIBRARY_PATH, but a
portion of compile_command environment variable set by GUB (see a
portion of strace log attached); even if it was, we'd be in serious
trouble, because it would mean shell variable substitution has not been
made, and as far as I understand, there is no shell involved in GS
invocation from LilyPond.
Note that I was misled just like you at first sight (and also at n-th
sight for several n's), until I saw the override of LD_LIBRARY_PATH in
tools::python wrapper you added in pull request #58. Immediately below
is the quote of my comment on gub/specs/python.py(211).
This override of LD_LIBRARY_PATH breaks lilypond-test, as tools:python
is used in lilypond-book call, and linux-(arch)::gs needs a different
directory in LD_LIBRARY_PATH, namely target/linux-64/root/usr/lib.
I haven't investigated when and why such a wrapper would be necessary,
but if it is, it might be saner to define
LD_LIBRARY_PATH=%(system_prefix)s/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
instead.
Best
--
John Mandereau
strace_gs_link_error.log
Description: Text Data