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

[Joel Sherrill]

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. :)

--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/f31a94d2/attachment.htm>