lilypond-devel
[Top][All Lists]
Advanced

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

Re: Cross-compiling for MinGW on Fedora 36


From: Jonas Hahnfeld
Subject: Re: Cross-compiling for MinGW on Fedora 36
Date: Sun, 26 Jun 2022 20:06:30 +0200
User-agent: Evolution 3.44.2

On Sun, 2022-06-26 at 19:13 +0200, Jean Abou Samra wrote:
> Hi,
> 
> I recently reinstalled my system, now on Fedora (version 36) rather than
> Ubuntu.

To be honest, I would recommend getting a VM with Ubuntu for building
LilyPond binaries. As witnessed, the cross-compilation environments are
too different between distributions to make it work reliably...

> I tried cross-compiling LilyPond for MinGW, to continue investigating
> https://gitlab.com/lilypond/lilypond/-/issues/6361. However, Ghostscript
> fails to compile with
> 
> In file included from 
> /home/jean/repos/lilypond/release/binaries/mingw/dependencies/src/ghostscript-9.56.1/base/gp_unix.c:24:
> /home/jean/repos/lilypond/release/binaries/mingw/dependencies/src/ghostscript-9.56.1/base/time_.h:82:12:
>  
> fatal error: sys/times.h: No such file or directory
>     82 | #  include <sys/times.h>
>        |            ^~~~~~~~~~~~~
> compilation terminated.
> 
> 
> The code in question reads
> 
> #if defined(HAVE_SYS_TIMES_H) && HAVE_SYS_TIMES_H == 1
> #  include <sys/times.h>
> #  define use_times_for_usertime 1
>                  /* Posix 1003.1b-1993 section 4.8.1.5 says that
>                     CLK_TCK is obsolescent and that sysconf(_SC_CLK_TCK)
>                     should be used instead, but this requires including
>                     <unistd.h>, which is too painful to configure.  */
> #  ifndef CLK_TCK
> #    define CLK_TCK 100        /* guess for older hosts */
> #  endif
> #else
> #  define use_times_for_usertime 0
> #endif
> 
> 
> As far as I understood, it's expected that MinGW doesn't have
> sys/times.h. The question is thus why HAVE_SYS_TIMES_H was 1.
> Looking into mingw/dependencies/build/ghostscript-9.56.1/config.log,
> I find
> [...]
> 
> However, at the end, there is
> 
> 
> GCFLAGSAUX='  -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations 
> -Wmissing-prototypes -Wwrite-strings -fno-strict-aliasing 
> -Werror=declaration-after-statement -fno-builtin -fno-common 
> -Werror=return-type -DHAVE_STDINT_H=1 -DHAVE_DIRENT_H=1 
> -DHAVE_SYS_DIR_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 
> -DHAVE_INTTYPES_H=1 -DHAVE_LIBDL=1 -DGX_COLOR_INDEX_TYPE="unsigned long 
> long" -D__USE_UNIX98=1 -DBUILD_PDF=1 
> -I/home/jean/repos/lilypond/release/binaries/mingw/dependencies/src/ghostscript-9.56.1/pdf
>  
> -DNOCONTRIB -DHAVE_RESTRICT=1 -fno-strict-aliasing'
> 
> 
> That sounds odd. I'm a bit out of my depth here. Does anyone have
> a clue?

I remember overwriting this for my proof-of-concept:
https://github.com/hahnjo/lilypond-binaries/blob/main/scripts/build_native_deps.sh#L202-L205
However, this somehow wasn't necessary anymore with the rewritten
Python version running on Ubuntu. I never investigated why...

However, GCFLAGSAUX above should be for compiling host programs
("AUX"), so that is fine in principle. You'll need to check where the
defines come from when actually cross-compiling...

> Also, Fontconfig failed building before I did
> 
> diff --git a/release/binaries/lib/dependencies.py 
> b/release/binaries/lib/dependencies.py
> index 5cfb6af5d2..a3ef1e72ad 100644
> --- a/release/binaries/lib/dependencies.py
> +++ b/release/binaries/lib/dependencies.py
> @@ -146,6 +146,11 @@ class Fontconfig(ConfigurePackage):
>       def __str__(self) -> str:
>           return f"Fontconfig {self.version}"
> 
> +    def build_env_extra(self, c: Config) -> Dict[str, str]:
> +        extra = super().build_env_extra(c)
> +        extra["CFLAGS"] = "-fstack-protector"
> +        return extra
> +
> 
>   fontconfig = Fontconfig()
> 
> 
> following
> 
> https://github.com/msys2/MINGW-packages/issues/5868
> 
> (the linker error was about __strcpy_chk).
> 
> I have no idea why this is needed. Grepping for "FORTIFY_SOURCES"
> in the Fontconfig repository doesn't yield matches. Again, can
> anyone shed light on this?

I *think* that _FORTIFY_SOURCES may be set by Fedora globally. If so,
we'll probably need to exclude that for cross-compilation...

Jonas

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


reply via email to

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