Re: gnat compiler issues with a partial build

[jan.de.kruyf@gmail.com]

On Thursday, June 11, 2015 at 7:01:25 AM UTC+2, Simon Wright wrote:


> 
> In my opinion, this approach is *exactly* why you are having problems.

Since when is it, that when I point out something in the tools that does not seem kosher (or perhaps is not documented) that I ought to have a problem?

The issue I had, I have solved for myself long ago, because I do know my tools. 
And when it proves I dont, I will strive to get to know them better.

> 
> Since you aren't doing that, the compiler looks at the code you are
> working on, including the parts that should be in the RTS. 

Yes.

> it will look in the RTS it is in fact compiling
> against, which in your case is the Linux GNAT GPL 2014 RTS, 

No, for that it needs a library (or RTS as we call it in Ada). I have made sure it is not there, by setting the RTS essentially to null in the project file. And I  have tried to inform the compiler of that fact. 
But apparently I failed or there is a bug in the compiler.

> and generate
> code that expects to find those features at link time.

Possible, but the documentation as it stands says it ought not, if one uses the right restrictions. What is more, the arm cross environment does not suffer of it, according to Mark L. 
And in the olden days we had "No Runtime", which means exactly that.
Today gnat says that we can imitate that with the right restrictions etc.

> 
> (2) work in an RTS framework, as I have described, and write your own
> System.Memory. I think you can get away with the standard spec and just
> modify the body (to use the same bindings as you'd have written for
> (1)).

You have a wrong understanding of an RTS.

It is a collection of source files that are compiled and partially linked into a library.
This library is then linked with the final customer program (when it is a static lib) to make the executable. 
It is nothing more and also nothing less.
And where the firewall between the 2 lies is entirely unimportant. The linker just wants the symbols it needs in other parts of the program.

So I fail to see how an extra layer of obfuscation will make this issue (of wrong or accidental code go away. 
On the contrary _understanding the tools better_, including their failings will clear this issue up.

The issue is not my runtime (or immitation of it) The issue is that the compiler produces symbols that _ARE NOT_ in the ravenscar profile for arm.
Although I set all the switches to immitate that compile environment. (At least I hope I did).

Thanks for listening to me,

j.