[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I cannot run make check since Issue 5450: Introduce new

From: John Mandereau
Subject: Re: I cannot run make check since Issue 5450: 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/"
> So lilypond fails because gs failed to convert 65/ 

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/

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



John Mandereau

Attachment: strace_gs_link_error.log
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]