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

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?


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 <[email protected]> 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 <[email protected]> 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
> >