diff mbox series

[Ada] Makefile patches from initial RISC-V cross/native build.

Message ID 20180705234517.6059-1-jimw@sifive.com
State New
Headers show
Series [Ada] Makefile patches from initial RISC-V cross/native build. | expand

Commit Message

Jim Wilson July 5, 2018, 11:45 p.m. UTC
These are some patches I needed to complete my cross build of a native
riscv linux Ada compiler.  Some paths were different on the build machine
and host machine.  I needed to pass options into gnatmake to work around this,
and that required fixing some makefile rules to use $(GNATMAKE) instead of
calling gnatmake directly.

Tested with native riscv-linux bootstrap with Ada enabled.

OK?

Jim

	gcc/ada/
	* Make-generated.in (treeprs.ads): Use $(GNATMAKE) instead of gnatmake.
	(einfo.h, sinfo.h, stamp-snames, stamp-nmake): Likewise.
	* gcc-interface/Makefile.in (xoscons): Likewise.
---
 gcc/ada/Make-generated.in         | 10 +++++-----
 gcc/ada/gcc-interface/Makefile.in |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

Comments

Arnaud Charlet July 6, 2018, 7:18 a.m. UTC | #1
> These are some patches I needed to complete my cross build of a native
> riscv linux Ada compiler.  Some paths were different on the build machine
> and host machine.  I needed to pass options into gnatmake to work around this,
> and that required fixing some makefile rules to use $(GNATMAKE) instead of
> calling gnatmake directly.
> 
> Tested with native riscv-linux bootstrap with Ada enabled.
> 
> OK?

OK, thanks.

> Jim
> 
> 	gcc/ada/
> 	* Make-generated.in (treeprs.ads): Use $(GNATMAKE) instead of
> 	gnatmake.
> 	(einfo.h, sinfo.h, stamp-snames, stamp-nmake): Likewise.
> 	* gcc-interface/Makefile.in (xoscons): Likewise.
Jim Wilson July 6, 2018, 5:08 p.m. UTC | #2
On Fri, Jul 6, 2018 at 12:18 AM, Arnaud Charlet <charlet@adacore.com> wrote:
>> These are some patches I needed to complete my cross build of a native
>> riscv linux Ada compiler.  Some paths were different on the build machine
>> and host machine.  I needed to pass options into gnatmake to work around this,
>> and that required fixing some makefile rules to use $(GNATMAKE) instead of
>> calling gnatmake directly.
>>
>> Tested with native riscv-linux bootstrap with Ada enabled.
>>
>> OK?
>
> OK, thanks.
>
>> Jim
>>
>>       gcc/ada/
>>       * Make-generated.in (treeprs.ads): Use $(GNATMAKE) instead of
>>       gnatmake.
>>       (einfo.h, sinfo.h, stamp-snames, stamp-nmake): Likewise.
>>       * gcc-interface/Makefile.in (xoscons): Likewise.

Committed.

Jim
Andreas Schwab July 7, 2018, 7:25 a.m. UTC | #3
On Jul 05 2018, Jim Wilson <jimw@sifive.com> wrote:

> Tested with native riscv-linux bootstrap with Ada enabled.

I'm getting a lot of errors from the assembler "non-constant .uleb128 is
not supported" when trying to bootstrap the compiler with the
cross-compiled ada compiler.

Andreas.
Jim Wilson July 7, 2018, 3:32 p.m. UTC | #4
On Sat, Jul 7, 2018 at 12:25 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Jul 05 2018, Jim Wilson <jimw@sifive.com> wrote:
>
>> Tested with native riscv-linux bootstrap with Ada enabled.
>
> I'm getting a lot of errors from the assembler "non-constant .uleb128 is
> not supported" when trying to bootstrap the compiler with the
> cross-compiled ada compiler.

GCC configure assumes that if you have gas, then non-constant .uleb128
is OK.  However, because RISC-V deletes instructions at link time, we
cannot allow some forms of this construct.  If you have a working gas
available at gcc configure time, then it should do a gas run-time test
and discover that this gas feature does not work.  If you do not have
a working gas at gcc configure time, it will assume the feature is
available, try to use it, and then you get a build failure due to gas
errors.

The only time I've ever seen this error is if I try to use an
old-style combined-tree build approach, because in this case gcc
configures before gas is built.  If you build and install binutils,
and then build and install gcc, the build will work.  I haven't tried
to fix the old-style combined-tree approach, I didn't see an obvious
fix, and since I don't like to do builds this way anymore it wasn't
important enough to me to try to fix.

JIm
Andreas Schwab July 7, 2018, 5:06 p.m. UTC | #5
On Jul 07 2018, Jim Wilson <jimw@sifive.com> wrote:

> If you build and install binutils, and then build and install gcc, the
> build will work.

Not if the compiler was built in a canadian cross.  That's the only way
to bootstrap an Ada compiler.

Andreas.
Jim Wilson July 7, 2018, 5:40 p.m. UTC | #6
On Sat, Jul 7, 2018 at 10:06 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Jul 07 2018, Jim Wilson <jimw@sifive.com> wrote:
>
>> If you build and install binutils, and then build and install gcc, the
>> build will work.
>
> Not if the compiler was built in a canadian cross.  That's the only way
> to bootstrap an Ada compiler.

It worked for me.  I have RISC-V Fedora Linux Ada compiler binaries
that I built cross from an x86_64 Ubuntu 18.04 system.

You should only see the gas error if your gas sources are in the same
source tree as your gcc sources.  if you have separate binutils and
gcc source trees, the build should work.  In the gcc/configure.ac
file, see the in_tree_gas and in_tree_gas_elf variables, which are set
if gas/ELF gas are in the same source tree.  And then look at
configure, and note that configure makes assumptions about gas
features when these variables are set, instead of doing run-time
assembler checks.

I've done number of canadian cross compiler builds, and I've never run
into this gas problem in any of them, but I always use separate
binutils and gcc source trees for my builds.

Jim
Andreas Schwab July 7, 2018, 6:30 p.m. UTC | #7
On Jul 07 2018, Jim Wilson <jimw@sifive.com> wrote:

> You should only see the gas error if your gas sources are in the same
> source tree as your gcc sources.

Nope.

> if you have separate binutils and gcc source trees, the build should
> work.

It's not the canadian cross build that fails, but the subsequent native
build using the (misconfigured) canadian cross build.

Andreas.
Jim Wilson July 7, 2018, 8:41 p.m. UTC | #8
On Sat, Jul 7, 2018 at 11:30 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Jul 07 2018, Jim Wilson <jimw@sifive.com> wrote:
>> if you have separate binutils and gcc source trees, the build should
>> work.
>
> It's not the canadian cross build that fails, but the subsequent native
> build using the (misconfigured) canadian cross build.

This works for me.  I have a sysroot created from a live system.  I
configure/build/install a cross binutils, then cross gcc.  I put the
cross install tree on my path, then I configure/build/install the
canadian cross binutils and then gcc.  Then I copy the canadian cross
install tree to the RISC-V system and use it to bootstrap a native gcc
with Ada.

This is also presumably what the debian, fedora, and gentoo folks did
to get their first native compiler.  They didn't report any problems.

Is this the first time you are trying to build a native RISC-V
compiler for OpenSuse?  If you already built a C/C++ compiler, then I
would expect the Ada compiler build to work the same way.  But if this
is your first native RISC-V compiler build attempt then maybe there is
something different about how you are trying to do the build.  I could
share my build scripts with you but they are pretty simple.  It is
also possible to build a canadian cross compiler from github
riscv/riscv-gnu-toolchain using the linux-native makefile rule, but
since it has its own copy of glibc you might run into glibc versioning
problems.

One thing I could mention is that I started with a gcc-7.3 release,
because Ubuntu 18.04 has gcc-7.3 as the native compiler, and I wasn't
sure if gcc-7 Ada could build gcc-9 Ada.  Sometimes old Ada versions
can't compile new Ada versions.  So I actually did the canadian cross
build with binutils-2.30 and gcc-7.3.1, and then moved up from gcc-7
to gcc-9 on the RISC-V side.  I maybe haven't tried a canadian cross
build with a newer gcc version, so maybe something broke after gcc-7.
That seems unlikely though.

If you can give me details about exactly how you are trying to
canadian cross build the Ada compiler, I can try to reproduce your
problem here.

Jim
Andreas Schwab July 7, 2018, 9:43 p.m. UTC | #9
On Jul 07 2018, Jim Wilson <jimw@sifive.com> wrote:

> This is also presumably what the debian, fedora, and gentoo folks did
> to get their first native compiler.  They didn't report any problems.

Of course, they didn't build an ada compiler.

> Is this the first time you are trying to build a native RISC-V
> compiler for OpenSuse?

I have bootstrapped several architectures for SUSE and openSUSE, thank
you.

Andreas.
Jim Wilson July 7, 2018, 9:57 p.m. UTC | #10
On Sat, Jul 7, 2018 at 2:43 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Jul 07 2018, Jim Wilson <jimw@sifive.com> wrote:
>
>> This is also presumably what the debian, fedora, and gentoo folks did
>> to get their first native compiler.  They didn't report any problems.
>
> Of course, they didn't build an ada compiler.

But building an Ada compiler works exactly the same as building C and
C++ compilers.  There should really be no difference.

>> Is this the first time you are trying to build a native RISC-V
>> compiler for OpenSuse?
>
> I have bootstrapped several architectures for SUSE and openSUSE, thank
> you.

I am aware that you have much experience building stuff.  But building
RISC-V is a little different than the others, because of link-time
relaxations deleting code, which means some things that work for other
targets don't work for RISC-V.  It is possible that the scheme you are
using to build canadian cross compilers will work for other targets
but not RISC-V because of this problem.  That is why I asked if this
is your first attempt to canadian cross build a RISC-V native
compiler.  And because of the above, that building Ada should be no
different from building C and C++.

Anyways, all I can repeat is what I've said before.  It works for me.
I can give you my trivial build scripts if you want.  Otherwise, you
have to give me enough info that I can reproduce the problem that you
ran into.

Jim
Andreas Schwab July 7, 2018, 10 p.m. UTC | #11
On Jul 07 2018, Jim Wilson <jimw@sifive.com> wrote:

> But building an Ada compiler works exactly the same as building C and
> C++ compilers.  There should really be no difference.

That Ada compiler is unique in that it uses exceptions.

Andreas.
Pierre-Marie de Rodat Aug. 2, 2018, 8:44 a.m. UTC | #12
Hello Jim,

On 07/06/2018 01:45 AM, Jim Wilson wrote:
> These are some patches I needed to complete my cross build of a native
> riscv linux Ada compiler.  Some paths were different on the build machine
> and host machine.  I needed to pass options into gnatmake to work around this,
> and that required fixing some makefile rules to use $(GNATMAKE) instead of
> calling gnatmake directly.

At AdaCore, we realized that this patch broke our canadian builds: in 
the cases your patch involved, the intent is to call the build 
toolchain, not the host one (to which GNATMAKE expands to).

Given that you described this change as a workaround for cross-machine 
path issues, I was wondering: do you still need this? If not, we should 
probably revert it right now, otherwise we should investigate why you 
needed it in the first place. What do you think?
Jim Wilson Aug. 2, 2018, 2:44 p.m. UTC | #13
On Thu, Aug 2, 2018 at 1:44 AM, Pierre-Marie de Rodat
<derodat@adacore.com> wrote:
> On 07/06/2018 01:45 AM, Jim Wilson wrote:
>>
>> These are some patches I needed to complete my cross build of a native
>> riscv linux Ada compiler.  Some paths were different on the build machine
>> and host machine.  I needed to pass options into gnatmake to work around
>> this,
>> and that required fixing some makefile rules to use $(GNATMAKE) instead of
>> calling gnatmake directly.
>
>
> At AdaCore, we realized that this patch broke our canadian builds: in the
> cases your patch involved, the intent is to call the build toolchain, not
> the host one (to which GNATMAKE expands to).
>
> Given that you described this change as a workaround for cross-machine path
> issues, I was wondering: do you still need this? If not, we should probably
> revert it right now, otherwise we should investigate why you needed it in
> the first place. What do you think?

I only needed it for the first canadian cross build.  If it is causing
problems for you it can be dropped.  If I need it again, it is easy
enough to write again.

I ran into a problem where the search paths were wrong when running
the canadian cross built compiler for the native build, and I had to
add something like -cargs -L$installdir/lib to gnatmake to make it
work, but it is possible I did something wrong.  These canadian cross
builds aren't something I do often, so I might have made a mistake.
Also, RISC-V is a new target, so there are lots of things that are
just a little broken and have to be worked around.  This might have
been related to one of those problems.

Jim
Pierre-Marie de Rodat Aug. 3, 2018, 1:23 p.m. UTC | #14
On 08/02/2018 04:44 PM, Jim Wilson wrote:
> I only needed it for the first canadian cross build.  If it is causing
> problems for you it can be dropped.  If I need it again, it is easy
> enough to write again.

Ok, thank you! I’ve just committed the revert.

> I ran into a problem where the search paths were wrong when running
> the canadian cross built compiler for the native build, and I had to
> add something like -cargs -L$installdir/lib to gnatmake to make it
> work, but it is possible I did something wrong.  These canadian cross
> builds aren't something I do often, so I might have made a mistake.
> Also, RISC-V is a new target, so there are lots of things that are
> just a little broken and have to be worked around.  This might have
> been related to one of those problems.

Understood, thank you for the context. Let’s try to fix the underlying 
problem if you have issues with canadian crosses again. :-)
Andreas Schwab Aug. 3, 2018, 3:05 p.m. UTC | #15
On Aug 03 2018, Pierre-Marie de Rodat <derodat@adacore.com> wrote:

> Understood, thank you for the context. Let’s try to fix the underlying
> problem if you have issues with canadian crosses again. :-)

There should at least be a way to find the build gnatmake under a
different name.

Andreas.
diff mbox series

Patch

diff --git a/gcc/ada/Make-generated.in b/gcc/ada/Make-generated.in
index 757eaa85b90..bdcb62c4e56 100644
--- a/gcc/ada/Make-generated.in
+++ b/gcc/ada/Make-generated.in
@@ -28,21 +28,21 @@  $(ADA_GEN_SUBDIR)/treeprs.ads : $(ADA_GEN_SUBDIR)/treeprs.adt $(ADA_GEN_SUBDIR)/
 	-$(MKDIR) $(ADA_GEN_SUBDIR)/bldtools/treeprs
 	$(RM) $(addprefix $(ADA_GEN_SUBDIR)/bldtools/treeprs/,$(notdir $^))
 	$(CP) $^ $(ADA_GEN_SUBDIR)/bldtools/treeprs
-	(cd $(ADA_GEN_SUBDIR)/bldtools/treeprs; gnatmake -q xtreeprs ; ./xtreeprs treeprs.ads )
+	(cd $(ADA_GEN_SUBDIR)/bldtools/treeprs; $(GNATMAKE) -q xtreeprs ; ./xtreeprs treeprs.ads )
 	$(MOVE_IF_CHANGE) $(ADA_GEN_SUBDIR)/bldtools/treeprs/treeprs.ads $(ADA_GEN_SUBDIR)/treeprs.ads
 
 $(ADA_GEN_SUBDIR)/einfo.h : $(ADA_GEN_SUBDIR)/einfo.ads $(ADA_GEN_SUBDIR)/einfo.adb $(ADA_GEN_SUBDIR)/xeinfo.adb $(ADA_GEN_SUBDIR)/ceinfo.adb
 	-$(MKDIR) $(ADA_GEN_SUBDIR)/bldtools/einfo
 	$(RM) $(addprefix $(ADA_GEN_SUBDIR)/bldtools/einfo/,$(notdir $^))
 	$(CP) $^ $(ADA_GEN_SUBDIR)/bldtools/einfo
-	(cd $(ADA_GEN_SUBDIR)/bldtools/einfo; gnatmake -q xeinfo ; ./xeinfo einfo.h )
+	(cd $(ADA_GEN_SUBDIR)/bldtools/einfo; $(GNATMAKE) -q xeinfo ; ./xeinfo einfo.h )
 	$(MOVE_IF_CHANGE) $(ADA_GEN_SUBDIR)/bldtools/einfo/einfo.h $(ADA_GEN_SUBDIR)/einfo.h
 
 $(ADA_GEN_SUBDIR)/sinfo.h : $(ADA_GEN_SUBDIR)/sinfo.ads $(ADA_GEN_SUBDIR)/sinfo.adb $(ADA_GEN_SUBDIR)/xsinfo.adb $(ADA_GEN_SUBDIR)/csinfo.adb
 	-$(MKDIR) $(ADA_GEN_SUBDIR)/bldtools/sinfo
 	$(RM) $(addprefix $(ADA_GEN_SUBDIR)/bldtools/sinfo/,$(notdir $^))
 	$(CP) $^ $(ADA_GEN_SUBDIR)/bldtools/sinfo
-	(cd $(ADA_GEN_SUBDIR)/bldtools/sinfo; gnatmake -q xsinfo ; ./xsinfo sinfo.h )
+	(cd $(ADA_GEN_SUBDIR)/bldtools/sinfo; $(GNATMAKE) -q xsinfo ; ./xsinfo sinfo.h )
 	$(MOVE_IF_CHANGE) $(ADA_GEN_SUBDIR)/bldtools/sinfo/sinfo.h $(ADA_GEN_SUBDIR)/sinfo.h
 
 $(ADA_GEN_SUBDIR)/snames.h $(ADA_GEN_SUBDIR)/snames.ads $(ADA_GEN_SUBDIR)/snames.adb : $(ADA_GEN_SUBDIR)/stamp-snames ; @true
@@ -50,7 +50,7 @@  $(ADA_GEN_SUBDIR)/stamp-snames : $(ADA_GEN_SUBDIR)/snames.ads-tmpl $(ADA_GEN_SUB
 	-$(MKDIR) $(ADA_GEN_SUBDIR)/bldtools/snamest
 	$(RM) $(addprefix $(ADA_GEN_SUBDIR)/bldtools/snamest/,$(notdir $^))
 	$(CP) $^ $(ADA_GEN_SUBDIR)/bldtools/snamest
-	(cd $(ADA_GEN_SUBDIR)/bldtools/snamest; gnatmake -q xsnamest ; ./xsnamest )
+	(cd $(ADA_GEN_SUBDIR)/bldtools/snamest; $(GNATMAKE) -q xsnamest ; ./xsnamest )
 	$(MOVE_IF_CHANGE) $(ADA_GEN_SUBDIR)/bldtools/snamest/snames.ns $(ADA_GEN_SUBDIR)/snames.ads
 	$(MOVE_IF_CHANGE) $(ADA_GEN_SUBDIR)/bldtools/snamest/snames.nb $(ADA_GEN_SUBDIR)/snames.adb
 	$(MOVE_IF_CHANGE) $(ADA_GEN_SUBDIR)/bldtools/snamest/snames.nh $(ADA_GEN_SUBDIR)/snames.h
@@ -61,7 +61,7 @@  $(ADA_GEN_SUBDIR)/stamp-nmake: $(ADA_GEN_SUBDIR)/sinfo.ads $(ADA_GEN_SUBDIR)/nma
 	-$(MKDIR) $(ADA_GEN_SUBDIR)/bldtools/nmake
 	$(RM) $(addprefix $(ADA_GEN_SUBDIR)/bldtools/nmake/,$(notdir $^))
 	$(CP) $^ $(ADA_GEN_SUBDIR)/bldtools/nmake
-	(cd $(ADA_GEN_SUBDIR)/bldtools/nmake; gnatmake -q xnmake ; ./xnmake -b nmake.adb ; ./xnmake -s nmake.ads)
+	(cd $(ADA_GEN_SUBDIR)/bldtools/nmake; $(GNATMAKE) -q xnmake ; ./xnmake -b nmake.adb ; ./xnmake -s nmake.ads)
 	$(MOVE_IF_CHANGE) $(ADA_GEN_SUBDIR)/bldtools/nmake/nmake.ads $(ADA_GEN_SUBDIR)/nmake.ads
 	$(MOVE_IF_CHANGE) $(ADA_GEN_SUBDIR)/bldtools/nmake/nmake.adb $(ADA_GEN_SUBDIR)/nmake.adb
 	touch $(ADA_GEN_SUBDIR)/stamp-nmake
diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in
index 9a52e6d8edb..601f23afc1c 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -613,7 +613,7 @@  OSCONS_EXTRACT=$(OSCONS_CC) $(GNATLIBCFLAGS_FOR_C) -S s-oscons-tmplt.i
 	-$(MKDIR) ./bldtools/oscons
 	$(RM) $(addprefix ./bldtools/oscons/,$(notdir $^))
 	$(CP) $^ ./bldtools/oscons
-	(cd ./bldtools/oscons ; gnatmake -q xoscons)
+	(cd ./bldtools/oscons ; $(GNATMAKE) -q xoscons)
 
 $(RTSDIR)/s-oscons.ads: ../stamp-gnatlib1-$(RTSDIR) s-oscons-tmplt.c gsocket.h ./bldtools/oscons/xoscons
 	$(RM) $(RTSDIR)/s-oscons-tmplt.i $(RTSDIR)/s-oscons-tmplt.s