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

[Joel Sherrill]

On Wed, Nov 20, 2024 at 10:54 AM Corinna Vinschen <vinschen@redhat.com>
wrote:

> On Nov 20 10: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.
>
> Just use Cygwin instead of MSYS2?
>

We like to support both. MSYS2 and Cygwin each have different pros
and cons. Cygwin is usually easier to build on and more POSIX like.
MSYS2 produces native executables but is often a bit more challenging
to build things on.

One of the advantages of free and open source software is the ability
to support any host of interest. We don't want to lose MSYS2.

--joel

>
>
> Corinna
>
>
> >
> > But definitely better if someone has an idea for a real fix. :)
> >
> > --joel
> >
> > On Wed, Nov 20, 2024 at 10:14 AM Gedare Bloom <gedare@rtems.org> 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 <gedare@rtems.org> wrote:
> > > >
> > > > Hello Newlib!
> > > >
> > > > 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
> > > >
> > > > 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.
> > > >
> > > > Gedare
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/newlib/attachments/20241120/c19aebc3/attachment-0001.htm>