GNATBind with a GNAT cross‑compiler

GNATBind with a GNAT cross‑compiler

[Yannick Duchêne (Hibou57)]

Hi people,

While trying to figure the cause of some weird errors while compiling with  
a GNAT cross‑compiler, I noticed the wrong GPRBind was invoked (not  
matching the target).

I fixed this using

     for Switches ("Ada") use ("--gnatbind_path=/…/<target>-gnatbind");

… in the Builder package of the project file, which can also be made a  
default editing a `*.cgpr` file or one of the files of the GPRConfig  
database.

Then I noticed there is a `<target>-gcc`, and a `<target>-ld`  and so on,  
for each of my targets including the native one, but only a  
`<target>-gnatbind` for non‑native target, and the native one only exist  
as unprefixed.

So I will rename all non‑prefixed GNAT tools to give them a target prefix  
and will remove the default (with all non‑prefix named tools) GNAT  
compiler suite to only have the ones I compiled, so that I will always get  
an error whenever any one of these tools is unfortunately invoked using a  
non‑prefixed name, which is error‑prone as this is likely to not be the  
one for the target.

I don't really have any question, that's just to tell people in case any  
one encounter a similar issue. I still wonder why, as compilation of GCC  
and Binutils generates a prefixed version of all of their tools, why don't  
compilation of GNAT do the same.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: GNATBind with a GNAT cross‑compiler

[Brian Drummond]

On Thu, 25 Apr 2013 05:07:18 +0200, Yannick Duchêne (Hibou57) wrote:

> Hi people,
> 
> While trying to figure the cause of some weird errors while compiling
> with a GNAT cross‑compiler, 
[...] 
> I noticed there is a `<target>-gcc`, and a `<target>-ld`  and so
> on, for each of my targets including the native one, but only a
> `<target>-gnatbind` for non‑native target, and the native one only exist
> as unprefixed.

> I don't really have any question, that's just to tell people in case any
> one encounter a similar issue. I still wonder why, as compilation of GCC
> and Binutils generates a prefixed version of all of their tools, why
> don't compilation of GNAT do the same.

Where did this crosscompiler come from?

My non-native target builds have the full set of tools. However...

If you built it from source, with --disable-libada, you may have fallen 
foul of a longstanding GCC "feature" whereby building "gnattools" is also 
(I believe incorrectly) disabled by this configure option.

This leaves you with "<target>-gnat" and ""<target>-gnatbind" but 
"<target>-gnat*" for other values of * are missing. (You should still 
have "<target>-ld" though; it is a binutils product : perhaps it was 
"<target>-gnatlink" that was missing?)

Possible fixes : 
after "make" when building the crosscompiler, "make -c gcc gnattools" may 
build the remaining targets for you. 

If that protests, then you may need to patch the gcc "configure" file to 
allow the missing targets to be built, as in the following patch.

http://sourceforge.net/p/msp430ada/code/ci/tip/tree/patches/23-gcc-4.7-
ada-Makefile.patch

found on

http://sourceforge.net/p/msp430ada/code/ci/tip/tree/patches/

Having applied the patch, obviously you need to re-run configure/make/
[make gnattools if utils missing in build dir]/make install. 

(The AVR-Ada project has also faced this issue with essentially the same 
solution. Some upstream gcc discussion on 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19959 )

If you try this and it works - or if and how it fails - it would be 
useful to follow up.

Re: GNATBind with a GNAT cross‑compiler

[Yannick Duchêne (Hibou57)]

Le Thu, 25 Apr 2013 12:46:09 +0200, Brian Drummond  
<brian@shapes.demon.co.uk> a écrit:

> If that protests, then you may need to patch the gcc "configure" file to
> allow the missing targets to be built, as in the following patch.
>
> http://sourceforge.net/p/msp430ada/code/ci/tip/tree/patches/23-gcc-4.7-
> ada-Makefile.patch
>
> found on
>
> http://sourceforge.net/p/msp430ada/code/ci/tip/tree/patches/
>
> Having applied the patch, obviously you need to re-run configure/make/
> [make gnattools if utils missing in build dir]/make install.
>
> (The AVR-Ada project has also faced this issue with essentially the same
> solution. Some upstream gcc discussion on
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19959 )
>
> If you try this and it works - or if and how it fails - it would be
> useful to follow up.

Something in part out‑of‑topic…

I will finally test the patch you mentioned, because I may have to  
recompile the compilers to fix GNATBind, as I'm having an issue when  
`Suppress_Standard_Library` from package `System` is set to `True`; I  
receive a complaint about an undefined reference to `Is_Elaborated`. Seems  
there is an inconsistency here in GNAT FSF. Explanation: I've found [1],  
which is a patch to drop the generation of the `Is_Elaborated` variable  
when `Suppress_Standard_Library` is `True`, arguing it was never  
referenced; except this may be not referenced with GNAT GPL or GNAT Pro  
(just guessing), but it is referenced for me with FSF GNAT [2].

So as I will have to disable the patch from [1], I will get an opportunity  
to test the patch to `configure` you suggest in the while.


[1]: http://patchwork.ozlabs.org/patch/194962/

[2]: Here is what gets generated by GNATBind from FSF GNAT:

     procedure adafinal is
        procedure s_stalib_adafinal;
        pragma Import (C, s_stalib_adafinal,  
"system__standard_library__adafinal");
     begin
        if not Is_Elaborated then -- << Here
           return;
        end if;
        Is_Elaborated := False; -- << And here
        s_stalib_adafinal;
     end adafinal;

     procedure adainit is
     begin
        null;

     end adainit;

Then it complains “"Is_Elaborated" is undefined (more references follow)”  
when compiling the files generated by GNATBind.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: GNATBind with a GNAT cross‑compiler

[Yannick Duchêne (Hibou57)]

Le Fri, 26 Apr 2013 22:59:19 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> I will finally test the patch you mentioned, because I may have to  
> recompile the compilers to fix GNATBind, as I'm having an issue when  
> `Suppress_Standard_Library` from package `System` is set to `True`; I  
> receive a complaint about an undefined reference to `Is_Elaborated`.  
> Seems there is an inconsistency here in GNAT FSF.

The patch you suggested changed nothing. I will finally go on using a  
renaming script to be applied to the built applications whose target is  
that of the host. Just for a sample, the two script I run from  
`<prefix>/bin` are attached to this message.

Then, for the undefined reference to `Is_Elaborated`, I've not reverted  
the patch from AdaCore, but instead created a supplementary patch. After a  
quick review of `bindgen.adb`, it appears there was indeed an  
inconsistency, precisely between `procedure Generateadainit` and  
`Generateadafinal`. As an attached file, is the patch  
`gcc-4.8-ada-bindgen.adb.patch` (also attached, is the patch you  
suggested, for GCC 4.8 instead of for GCC 4.7).

I may propose the `gcc-4.8-ada-bindgen.adb.patch` patch to the GCC mailing  
list.

P.S. Seems nntp.aioe.org does not allow attachments, so here are the  
attachments as a downloadable archive:
http://www.les-ziboux.rasama.org/download/2013-04-27-cla-attachments.zip

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: GNATBind with a GNAT cross‑compiler

[Yannick Duchêne (Hibou57)]

Le Sat, 27 Apr 2013 01:24:29 +0200, Yannick Duchêne (Hibou57)
<yannick_duchene@yahoo.fr> a écrit:
> http://www.les-ziboux.rasama.org/download/2013-04-27-cla-attachments.zip

I've updated the patch so that it fix two other erroneous references to  
the `System.Standard_Library` when `Suppress_Standard_Library_On_Target =  
True`, still in `bindgen.adb`.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: GNATBind with a GNAT cross‑compiler

[Brian Drummond]

On Sat, 27 Apr 2013 01:24:29 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Fri, 26 Apr 2013 22:59:19 +0200, Yannick Duchêne (Hibou57)
> <yannick_duchene@yahoo.fr> a écrit:

> The patch you suggested changed nothing. I will finally go on using a
> renaming script to be applied to the built applications whose target is
> that of the host. Just for a sample, the two script I run from
> `<prefix>/bin` are attached to this message.

It was for the earlier problem (unbuilt tools) not the undefined 
references you mentioned later. As you appear to be building 4.8, maybe 
it is no longer an issue, or maybe it will be once the other issues ahve 
been resolved.

> P.S. Seems nntp.aioe.org does not allow attachments, so here are the
> attachments as a downloadable archive:
> http://www.les-ziboux.rasama.org/download/2013-04-27-cla-attachments.zip

I will keep these patches in mind when I start to play with 4.8. Thanks.

- Brian