Re: [RFC] Add set of scripts to build static binaries on Linux

[Jonas Hahnfeld]

Am Freitag, dem 06.08.2021 um 15:33 +0200 schrieb Michael Käppler:
> Am 05.08.2021 um 21:51 schrieb Jonas Hahnfeld via Discussions on
> LilyPond development:
> > I just posted the first version of completely rewritten scripts to
> > build static binaries for LilyPond:
> > https://gitlab.com/lilypond/lilypond/-/merge_requests/864
> Hi Jonas,
> thank you very much for your work! IMHO this is going to be a much
> better maintainable way of producing binaries than GUB was.
> After some quirks I succeeded in building a package from a tarball
> created with `make dist` from
> af931c4b1e8f971e6be994a16aa70c0b53c7fb43
> 
> The resulting binary seems to work fine.
> 
> My build environment was Ubuntu 18.04 with gcc 7.5.0.
> 
> The problems I encountered:
> 1. Building 'fontconfig' failed due to missing 'gperf' on my system.
> This seems to be an error in the fontconfig build system, though,
> because 'configure'
> succeeded. It should check for presence of 'gperf', if it is needed, right?

I think there is some check, but maybe it doesn't complain if not
found? Anyway, Fontconfig is a bit odd and version 2.13.1 is from
almost three years ago while the most recent development release is
2.13.94, so maybe not too long until that becomes stable. Or maybe we
should just switch to 2.13.94, which also gets rid of the dependency
for libuuid IIRC?

> 2. The 'meson' package that comes with Ubuntu 18.04 is fairly old, so it
> did fail
> with 'meson: error: unrecognized arguments: --auto-features=disabled'.
> This option was added in 0.47.0:
> https://mesonbuild.com/Release-notes-for-0-47-0.html#new-type-of-build-option-for-features
> I could fix this by installing a current version from PyPI.

You need at least 0.55.3 for Pango. I'll add some notes on what the
required dependencies are (documentation is always hard...).


> Some questions:
> 1. Is it a deliberate decision to force the usage of Guile 2.2 or
> do you plan to make Guile 1.8 builds available, too?

Yes, Guile 2.2 is a deliberate choice for many reasons. First and
foremost, as stated in other threads, I don't believe that Guile 1.8
has an endless future in LilyPond with distributions switching to 2.2
and us probably not wanting to maintain code for making both versions
happy forever.
Other reasons against Guile 1.8 include that its srfi libraries must be
dynamically linked, no matter what. And while it is possible to link
the main libguile statically into the lilypond binary, it's incredibly
hard because you need to export the symbols from libguile required by
the srfi libraries (you can look at the GitHub repository, it was there
at some point). Moreover, and maybe most importantly, Guile 1.8 doesn't
work with 64-bit on Windows, and I don't think it's a good investment
to spend time fixing that.

> 2. Would it be possible to avoid rebuilds of dependencies already built, if
> the build process is interrupted?

That's another deliberate choice because I find incremental builds in
GUB quite painful. I see the advantage, but building all dependencies
natively is pretty fast compared to building the entire toolchain. For
local development, you can throw packages out of the all_dependencies
variable in lib/dependencies.py, but you're at your own risk there.

Jonas

> 
> Thanks,
> Michael

P.S. Please CC me on replies, this makes them go to my inbox instead of
the lilypond-devel directory which I see much faster.

signature.asc
Description: This is a digitally signed message part