Re: gcc one-tree build with newlib on MSYS2 broken due to top-level include?

On Wed, Nov 20, 2024 at 10:42 AM <[email protected]> wrote:
>
> Hi folks,
>
> If running native Windows builds on NTFS 3.1+, especially if on Windows 10 build
> 14972+, is there a reason the builds are not using use native mklink?
>
TIL!  Thanks Brian, this is great and appears to do the trick. We try
to meet users where they are at, but I think we can safely rely on
this feature and development mode for our MSYS2 users.

> MKLINK [[/D] | [/H] | [/J]] Link Target
>
>          /D      Creates a directory symbolic link.  Default is a file
>                  symbolic link.
>          /H      Creates a hard link instead of a symbolic link.
>          /J      Creates a Directory Junction.
>          Link    Specifies the new symbolic link name.
>          Target  Specifies the path (relative or absolute) that the new link
>                  refers to.
>
> Note the link and target paths are flipped relative to POSIX ln.
>
> Directory symlinks, hard links, and junctions are also supported.
>
> These operations may be made unprivileged in Developer mode and/or with Local
> Security Policy.
>
> Cygwin has been using the underlying operations, where supported, for links for
> some time now; for example:
>
> $ llgo wget-1.25.0-2.x86_64/{CYGWIN-PATCHES,build/GNUmakefile}
> lrwxrwxrwx 1 62 Nov 16 15:34 wget-1.25.0-2.x86_64/build/GNUmakefile ->
> /usr/src/wget/wget-1.25.0-2.x86_64/src/wget-1.25.0/GNUmakefile
> lrwxrwxrwx 1 65 Nov 16 15:25 wget-1.25.0-2.x86_64/CYGWIN-PATCHES ->
> /usr/src/wget/wget-1.25.0-2.x86_64/src/wget-1.25.0/CYGWIN-PATCHES/
> $ cmd /c dir wget-1.25.0-2.x86_64\\CYGWIN-PATCHES
> wget-1.25.0-2.x86_64\\build\\GNUmakefile
> ...
>   Directory of C:\cygwin64\usr\src\wget\wget-1.25.0-2.x86_64
>
> 2024-11-16  15:25    <JUNCTION>     CYGWIN-PATCHES [...]
>                 1 File(s)              0 bytes
>
>   Directory of C:\cygwin64\usr\src\wget\wget-1.25.0-2.x86_64\build
>
> 2024-11-16  15:34    <JUNCTION>     GNUmakefile [...]
>                 1 File(s)              0 bytes
>
> On 2024-11-20 09:32, Joel Sherrill wrote:
> > Not to distract from the problem at hand, but I think we do NOT want to
> > move away from one-tree builds. It is much better if they are fixed.
> >
> > Moving away from the one-tree build means we will end up with
> > multiple steps:
> >
> > (1) gcc C-only w/o newlib
> > (2) newlib (may require doing gcc to get current configuration
> > (3) languages beyond C (C++, Ada, Fortran)
> >
> > We have invested a lot of effort in the one-tree build building everything
> > in one sweep. Going to multiple steps will increase complexity and
> > build time.
> >
> > I'm really hoping someone has a good fix. Otherwise, I'd lean to us
> > keeping your single file copy hack.
> >
> > But definitely better if someone has an idea for a real fix. :)
>
> > On Wed, Nov 20, 2024 at 10:14 AM Gedare Bloom wrote:
> >     We were able to confirm the one-tree builds on cygwin work still. So
> >     this appears to be an issue related to the lack of support for proper
> >     symlinks in MSYS2, coupled with newlib "reaching up" to get an include
> >     path. We currently workaround this problem by copying the
> >     arm-acle-compat.h header file into the gcc-13.3.0/include directory,
> >     which is not ideal. Our next step is probably to stage the gcc and
> >     newlib builds instead of using the combined one-tree approach.
> >
> >     Any guidance on better/different ways to accomplish the one-tree build
> >     without symlinking newlib-cygwin/newlib is appreciated.
> >
> > On Tue, Nov 19, 2024 at 5:22 PM Gedare Bloom wrote:
>  >> In RTEMS we build a one-tree gcc cross using newlib. We have
>  >> historically just symlinked the newlib directory into gcc, e.g.,
>  >> something like...
>  >>  $ git clone sourceware.org:/git/newlib-cygwin.git
>  >>  $ cd gcc-13.3
>  >>  $ ln -s ../newlib-cygwin/newlib .
>  >>  $ configure ... --with-newlib ...
>  >> etc. This has worked pretty well for a long time, however we've seen a
>  >> breakage on MSYS2 builds for the arm target:
>  >> ../../../gcc-13.3.0/newlib/libc/machine/arm/setjmp.S:5:10: fatal
>  >> error: arm-acle-compat.h: No such file or directory
>  >>     5 | #include "arm-acle-compat.h"
>  >>
>  >> We tracked down this file is missing due to
>  >> https://sourceware.org/pipermail/newlib/2023/020082.html <https://
>  >ourceware.org/pipermail/newlib/2023/020082.html>
>  >>
>  >> We tracked the issue to this snippet:
>  >> -idirafter ../../../gcc-13.3.0/newlib/../include
>  >>
>  >> Which is built in Makefile.am: 66
>  >> srcroot = $(top_srcdir)/..
>  >>
>  >> Makefile.am: 73
>  >> AM_CPPFLAGS = $(NEWLIB_CFLAGS) $(TARGET_CFLAGS) $(AM_CPPFLAGS_$(subst
>  >> /,_,$(@D))) $(AM_CPPFLAGS_$(subst /,_,$(@D)_$(<F))) -idirafter
>  >> $(srcroot)/include
>  >>
>  >> The problem seems to be only affecting Windows, due to the deep-clone
>  >> of newlib-cygwin/newlib as opposed to symlinking it. On OS's with
>  >> actual symlinks, the relative paths descending out of the symlink and
>  >> back into it are able to resolve the -idirafter path. On MSYS2 the
>  >> include path is not finding newlib-cygwin/include, it is finding
>  >> gcc-13.3.0/include.
>  >>
>  >> Anyone have advice for how to build gcc with newlib in a one-tree
>  >> build on Windows (MSYS2)?
>  >>
>  >> We have at least one person looking into this for cygwin and may
>  >> report back on it too.
>
> --
> Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada
>
> La perfection est atteinte                   Perfection is achieved
> non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
> mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
>                                  -- Antoine de Saint-Exupéry