Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new command `set?'

[John Mandereau]

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