[Top][All Lists]

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

Re: Compiling LilyPond on Linux Mint 19.1

From: Urs Liska
Subject: Re: Compiling LilyPond on Linux Mint 19.1
Date: Fri, 21 Dec 2018 19:06:43 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

Am 21.12.18 um 09:06 schrieb Urs Liska:
Hi Lukas,

thanks for putting this together. Indeed since installing a distro that doesn't Guile 1.8 anymore I hadn't been able to compile LilyPond anymore. Once I managed to compile Guile 1.8 and do a build but for some reason I lost this option. I think the point was that after compiling Guile I had to actually change the way LilyPond's make was handled - which of course isn't sustainable.

I'm also running Linux Mint 19.1, and followed your command list (and the previous instructions from the CG). Except that I already had some of the dependencies installed everything worked flawlessly, and I could run a make to compile LilyPond, register that in Frescobaldi and compile a .ly file with it. A warning about missing URW fonts was the only issue I encountered. make doc took the expected ages but worked without errors too!

So I can confirm that the steps work on Linux Mint 19.

Janek WachoĊ‚ has written a few scripts to help managing multiple LilyPond builds, which I really appreciated when I had them working. Basically they provide a configuration layer around the compilation, then create a local clone of the main code repository and build from that copy. That makes it possible to have multiple different builds from different branches (or even states of a branch) in parallel. I will see if I can integrate that with compiling through a self-compiled Guile and report back. Maybe these scripts are of use for others as well.

I have looked again into these scripts and found that they (still) work well. The script that I suggest looking into is located at

However, when it is considered of general use I'll ask Janek to extract the script from his scripts collection.

In order to use the script two environment variables have to be exported (presumably from .bashrc):


When invoked without arguments the script will clone the source repository in its current state to the "current" subdirectory of LILYPOND_BUILD_DIR and build it from there. Settings to build other branches (or combinations of branches) to other target directories are described at the beginning of the script.

Does this look interesting to anybody?


Am 20.12.18 um 12:21 schrieb Lukas-Fabian Moser:

this is mostly to give a reference to those who might hit the same problems that I had:

I decided to switch from my ancient Linux Mint 17.3 to Linux Mint 19.1 yesterday. In order to set up a working build environment, I had to provide a working Guile 1.8 which seems not to be in the repositories any more.

So in addition to following the instructions given in I also followed the most recent one of the various variations of steps for compiling Guile 1.8 that Federico Bruni gave in October 2017 (

git clone
cd guile
git checkout branch_release-1-8
./configure --disable-error-on-warning --prefix=/usr/local
sudo make install
sudo ldconfig

echo "GUILE_CONFIG=/usr/local/bin/guile-config" >> ~/.bashrc

Then, after restarting Bash, I could proceed to and successfully compile current Master.

(On my system, the echo [...] >> ~/.bashrc command added the given line without any new-line or whitespace, so I had to insert a newline in an editor.)

Probably these instructions would need some more testing/polishing/adjusting to other distributions before they could reasonably be added to the Contributor's Guide, so I just thought it might be helpful to collect them once more here. (In fact I did run into a bit of trouble tonight, but this seems to have been because I wanted to re-use my old lilypond git directory which had been used for compiling on my old system, so it wasn't really a clean start. This might also mean my procedure can't be guaranteed to work on a really fresh Lilypond git folder, but I think they should - I removed the old build/ folder before the first succesful compile, so there shouldn't have been any remnants of earlier successful compilations.)

Or would there have been a much easier way to success?

(The upside for me: Now I have the necessary Python/Qt/Lilypond bindings to also run current Frescobaldi from the git repository following Urs's excellent instructions on


lilypond-user mailing list

lilypond-user mailing list

reply via email to

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