Re: Patchy email (guile 1.8 instructions)

[David Kastrup]

address@hidden writes:

> David,
>
> On 07/03/2020 00:59, David Kastrup wrote:
>> David Kastrup <address@hidden> writes:
>>
>>> address@hidden writes:
>>>
>>>> 23:42:58 (UTC) Begin LilyPond compile, previous commit at  
>>>> bf6f650dbc16cb33181501eee2aca082a5a5e3ef
>>>> 23:43:05 Merged staging, now at:   bf6f650dbc16cb33181501eee2aca082a5a5e3ef
>>>> 23:43:06   Success:                ./autogen.sh --noconfigure
>>>> 23:43:18   Success:                /tmp/lilypond-autobuild/configure 
>>>> --enable-checking
>>>> 23:43:21   Success:                nice make clean
>>>> 23:46:54   Success:                nice make -j9 CPU_COUNT=9
>>>> 23:51:15   Success:                nice make test -j9 CPU_COUNT=9
>>>> 23:54:59 *** FAILED BUILD ***
>>>>    nice make doc -j9 CPU_COUNT=9
>>>>    Previous good commit:   825dd87d0b1b58e56d7c66ef1fc1dd672d913c84
>>>>    Current broken commit:  bf6f650dbc16cb33181501eee2aca082a5a5e3ef
>>>> 23:54:59 *** FAILED STEP ***
>>>>    merge from staging
>>>>    Failed runner: nice make doc -j9 CPU_COUNT=9
>>>> See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt
>>>> 23:54:59 Traceback (most recent call last):
>>>>    File 
>>>> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", 
>>>> line 528, in handle_staging
>>>>      self.build (issue_id=issue_id)
>>>>    File 
>>>> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", 
>>>> line 333, in build
>>>>      issue_id)
>>>>    File 
>>>> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", 
>>>> line 266, in runner
>>>>      raise FailedCommand ("Failed runner: %s\nSee the log file %s" % 
>>>> (command, this_logfilename))
>>>> FailedCommand: Failed runner: nice make doc -j9 CPU_COUNT=9
>>>> See the log file log-staging-nice-make-doc--j9-CPU_COUNT=9.txt
>>> So I am suddenly seeing comparatively frequent segfaults in my patchy
>>> runs while building the docs.  This is the second time in as many days
>>> (or not more than 3 days I guess).
>>>
>>> My prime candidates are basically Han-Wen's job control for
>>> lilypond-book (could lead to out-of-memory conditions on my system and I
>>> don't think we handle exceptions other than aborting currently) and
>>> Torsten Hämmerle's French beaming stuff.  I read through that patch a
>>> few times but did not see any red flags.
>>>
>>> To track this down, I'll now enable core dumps and hope that eventually
>>> I'll be able to get a relevant one.  I'll stick at current settings for
>>> now.
>> Ok, I am seriously annoyed right now.  I have in my Patchy config (and
>> use in my normal compilations)
>>
>> [configure_environment]
>> GUILE=/usr/bin/guile
>> GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config
>>
>> but GUILE_CONFIG is now being ignored.  What is the current invocation I
>> am supposed to use to get my own version of GUILE?  Where is this
>> documented?
>>
>> ./configure --help
>>
>> does not say _anything_ here.
>>
>> This is pretty important for people like Debian system integrators that
>> include a version of Guile-1.8.  That is now getting ignored by default,
>> and there is no documented way of getting it.
>>
> I built a couple of new new Ubuntu 18.04 VMs at work last week (I like
> to re-aquaint myself with the steps to build a working LP dev machine 
> now and then).
>
> For Guile I always use the instructions from Federico that he sent to
> the mailing lists
>
> https://lists.gnu.org/archive/html/lilypond-devel/2017-10/msg00130.html
>
> --snip--
>
> git clone https://git.savannah.gnu.org/git/guile.git
> cd guile
> git checkout branch_release-1-8
> ./autogen.sh
> ./configure --disable-error-on-warning --prefix=/usr/local
> make
> sudo make install
> sudo ldconfig
>
> echo "GUILE_CONFIG=/usr/local/bin/guile-config" >> ~/.bashrc
>
> --snip--
>
> P.S. I am running a patchy staging myself right now.

GUILE_CONFIG is now being ignored.  It's possible that pkgconfig picks
up /usr/local/lib/pkgconfig/guile-1.8.pc on your system now and that
your system works in that manner.

But with a privately installed Guile-1.8 like mine (namely a more
specific prefix than /usr/local ), this recipe will no longer work.

-- 
David Kastrup