Inspirels Ada on cortex tutorial linker issue

Inspirels Ada on cortex tutorial linker issue

[Devin]

Hello, 

I am just getting started with Ada, and I am going through the Inspirel Ada on Cortex m tutorial.

I am trying to get my environment setup, and I am using an Orange pi pc running armbian as the OS.  It is an arm based single board computer, so I should be able to use the compiler and linker tools natively, at least that is what I am understanding from the chapter of the tutorial.

I am able to compile the program from the "First Program" chapter of the tutorial without errors, but when I attempt to link the program I get an error reading:

program.o:(.ARM.exidx+0x0): undefined reference to '__aeabi_unwind_cpp_pr0'

The linker command I am using is:

ld -T flash.ld -o program.elf program.o

Thank you for the help, and as I said, I am very new to this so I apologize if I am leaving out any information that I should be providing.

Re: Inspirels Ada on cortex tutorial linker issue

[Simon Wright]

Devin <devin.inspiredby@gmail.com> writes:

> I am trying to get my environment setup, and I am using an Orange pi
> pc running armbian as the OS.  It is an arm based single board
> computer, so I should be able to use the compiler and linker tools
> natively, at least that is what I am understanding from the chapter of
> the tutorial.
>
> I am able to compile the program from the "First Program" chapter of
> the tutorial without errors, but when I attempt to link the program I
> get an error reading:
>
> program.o:(.ARM.exidx+0x0): undefined reference to '__aeabi_unwind_cpp_pr0'

That's to do with exception handling. It seems that your armbian
compiler has inserted exception handling code that's not inserted by the
raspbian compiler. I'd expect some trace of this in the program.s file
described in the tutorial.

When I compile (using -S to generate program.s) with an arm-eabi
cross-compiler on this Mac, I get something that's almost the same as
the tutorial. When I compile with the native compiler, aside from the
obvious difference that it's x86_64 code, there is exception handling
code in there.

It's possible that this is because of different configuration options in
system.ads. Before we go too far down that route, can anyone report on
experience using raspbian/armbian?

Re: Inspirels Ada on cortex tutorial linker issue

[Devin]

On Saturday, July 23, 2016 at 2:57:22 AM UTC-4, Simon Wright wrote:
> Devin writes:
> 
> > I am trying to get my environment setup, and I am using an Orange pi
> > pc running armbian as the OS.  It is an arm based single board
> > computer, so I should be able to use the compiler and linker tools
> > natively, at least that is what I am understanding from the chapter of
> > the tutorial.
> >
> > I am able to compile the program from the "First Program" chapter of
> > the tutorial without errors, but when I attempt to link the program I
> > get an error reading:
> >
> > program.o:(.ARM.exidx+0x0): undefined reference to '__aeabi_unwind_cpp_pr0'
> 
> That's to do with exception handling. It seems that your armbian
> compiler has inserted exception handling code that's not inserted by the
> raspbian compiler. I'd expect some trace of this in the program.s file
> described in the tutorial.
> 
> When I compile (using -S to generate program.s) with an arm-eabi
> cross-compiler on this Mac, I get something that's almost the same as
> the tutorial. When I compile with the native compiler, aside from the
> obvious difference that it's x86_64 code, there is exception handling
> code in there.
> 
> It's possible that this is because of different configuration options in
> system.ads. Before we go too far down that route, can anyone report on
> experience using raspbian/armbian?

Thanks for the info.  After looking closer, there are definitely differences in the output of my program.s file, so I think you may be on to something there.

Re: Inspirels Ada on cortex tutorial linker issue

[Devin]

On Saturday, July 23, 2016 at 9:34:10 AM UTC+2, Devin wrote:
> On Saturday, July 23, 2016 at 2:57:22 AM UTC-4, Simon Wright wrote:
> > Devin writes:
> > 
> > > I am trying to get my environment setup, and I am using an Orange pi
> > > pc running armbian as the OS.  It is an arm based single board
> > > computer, so I should be able to use the compiler and linker tools
> > > natively, at least that is what I am understanding from the chapter of
> > > the tutorial.
> > >
> > > I am able to compile the program from the "First Program" chapter of
> > > the tutorial without errors, but when I attempt to link the program I
> > > get an error reading:
> > >
> > > program.o:(.ARM.exidx+0x0): undefined reference to '__aeabi_unwind_cpp_pr0'
> > 
> > That's to do with exception handling. It seems that your armbian
> > compiler has inserted exception handling code that's not inserted by the
> > raspbian compiler. I'd expect some trace of this in the program.s file
> > described in the tutorial.
> > 
> > When I compile (using -S to generate program.s) with an arm-eabi
> > cross-compiler on this Mac, I get something that's almost the same as
> > the tutorial. When I compile with the native compiler, aside from the
> > obvious difference that it's x86_64 code, there is exception handling
> > code in there.
> > 
> > It's possible that this is because of different configuration options in
> > system.ads. Before we go too far down that route, can anyone report on
> > experience using raspbian/armbian?
> 
> Thanks for the info.  After looking closer, there are definitely differences in the output of my program.s file, so I think you may be on to something there.

Here is the output in my program.s:

	.cpu cortex-m0
	.fpu softvfp
	.eabi_attribute 20, 1
	.eabi_attribute 21, 1
	.eabi_attribute 23, 3
	.eabi_attribute 24, 1
	.eabi_attribute 25, 1
	.eabi_attribute 26, 2
	.eabi_attribute 30, 6
	.eabi_attribute 34, 0
	.code	16
	.file	"program.adb"
	.global	program_E
	.data
	.align	1
	.type	program_E, %object
	.size	program_E, 2
program_E:
	.space	2
	.text
	.align	2
	.global	run
	.code	16
	.thumb_func
	.type	run, %function
run:
	.fnstart
.LFB2:
	push	{r7, lr}
	.save {r7, lr}
	.setfp r7, sp, #0
	add	r7, sp, #0
.L3:
	mov	r8, r8
	b	.L3
	.fnend
	.size	run, .-run
	.ident	"GCC: (Debian 4.9.2-1) 4.9.2"
	.section	.note.GNU-stack,"",%progbits

Re: Inspirels Ada on cortex tutorial linker issue

[Simon Wright]

Devin <devin.inspiredby@gmail.com> writes:

> On Saturday, July 23, 2016 at 9:34:10 AM UTC+2, Devin wrote:
>> On Saturday, July 23, 2016 at 2:57:22 AM UTC-4, Simon Wright wrote:
>> > Devin writes:
>> > 
>> > > I am trying to get my environment setup, and I am using an Orange pi
>> > > pc running armbian as the OS.  It is an arm based single board
>> > > computer, so I should be able to use the compiler and linker tools
>> > > natively, at least that is what I am understanding from the chapter of
>> > > the tutorial.
>> > >
>> > > I am able to compile the program from the "First Program" chapter of
>> > > the tutorial without errors, but when I attempt to link the program I
>> > > get an error reading:
>> > >
>> > > program.o:(.ARM.exidx+0x0): undefined reference to
>> > > '__aeabi_unwind_cpp_pr0'

> Here is the output in my program.s:
>
> 	.cpu cortex-m0
> 	.fpu softvfp
> 	.eabi_attribute 20, 1
> 	.eabi_attribute 21, 1
> 	.eabi_attribute 23, 3
> 	.eabi_attribute 24, 1
> 	.eabi_attribute 25, 1
> 	.eabi_attribute 26, 2
> 	.eabi_attribute 30, 6
> 	.eabi_attribute 34, 0
> 	.code	16
> 	.file	"program.adb"
> 	.global	program_E
> 	.data
> 	.align	1
> 	.type	program_E, %object
> 	.size	program_E, 2
> program_E:
> 	.space	2
> 	.text
> 	.align	2
> 	.global	run
> 	.code	16
> 	.thumb_func
> 	.type	run, %function
> run:
> 	.fnstart
> .LFB2:
> 	push	{r7, lr}
> 	.save {r7, lr}
> 	.setfp r7, sp, #0
> 	add	r7, sp, #0
> .L3:
> 	mov	r8, r8
> 	b	.L3
> 	.fnend
> 	.size	run, .-run
> 	.ident	"GCC: (Debian 4.9.2-1) 4.9.2"
> 	.section	.note.GNU-stack,"",%progbits

Strange. There's nothing in there to reference
__aeabi_unwind_cpp_pr0. Does "nm program.o" show a reference?

Umm, I suppose you did actually recompile the program to produce an
object file and it's not some old program.o left lying around?

Re: Inspirels Ada on cortex tutorial linker issue

[Devin]

On Saturday, July 23, 2016 at 12:32:09 PM UTC-4, Simon Wright wrote:
> Devin writes:
> 
> > On Saturday, July 23, 2016 at 9:34:10 AM UTC+2, Devin wrote:
> >> On Saturday, July 23, 2016 at 2:57:22 AM UTC-4, Simon Wright wrote:
> >> > Devin writes:
> >> > 
> >> > > I am trying to get my environment setup, and I am using an Orange pi
> >> > > pc running armbian as the OS.  It is an arm based single board
> >> > > computer, so I should be able to use the compiler and linker tools
> >> > > natively, at least that is what I am understanding from the chapter of
> >> > > the tutorial.
> >> > >
> >> > > I am able to compile the program from the "First Program" chapter of
> >> > > the tutorial without errors, but when I attempt to link the program I
> >> > > get an error reading:
> >> > >
> >> > > program.o:(.ARM.exidx+0x0): undefined reference to
> >> > > '__aeabi_unwind_cpp_pr0'
> 
> > Here is the output in my program.s:
> >
> > 	.cpu cortex-m0
> > 	.fpu softvfp
> > 	.eabi_attribute 20, 1
> > 	.eabi_attribute 21, 1
> > 	.eabi_attribute 23, 3
> > 	.eabi_attribute 24, 1
> > 	.eabi_attribute 25, 1
> > 	.eabi_attribute 26, 2
> > 	.eabi_attribute 30, 6
> > 	.eabi_attribute 34, 0
> > 	.code	16
> > 	.file	"program.adb"
> > 	.global	program_E
> > 	.data
> > 	.align	1
> > 	.type	program_E, %object
> > 	.size	program_E, 2
> > program_E:
> > 	.space	2
> > 	.text
> > 	.align	2
> > 	.global	run
> > 	.code	16
> > 	.thumb_func
> > 	.type	run, %function
> > run:
> > 	.fnstart
> > .LFB2:
> > 	push	{r7, lr}
> > 	.save {r7, lr}
> > 	.setfp r7, sp, #0
> > 	add	r7, sp, #0
> > .L3:
> > 	mov	r8, r8
> > 	b	.L3
> > 	.fnend
> > 	.size	run, .-run
> > 	.ident	"GCC: (Debian 4.9.2-1) 4.9.2"
> > 	.section	.note.GNU-stack,"",%progbits
> 
> Strange. There's nothing in there to reference
> __aeabi_unwind_cpp_pr0. Does "nm program.o" show a reference?
> 
> Umm, I suppose you did actually recompile the program to produce an
> object file and it's not some old program.o left lying around?

Yes, after looking at the assembly, I recompiled using:
$ gcc -c -mcpu=cortex-m0 -mthumb -mfloat-abi=soft program.adb

From the looks of it, the exception handling is added at compile time when making the program.o file?  Would I be able to edit system.ads to turn off exception handling?

Re: Inspirels Ada on cortex tutorial linker issue

[Simon Wright]

Devin <devin.inspiredby@gmail.com> writes:

> Yes, after looking at the assembly, I recompiled using:
> $ gcc -c -mcpu=cortex-m0 -mthumb -mfloat-abi=soft program.adb
>
> From the looks of it, the exception handling is added at compile time
> when making the program.o file?  Would I be able to edit system.ads to
> turn off exception handling?

It turns out that it's the .fnstart/.fnend assembler directives.

It is indeed system.ads that needs changing, but I'd strongly advise not
editing the installed one (unless you never intend to compile Ada for
the Pi natively!).

I've been playing around with my own native system.ads and I can't see
what needs to be tweaked. However, if I create a minimal runtime system
using one of the AdaCore-supplied ARM system.ads's
(ravenscar-sfp-stm32f4/arch, to be exact) the offending asm constructs
don't appear.

To create this minimal RTS you need
* a directory, say rts/
* containing an empty directory adalib/
* and a directory adainclude/ containing the system.ads to be used.

Then compile with this RTS:

 $ gcc --RTS=rts -c -u -f -mcpu=cortex-m0 -mthumb -mfloat-abi=soft program.adb

I've put a copy of the RTS I used at
https://www.dropbox.com/s/iyff5ir5bl41hpd/rts.tar.gz?dl=0

Hope this works for you!

Re: Inspirels Ada on cortex tutorial linker issue

[Devin]

On Sunday, July 24, 2016 at 9:41:17 AM UTC+2, Simon Wright wrote:
> Devin writes:
> 
> > Yes, after looking at the assembly, I recompiled using:
> > $ gcc -c -mcpu=cortex-m0 -mthumb -mfloat-abi=soft program.adb
> >
> > From the looks of it, the exception handling is added at compile time
> > when making the program.o file?  Would I be able to edit system.ads to
> > turn off exception handling?
> 
> It turns out that it's the .fnstart/.fnend assembler directives.
> 
> It is indeed system.ads that needs changing, but I'd strongly advise not
> editing the installed one (unless you never intend to compile Ada for
> the Pi natively!).
> 
> I've been playing around with my own native system.ads and I can't see
> what needs to be tweaked. However, if I create a minimal runtime system
> using one of the AdaCore-supplied ARM system.ads's
> (ravenscar-sfp-stm32f4/arch, to be exact) the offending asm constructs
> don't appear.
> 
> To create this minimal RTS you need
> * a directory, say rts/
> * containing an empty directory adalib/
> * and a directory adainclude/ containing the system.ads to be used.
> 
> Then compile with this RTS:
> 
>  $ gcc --RTS=rts -c -u -f -mcpu=cortex-m0 -mthumb -mfloat-abi=soft program.adb
> 
> I've put a copy of the RTS I used at
> https://www.dropbox.com/s/iyff5ir5bl41hpd/rts.tar.gz?dl=0
> 
> Hope this works for you!

That got me quite a bit further to getting it running.  I did have to comment out a line:

pragma Restrictions (No_Task_At_Interrupt_Priority);

in order to get it to compile, it causes an error:

fatal error: system.ads is incorrectly formatted
unrecognized or incorrect restrictions pragma: No_Task_At_Interrupt_Priority
compilation abandoned

If I comment the line out, it compiles and links fine (but I can not get openOCD to load the firmware to the Nucleo32).

In openocd I get a warning saying that there are no flash banks found for addresses 10000000 and 10000100 and it says it writes 0 bytes from file program.bin and resets the target.  The Nucleo32 then starts running the same firmware that it shipped with.

Thank you very much for all your help, Simon.

Re: Inspirels Ada on cortex tutorial linker issue

[Simon Wright]

Devin <devin.inspiredby@gmail.com> writes:

> pragma Restrictions (No_Task_At_Interrupt_Priority);
>
> in order to get it to compile, it causes an error:
>
> fatal error: system.ads is incorrectly formatted
> unrecognized or incorrect restrictions pragma: No_Task_At_Interrupt_Priority
> compilation abandoned

That's a GNAT implementation-defined restriction.

Interrupt and task priorities are different things even if the ARM
makes them numerically adjacent.

> In openocd I get a warning saying that there are no flash banks found
> for addresses 10000000 and 10000100 and it says it writes 0 bytes from
> file program.bin and resets the target.  The Nucleo32 then starts
> running the same firmware that it shipped with.

I haven't used openocd, so no ideas.

> Thank you very much for all your help, Simon.

That's OK!

Re: Inspirels Ada on cortex tutorial linker issue

[Maciej Sobczak]

> I am able to compile the program from the "First Program" chapter of the tutorial without errors, but when I attempt to link the program I get an error reading:
> 
> program.o:(.ARM.exidx+0x0): undefined reference to '__aeabi_unwind_cpp_pr0'

Sorry for being late to the discussion.
I was able to reproduce this problem and after browsing through some threads on the net, I understand that the newest and greatest gcc compilers automatically add references to exception handling routines even in C code. Apparently there *might* be some obscure integration cases where this automatic injection can help (especially in those projects that mix C and C++), but it is a pity that the "feature" is unconditional. Or at least I was not able to find any option to switch it off.

In any case, I was able to solve the problem by adding the following in any .adb file (for the first program example you can add it to program.adb, but I would recommend moving it to utils.adb or even to some additional file, created only for this purpose):

   procedure Dummy_aeabi_unwind_cpp_pr0;
   pragma Export (C, Dummy_aeabi_unwind_cpp_pr0, "__aeabi_unwind_cpp_pr0");
   
   procedure Dummy_aeabi_unwind_cpp_pr1;
   pragma Export (C, Dummy_aeabi_unwind_cpp_pr1, "__aeabi_unwind_cpp_pr1");
   
   procedure Dummy_aeabi_unwind_cpp_pr0 is
   begin
      null;
   end Dummy_aeabi_unwind_cpp_pr0;
   
   procedure Dummy_aeabi_unwind_cpp_pr1 is
   begin
      null;
   end Dummy_aeabi_unwind_cpp_pr1;

That's it. These procedures will never be called in a pure Ada program, but they make the linker happy. Yes, it'd kind of silly, and I hope that future versions of gcc will have a nice option to switch this nuisance off.

> The linker command I am using is:
> 
> ld -T flash.ld -o program.elf program.o

This command will still work if you put the code above in program.adb, for example after the Run procedure.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Inspirels Ada on cortex tutorial linker issue

[Devin]

I appreciate your help! 

I added the procedures into a file called noexceptionhandling.adb and noexceptionhandling.ads, and added: 
with noexceptionhandling;

to the beginning of my program.adb file. 

It compiles properly but I am still getting a call to __aeabi_unwind_cpp_pr0 and the linker will not work.

Re: Inspirels Ada on cortex tutorial linker issue

[Devin]

Sorry for multiple posts.  

I just added the code you provided directly after the Run procedure, and it linked without error. I am confused as to why it would be different from including it in a different file the way I did.  Thank you for the help.

Re: Inspirels Ada on cortex tutorial linker issue

[Maciej Sobczak]

> I just added the code you provided directly after the Run procedure, and it linked without error. I am confused as to why it would be different from including it in a different file the way I did.

Let me guess - you did not compile the noexceptionhandling.adb file or you did not add the resulting noexceptionhandling.o to the linker invocation.

Note that this is a symbol linking problem, not an Ada problem. That's why language tricks are not a proper solution. Interestingly, you might as well solve it outside of Ada, for example by compiling and linking in the following C code:

void __aeabi_unwind_cpp_pr0(void) {}
void __aeabi_unwind_cpp_pr1(void) {}

But the point of the tutorial was to demonstrate pure-Ada programming. :-)

In any case, the *proper* solution is not to have these useless injections in the first place. The compiler should have an option for this.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Inspirels Ada on cortex tutorial linker issue

[Devin]

On Sunday, August 21, 2016 at 10:38:12 AM UTC-4, Maciej Sobczak wrote:
> > I just added the code you provided directly after the Run procedure, and it linked without error. I am confused as to why it would be different from including it in a different file the way I did.
> 
> Let me guess - you did not compile the noexceptionhandling.adb file or you did not add the resulting noexceptionhandling.o to the linker invocation.
> 
> Note that this is a symbol linking problem, not an Ada problem. That's why language tricks are not a proper solution. Interestingly, you might as well solve it outside of Ada, for example by compiling and linking in the following C code:
> 
> void __aeabi_unwind_cpp_pr0(void) {}
> void __aeabi_unwind_cpp_pr1(void) {}
> 
> But the point of the tutorial was to demonstrate pure-Ada programming. :-)
> 
> In any case, the *proper* solution is not to have these useless injections in the first place. The compiler should have an option for this.
> 
> -- 
> Maciej Sobczak * http://www.inspirel.com

Ah, you knew the issue exactly, I did not even compile it.  Now after compiling, I was able to link and load it onto the board properly.

It is nice to see the solution come from a pure Ada perspective as well.  I am very early in learning to write embedded firmware, and any software in general, so I greatly appreciate your help.

Devin

Re: Inspirels Ada on cortex tutorial linker issue

[Brian Drummond]

On Sun, 21 Aug 2016 21:00:46 -0700, Devin wrote:

> On Sunday, August 21, 2016 at 10:38:12 AM UTC-4, Maciej Sobczak wrote:
>> > I just added the code you provided directly after the Run procedure,
>> > and it linked without error. I am confused as to why it would be
>> > different from including it in a different file the way I did.
>> 
>> Let me guess - you did not compile the noexceptionhandling.adb file 
...
> Ah, you knew the issue exactly, I did not even compile it.  Now after
> compiling, I was able to link and load it onto the board properly.
> 
> It is nice to see the solution come from a pure Ada perspective as well.
>  I am very early in learning to write embedded firmware, and any
> software in general, so I greatly appreciate your help.
> 
> Devin

It's not QUITE a pure Ada perspective (IMO) ... that would involve the 
Ada compiler system tracking and automatically compiling all necessary 
dependencies.

That's what gnatmake or gprbuild do - where some languages require 
Makefiles or other out-of-the-language means to manage the dependencies.

However in this case the dependency is injected by specific versions of 
the compiler, behind Ada's back so to speak, so the Ada compiler can't 
track it for you. Even if it's written in pure Ada, the separate compile 
and linking steps are still just a workaround until the compiler gets 
fixed.

-- Brian

Re: Inspirels Ada on cortex tutorial linker issue

[Nicholas Colin Paul de Gloucester]

Brian Drummond sent:
|------------------------------------------------------------------------|
|"[. . .]                                                                |
|                                                                        |
|That's what gnatmake or gprbuild do - where some languages require      |
|Makefiles or other out-of-the-language means to manage the dependencies.|
|                                                                        |
|[. . .]"                                                                |
|------------------------------------------------------------------------|


Dear Brian Drummond,

Thay may be nice, but they are also out-of-the-language means.

Thy sincerely,
Colin Paul Gloster, Coimbra University

Re: Inspirels Ada on cortex tutorial linker issue

[rieachus]

On Monday, August 29, 2016 at 1:49:23 PM UTC-4, Nicholas Colin Paul de Gloucester wrote:

> Thay may be nice, but they are also out-of-the-language means.

Uh, when I use a text editor to create Ada source files, then call gnatmake on the main program, I don't need to know anything about makefiles, pre-processor commands to mix in with my source, linker commands to bring in math libraries or whatever.  In fact, I can and have created programs with GNATs assembly language commands, and recompile for a different platform without change.  (Not guaranteed to work, and you have to be careful.) All in all, much, much better than other languages where moving an application from one compiler to another for the same target can take weeks.

On the downside, Ada is just getting to the point where OS calls and graphics is as easy as the rest of the langauge domain... 

Re: Inspirels Ada on cortex tutorial linker issue

[Brian Drummond]

On Mon, 29 Aug 2016 19:49:12 +0200, Nicholas Colin Paul de Gloucester
wrote:

> Brian Drummond sent:
> 
|------------------------------------------------------------------------|
                                                                     
> |
> |That's what gnatmake or gprbuild do - where some languages require     
> |
> |Makefiles or other out-of-the-language means to manage the
> dependencies.|

> 
|------------------------------------------------------------------------|
> 
> 
> Dear Brian Drummond,
> 
> Thay may be nice, but they are also out-of-the-language means.

By that definition, the compiler itself is an out-of-the-language means. 
Indeed you can see "gnatmake" as "the compiler" and ignore all lower 
level details.

Ada source code tracks its own dependencies properly (with hints in the 
form of pragma, limited with, use type where it is necessary to resolve 
circularities and ambiguities)

Having learned an allegedly smaller language instead, you sometimes find 
you also have to learn "make"(*) before you can do anything non-trivial 
with it.

(*) one of only two languages I've seen, where substituting multiple 
spaces for tabs will change the semantics. I suspect "make" was the 
inspiration for the other...

Mixing languages, you get used to that additional burden, but it's a 
surprise to have to, as the OP has, in a pure Ada program, thanks to a 
(hopefully temporary) compiler defect.

-- Brian

Re: Inspirels Ada on cortex tutorial linker issue

[Simon Wright]

Brian Drummond <brian@shapes.demon.co.uk> writes:

> Mixing languages, you get used to that additional burden, but it's a
> surprise to have to, as the OP has, in a pure Ada program, thanks to a
> (hopefully temporary) compiler defect.

I'd say it's a feature, not a defect.

OP is using a full Ada compiler on an ARM Debian computer, and the
compiler and RTS are set up to deal with exception handling in a
particular way, which fails when the resulting code needs to be executed
on a very much smaller ARM platform without any runtime support.

As I noted upthread, one workround is to compile against an RTS which
doesn't provoke the compiler into the unwanted behaviour. And it doesn't
have to be much of an RTS!

Re: Inspirels Ada on cortex tutorial linker issue

[Nicolas Colin Paul de Gloucester]

|-----------------------------------------------------------------------|
|"On Monday, August 29, 2016 at 1:49:23 PM UTC-4, Nicholas Colin Paul de|
|Gloucester wrote:                                                      |
|                                                                       |
|Thay may be nice, but they are also out-of-the-language means.         |
|                                                                       |
|Uh, when I use a text editor to create Ada source files, then call     |
|gnatmake on the main program, I don't need to know anything about      |
|makefiles, pre-processor commands to mix in with my source, linker     |
|commands to bring in math libraries or whatever.  [. . .] All in all,  |
|much, much better than other languages where moving an application     |
|from one compiler to another for the same target can take weeks.       |
|                                                                       |
|[. . .]"                                                               |
|-----------------------------------------------------------------------|

Hello:

When I run  gnatmake  it invokes none of PowerAda and Janus/Ada and
Ada Magic. It invokes GNAT. For example,  out_of_the_language.ada  is
a file that contains a legal Ada program. GNATMake refuses to compile
it.

cat out_of_the_language.ada
package Out_Of_The_Language is
   type Out_Of_The_Language_Type is (True, False);
   function Predicate return Out_Of_The_Language_Type;
end Out_Of_The_Language;
package body Out_Of_The_Language is
   function Predicate return Out_Of_The_Language_Type is
      Disagreement : Out_Of_The_Language_Type := True;
   begin
      return Disagreement;
   end Predicate;
end Out_Of_The_Language;
 /home/gloucester/out_of_the_language/single_file $ gnatmake
 out_of_the_language.ada
gcc-4.9 -c -x ada out_of_the_language.ada
out_of_the_language.ada:5:01: end of file expected, file can have only
one compilation unit
gnatmake: "out_of_the_language.ada" compilation error

GNATChop is also out of the language and it provides a workaround.

 /home/gloucester/out_of_the_language/single_file $ mkdir ../GNATChop
 /home/gloucester/out_of_the_language/single_file $ gnatchop
 out_of_the_language.ada ../GNATChop
splitting out_of_the_language.ada into:
   ../GNATChop/out_of_the_language.ads
   ../GNATChop/out_of_the_language.adb

A person who knows everything about Ada and nothing about GNAT can
"use a text editor to create Ada source files" - e.g.
out_of_the_language.ada  - but cannot then merely "call gnatmake on
the main program". Invoking the GNATChop "pre-processor" might be a
step between "a text editor" and "gnatmake".

No person needs to "know anything about makefiles" for a language
(whether Ada or not Ada). A compiler for a language may be (and in
many cases is) impractical without something like GNATMake (and
GNATMake is much better than Make), but "makefiles" are also out of
those languages.

With kind regards,
Nicholas Collin Paul de Gloucester

Re: Inspirels Ada on cortex tutorial linker issue

[Nicolas Colin Paul de Gloucester]

Brian Drummond sent:
|------------------------------------------------------------------------|
|"[. . .]                                                                |
|                                                                        |
|Having learned an allegedly smaller language instead, you sometimes find|
|you also have to learn "make"(*) before you can do anything non-trivial |
|with it."                                                               |
|------------------------------------------------------------------------|

Dear Brian Drummond,

In real life this is true. Nothing prevents one de merging
functionality like "make" into a compiler. GNATMake; JavaC; and
Borland Turbo C++ are examples.

|------------------------------------------------------------------------|
|"(*) one of only two languages I've seen, where substituting multiple   |
|spaces for tabs will change the semantics. I suspect "make" was the     |
|inspiration for the other...                                            |
|                                                                        |
|[. . .]                                                                 |
|                                                                        |
|-- Brian"                                                               |
|------------------------------------------------------------------------|

Ugh. What was that other language?

Thy sincerely,
Paul Colin de Gloucester

Re: Inspirels Ada on cortex tutorial linker issue

[Dennis Lee Bieber]

On Tue, 30 Aug 2016 16:55:21 +0200, Nicolas Colin Paul de Gloucester
<wirklich@nicht.at> declaimed the following:


>When I run  gnatmake  it invokes none of PowerAda and Janus/Ada and
>Ada Magic. It invokes GNAT. For example,  out_of_the_language.ada  is
>a file that contains a legal Ada program. GNATMake refuses to compile
>it.
>

	GNAT implementation turns the OS filesystem into the "database" defined
in the APSE requirements

https://en.wikipedia.org/wiki/APSE
http://www.adahome.com/History/Stoneman/stoneman.htm

	As a side-effect, it requires that files containing multiple units be
split (gnatchop) so that the unit names become entities in the filesystem.
cf: 4.A.3; this then permits gnatmake and the compiler to locate units when
referenced (with'ed). For a system to fit the APSE requirements yet allow
multiple units within a file requires some other meta-data to be maintained
somehow so that the tools of the APSE can find the correct file given just
the entity name.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Inspirels Ada on cortex tutorial linker issue

[Simon Wright]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> 	As a side-effect, it requires that files containing multiple
> units be split (gnatchop) so that the unit names become entities in
> the filesystem.  cf: 4.A.3; this then permits gnatmake and the
> compiler to locate units when referenced (with'ed). For a system to
> fit the APSE requirements yet allow multiple units within a file
> requires some other meta-data to be maintained somehow so that the
> tools of the APSE can find the correct file given just the entity
> name.

You can use gprname[1] to generate this metadata (which says e.g. "package
body P is the second unit in file files.ada").

[1]
http://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/companion_tools.html#specifying-a-naming-scheme-with-gprname

Re: Inspirels Ada on cortex tutorial linker issue

[Brian Drummond]

On Tue, 30 Aug 2016 17:06:34 +0200, Nicolas Colin Paul de Gloucester
wrote:

> Brian Drummond sent:
> |you also have to learn "make"(*) before you can do anything non-trivial
|------------------------------------------------------------------------|
> |"(*) one of only two languages I've seen, where substituting multiple  
> |spaces for tabs will change the semantics. I suspect "make" was the    
> |inspiration for the other...                                           
> |

> Ugh. What was that other language?

Brainf**k

(I'm speculating it was born after a lengthy and completely unnecessary 
debugging session that turned out to be a Makefile error)

nuff said?

-- Brian

Re: Inspirels Ada on cortex tutorial linker issue

[Maciej Sobczak]

On Monday, August 29, 2016 at 11:51:36 PM UTC+2, riea...@comcast.net wrote:
> All in all, much, much better than other languages where moving an application from one compiler to another for the same target can take weeks.

Sorry, but this argument is as wrong as it is frequently repeated.
If you move Ada to another compiler, you can be sure that your gnatmake will not work anymore. And then it will take weeks to configure the new tool.

Similarly, I can see people arguing that Ada is more portable than "other languages" (meaning C), because they never move outside of GNAT. If you don't change the compiler, then Ada and "other languages" are similarly portable. There is nothing magic in Ada, it is a single toolchain that people are attached to (for whatever reason), that makes their code kind of portable or stable.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Inspirels Ada on cortex tutorial linker issue

[Maciej Sobczak]

On Tuesday, August 30, 2016 at 2:33:43 PM UTC+2, Brian Drummond wrote:

> (*) one of only two languages I've seen, where substituting multiple 
> spaces for tabs will change the semantics. I suspect "make" was the 
> inspiration for the other...

And in "The Art of Unix Programming" the author cites the "make" creator, who admits that it was his stupidest idea ever.

Now, go and tell this to the advocates of that other language, for whom attaching semantics to the amount of whitespace is one of the best language features. ;-)

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Inspirels Ada on cortex tutorial linker issue

[Simon Wright]

Brian Drummond <brian@shapes.demon.co.uk> writes:

> On Tue, 30 Aug 2016 17:06:34 +0200, Nicolas Colin Paul de Gloucester
> wrote:
>
>> Brian Drummond sent:
>> |you also have to learn "make"(*) before you can do anything non-trivial
> |------------------------------------------------------------------------|
>> |"(*) one of only two languages I've seen, where substituting multiple  
>> |spaces for tabs will change the semantics. I suspect "make" was the    
>> |inspiration for the other...                                           
>> |
>
>> Ugh. What was that other language?
>
> Brainf**k
>
> (I'm speculating it was born after a lengthy and completely unnecessary 
> debugging session that turned out to be a Makefile error)

:-)

And of course Whitespace. (I have my Emacs set so the default behaviour
is to save a file with tabs converted to spaces and trailing white space
deleted. Hah.)

Re: Inspirels Ada on cortex tutorial linker issue

[Dennis Lee Bieber]

On Wed, 31 Aug 2016 05:47:49 -0700 (PDT), Maciej Sobczak
<see.my.homepage@gmail.com> declaimed the following:


>Now, go and tell this to the advocates of that other language, for whom attaching semantics to the amount of whitespace is one of the best language features. ;-)

	You mean the one that gets installed behind the scenes when installing
GNAT GPS?
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Inspirels Ada on cortex tutorial linker issue

[Alejandro R. Mosteo]

On 01/09/16 02:02, Dennis Lee Bieber wrote:
> On Wed, 31 Aug 2016 05:47:49 -0700 (PDT), Maciej Sobczak
> <see.my.homepage@gmail.com> declaimed the following:
>
>
>> Now, go and tell this to the advocates of that other language, for whom attaching semantics to the amount of whitespace is one of the best language features. ;-)
>
> 	You mean the one that gets installed behind the scenes when installing
> GNAT GPS?

Hehehe

Re: Inspirels Ada on cortex tutorial linker issue

[Alejandro R. Mosteo]

On 31/08/16 14:42, Maciej Sobczak wrote:
> On Monday, August 29, 2016 at 11:51:36 PM UTC+2, riea...@comcast.net wrote:
>> All in all, much, much better than other languages where moving an application from one compiler to another for the same target can take weeks.
>
> Sorry, but this argument is as wrong as it is frequently repeated.
> If you move Ada to another compiler, you can be sure that your gnatmake will not work anymore. And then it will take weeks to configure the new tool.
>
> Similarly, I can see people arguing that Ada is more portable than "other languages" (meaning C), because they never move outside of GNAT. If you don't change the compiler, then Ada and "other languages" are similarly portable. There is nothing magic in Ada, it is a single toolchain that people are attached to (for whatever reason), that makes their code kind of portable or stable.

I cannot agree with that. The differences an psychological effect of 
changing toolchains might be the same, but certainly Ada is (or was) 
more portable in my experience. C/C++ may have come a long way with 
standardization efforts, but I remember my university times and that was 
eye-opening.

At that time, most deliverables where submitted and tested in some HP 
UNIX. We of course tried to advance work in our PCs. This would involve 
at least gnat and meridian compilers. C++ at that time (circa 2000) was 
nightmarish on its inconsistencies. The first time I took Ada code and 
it compiled and worked just the same across compilers I realized things 
could be better.

Admittedly, they were not very large projects. I guess C++ is long 
beyond that point, but at the time it was one of the things in Ada that 
attracted me. And in the end Ada mandates consistency when using library 
units. Even meridian did that, even if less easily. So you know that if 
not gnatmake/gprbuild you should have something else for the same purpose.

Even using the same compilers... I would bet on my Ada code from those 
days being easier to bring up to date to current gccs than my C/C++ one.

Ah, how time flies...

Re: Inspirels Ada on cortex tutorial linker issue

[Brian Drummond]

On Wed, 31 Aug 2016 21:58:34 +0100, Simon Wright wrote:

> Brian Drummond <brian@shapes.demon.co.uk> writes:
> 
>> On Tue, 30 Aug 2016 17:06:34 +0200, Nicolas Colin Paul de Gloucester
>> wrote:

|------------------------------------------------------------------------|
>>> |"(*) one of only two languages I've seen, where substituting multiple
>>> |spaces for tabs will change the semantics. I suspect "make" was the
>>> |inspiration for the other...
>>> |
>>
>>> Ugh. What was that other language?
>>
>> Brainf**k
>>
>> (I'm speculating it was born after a lengthy and completely unnecessary
>> debugging session that turned out to be a Makefile error)
> 
> :-)
> 
> And of course Whitespace. (I have my Emacs set so the default behaviour
> is to save a file with tabs converted to spaces and trailing white space
> deleted. Hah.)

oops it is entirely possible I was confusing the two, for some reason.

-- Brian

Re: Inspirels Ada on cortex tutorial linker issue

[AdaMagica]

Am Mittwoch, 31. August 2016 14:42:59 UTC+2 schrieb Maciej Sobczak:
> On Monday, August 29, 2016 at 11:51:36 PM UTC+2, riea...@comcast.net wrote:
> > All in all, much, much better than other languages where moving an
> > application from one compiler to another for the same target can take weeks.
>
> Sorry, but this argument is as wrong as it is frequently repeated.
> If you move Ada to another compiler, you can be sure that your gnatmake will
> not work anymore. And then it will take weeks to configure the new tool.
>
> Similarly, I can see people arguing that Ada is more portable than "other
> languages" (meaning C), because they never move outside of GNAT. If you don't
> change the compiler, then Ada and "other languages" are similarly portable.
> There is nothing magic in Ada, it is a single toolchain that people are
> attached to (for whatever reason), that makes their code kind of portable or
> stable.

Well, I can't comment on C(++). But:

I re-hosted several million lines of airborne embedded Ada code to different hardware (big endian to little endian) with compilers from different manufacturers (Ada 83 to Ada 95/2005) for use in full scale flight simulators. And to my big surprise, only very few pieces of code had to be touched.

GNAT's project files were easily written to work with the original code distribution over more than a dozen subsystem directory trees. It didn't take weeks; of course I had to learn about project files, but then it was matter of a few hours.

Biggest problems were:
- BE to LE
- original code not fully compliant to Ada RM (e.g. with Unchecked_Conversion)
- elaboration circularities arising because of code changes for simulator needs

Re: Inspirels Ada on cortex tutorial linker issue

[Jeffrey R. Carter]

On 09/01/2016 09:33 AM, AdaMagica wrote:
>
> I re-hosted several million lines of airborne embedded Ada code to different
> hardware (big endian to little endian) with compilers from different
> manufacturers (Ada 83 to Ada 95/2005) for use in full scale flight
> simulators. And to my big surprise, only very few pieces of code had to be
> touched.

Nor is this an unusual experience. With only a little extra effort, it's quite 
easy to write Ada that is completely portable across compilers from different 
vendors (for a specific version of the language) and across platforms. I've 
written quite a bit of it.

-- 
Jeff Carter
"To Err is human, to really screw up, you need C++!"
Stéphane Richard
63

Re: Inspirels Ada on cortex tutorial linker issue

[Maciej Sobczak]

On Friday, September 2, 2016 at 2:36:31 AM UTC+2, Jeffrey R. Carter wrote:

> Nor is this an unusual experience. With only a little extra effort, it's quite 
> easy to write Ada that is completely portable across compilers from different 
> vendors (for a specific version of the language) and across platforms. 

And I still don't see how is this Ada-specific. Both Ada and C (or C++) are defined with such a high level of abstraction, that standard-compliant code will be portable across compilers and platforms. And if you move outside of the standard (by relying on data representation, for example), the resulting mess can be the same.

> I've 
> written quite a bit of it.

Then somebody else must have written the Ada code that I can see now, which is so heavily attached to the hardware (including packing of pointer values in record fields of forced sizes) that it is probably easier to rewrite it than port to any other target.
Language is a tool, you still need good engineering principles to use it properly.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Inspirels Ada on cortex tutorial linker issue

[Dmitry A. Kazakov]

On 02/09/2016 14:05, Maciej Sobczak wrote:

> Both Ada and C (or
> C++) are defined with such a high level of abstraction, that
> standard-compliant code will be portable across compilers and platforms.

The flaw in the reasoning is in the definition of portability. Portable 
means same source implies equivalent semantics.

Abstraction level of a construct has little to do with the semantics of. 
Low-level constructs usually have better and more exact defined 
semantics. At the same time the semantics of aggregated constructs may 
become very volatile even if the constructs are well-defined themselves, 
which is especially so for lower level ones and even more so for 
combinations of lower level and higher level constructs.

Ada just has less problems with poorly defined semantics than C/C++.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Inspirels Ada on cortex tutorial linker issue

[AdaMagica]

Am Freitag, 2. September 2016 14:05:24 UTC+2 schrieb Maciej Sobczak:
> Then somebody else must have written the Ada code that I can see now, which is so heavily attached to the hardware (including packing of pointer values in record fields of forced sizes) that it is probably easier to rewrite it than port to any other target.
> Language is a tool, you still need good engineering principles to use it properly.

You're absolutely right. A good language does not force people to write good code.

I've seen code like this:

I: Integer;
...
if I in Integer then ...

Re: Inspirels Ada on cortex tutorial linker issue

[G.B.]

On 02.09.16 14:53, Dmitry A. Kazakov wrote:
> Ada just has less problems with poorly defined semantics than C/C++.

 From a practical point of view, configuring a piece of
stereotypical C code means autoc***. Try porting this oxymoronic
setup to anything other than GNU/Linux[-like]. They seem to
be using it even for ANSI C programs... So much time is wasted
on porting Unix software to Unix only because the second Unix
called Apple's BSD and Unix C programs have not been written
with ANSI and POSIX in mind. Or sometimes they have, but depend
on some auto**** generated add-ons.

OTOH, if ever there have been standardized Ada build systems,
are they useful with current Ada? Even AdaCore's GPRBuild
is a moving target. Does any Ada competitor offer a translator
between build systems? More absurdly, could we have an Ada
compiler targeting older editions of the language in order
to enlarge the number of targets, like the Comeau compiler
front end does for C++, and like AdaCore's AdaMagic front-end
does for Ada, targeting C?

You do get order of elaboration with Ada's concept of compilation
units, with semantic implications. Isn't this helpful when solving
certain problems of order, and of timing, when part A of a program
needs part B of the program to be in a ready state?
How would you do the same using C with Make, and formally so?


-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: Inspirels Ada on cortex tutorial linker issue

[Maciej Sobczak]

>  From a practical point of view, configuring a piece of
> stereotypical C code means autoc***.

Nonsense. I have written C and C++ code for multiple platforms and have never used autoconf (if this is what you mean), not even once. In fact, I have never understood, actually, why people are using it at all.

So you are having problems with a tool that you associate with some programming language by means of stereotypical relations and you claim what exactly? That Ada is better, because it does not have any such tools that were created for C and which you do not need to use anyway? I like Ada, but I must be missing some of the religious part of it.

> They seem to
> be using it

Who is "they"? The C language standard does not mention them.
Don't blame the language for something that exists outside of it. If autotools do not work for you, it's not the fault of C and certainly it is not the Ada feature, either.

> OTOH, if ever there have been standardized Ada build systems,

Good point. Ada does not even have a consistent convention for naming its source files.

> Isn't this helpful when solving
> certain problems of order, and of timing, when part A of a program
> needs part B of the program to be in a ready state?
> How would you do the same using C with Make, and formally so?

When I need this kind of relationship, it is usually much more complex than can be achieved with elaboration control. Talk about ensuring existence of live database connection pool, for example. Or, on the other side of the application spectrum, about ensuring the proper clock configuration of your microcontroller before you start using its peripherals. Ada's elaboration control is neither required nor sufficient for managing relationships at the level of complexity that is actually interesting in real-life applications.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Inspirels Ada on cortex tutorial linker issue

[G.B.]

On 02.09.16 23:33, Maciej Sobczak wrote:
>
>>  From a practical point of view, configuring a piece of
>> stereotypical C code means autoc***.
>
> Nonsense. I have written

(So, there exists at least 1 x, therefore all x, in practice? ;-)

By "practical" I wasn't thinking of how one specific practitioner
could make use of C, that wasn't very clear. I was thinking of
C programs presenting themselves to any evaluation that tries to
assess porting efforts required.

> C and C++ code for multiple platforms and have never used autoconf

I applaud that.

> In fact, I have never understood, actually, why people are using
>  it at all.

How about this explanation of autoconf: people don't understand,
from a technical point of view, just why they are using autoconf.
The motivation would, I guess, be this: I do just what the others
usually do,

       The Eleventh Commandment
    configure, make, make install
   
Crowd orientation is a (statistically) very normal trait of programmer
behavior, including (program) managerial decisions as to what a
distributed product should include (autoconf; what the others do).
Come to that, also as to what languages one should use, and how.


> So you are having problems with a tool that you associate with some programming language by means of stereotypical relations and you claim what exactly?

I claim that at least the stereotypical setup of Ada is better
in that Ada does try to address some issues at the language level
like C does to a lesser degree. To achieve C portability and ease
of change, it takes a lot of knowledge and discipline, and also, typically,
independent thinking of a courageous individual programmer using C.
It does _not_ require autoconf, but this fact is ignored by many.

>> They seem to
>> be using it
>
> Who is "they"? The C language standard does not mention them.
> Don't blame the language for something that exists outside of it.

I do (pompously) blame language efforts for what they leave out (or keep).
If it is true that very many C programmers want some portability
(witness, e.g., autoconf), how could it not be the business of the
language's standardization process to address this common need,
and instead shrug and have programmers continue to use autoconf?

Programmers want to express something, and they use language for that.

> If autotools do not work for you, it's not the fault of C

Are you certain that the definition of C, its means for expressing
configuration, or variations (#if[def], say, or its type system
when LSP is desired?) will have no influence on how it is used
with Make, "discipline", etc? Would it not give rise to autoconf?

A configuration talks about source text. Therefore, the vocabulary
of source text is also present in configuration talk and perhaps
vice versa. So, there is a  language level, and the language will
affect configuration.

>> OTOH, if ever there have been standardized Ada build systems,
>
> Good point. Ada does not even have a consistent convention for naming its source files.

With consistency being a good thing, no language should depend on
accidentals of operating systems. Neither C nor Ada nor C++ do that(*).
However, "language environments" must help programmers getting their
compilation units compiled, this much is clear from economy 101,
customer's point of view.
By extension of economy 101, portability is required between
"language environments".
But you know what they say about customers.


>> Isn't this helpful when solving
>> certain problems of order, and of timing, when part A of a program
>> needs part B of the program to be in a ready state?
>> How would you do the same using C with Make, and formally so?
>
> When I need (...) at the level of complexity that is actually
>  interesting in real-life applications.

So that's one data point I had actually been hoping to see:
How useful is elaboration, a requirement that Ada does address?

__
(*) Well, C has its source files and associated scope rules,
but I can #include "slarti.bart.fast", and I need to put
"body" definitions in conventional "SomeTemplate.hpp", IINM.

-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: Inspirels Ada on cortex tutorial linker issue

[Brian Drummond]

On Fri, 02 Sep 2016 06:40:40 -0700, AdaMagica wrote:

> Am Freitag, 2. September 2016 14:05:24 UTC+2 schrieb Maciej Sobczak:
>> Then somebody else must have written the Ada code that I can see now,
>> which is so heavily attached to the hardware (including packing of
>> pointer values in record fields of forced sizes) that it is probably
>> easier to rewrite it than port to any other target.
>> Language is a tool, you still need good engineering principles to use
>> it properly.
> 
> You're absolutely right. A good language does not force people to write
> good code.
> 
> I've seen code like this:
> 
> I: Integer;
> ...
> if I in Integer then ...

My favourite:

while (1 = 1) loop 
   ...
end loop;

I imagine this was a creative response to a compiler error message 
"expected type boolean; found type integer" from "while (1) loop"

-- Brian

Re: Inspirels Ada on cortex tutorial linker issue

[Björn Lundin]

On 2016-09-03 13:58, Brian Drummond wrote:
> 
> My favourite:
> 
> while (1 = 1) loop 
>    ...
> end loop;
> 
> I imagine this was a creative response to a compiler error message 
> "expected type boolean; found type integer" from "while (1) loop"
> 


I've seen the equivalence of

if not List.Is_Empty then
  List.Append(Element);
else
  List.Prepend(Element);
end if;

I still wonder what difference it makes if
I append or prepend to an EMPTY list ...



--
Björn

Re: Inspirels Ada on cortex tutorial linker issue

[Alejandro R. Mosteo]

On 03/09/16 11:20, G.B. wrote:

> So that's one data point I had actually been hoping to see:
> How useful is elaboration, a requirement that Ada does address?

It's been useful to me, in the sense that I'm sure my programs 
initialize correctly in the Ada-only sense.

And usually, when a circularity is detected and pointed out by the 
compiler I realize that I'm being too careless in my design and should 
take a step back.

OTOH I've always despised #ifdef guards. What I find puzzling is that 
the #once directive was discouraged the last time I looked at it. I also 
felt very bothered when it was the linker instead of the compiler 
telling me something was either missing or duplicate in my 
single-language program.

Alex.

Re: Inspirels Ada on cortex tutorial linker issue

[Maciej Sobczak]

> >>  From a practical point of view, configuring a piece of
> >> stereotypical C code means autoc***.
> >
> > Nonsense. I have written
> 
> (So, there exists at least 1 x, therefore all x, in practice? ;-)

No. Rather - therefore there is no such thing as a stereotypical C code.

> How about this explanation of autoconf: people don't understand,
> from a technical point of view, just why they are using autoconf.

I agree with that. I have seen autoconf scripts checking whether there is a Fortran compiler installed, even though the given project was not using Fortran. Or whether there are standard functions. People have been blindly copying autoconf script pieces from each other without trying to understand what they do, only to deteriorate the whole ecosystem with time.
But this is not due to C limitations.
According to Wikipedia (https://en.wikipedia.org/wiki/Autoconf):

"Autoconf is agnostic about the programming languages used [...]"

> The motivation would, I guess, be this: I do just what the others
> usually do,

Which is a property of all things that are popular beyond technical justification. If Ada was as popular as C, you would have hordes of incompetent Ada "coders", too. And autoadaconf, too.

>        The Eleventh Commandment
>     configure, make, make install

Yes. One guy asked me to provide the configure script, because he refused to use a package that did not have it. I have instructed him to create an empty configure script instead.
But I still don't blame the C language for that.

> I claim that at least the stereotypical setup of Ada is better
> in that Ada does try to address some issues at the language level
> like C does to a lesser degree.

OK, so again from the same Wikipedia page:

"GNU Autoconf is a tool for producing configure scripts for building, installing and packaging software on computer systems where a Bourne shell is available."

Let pick the most important parts:
- building
- installing
- packaging

These are the voids that autoconf is (or rather was) trying to fill in the GNU ecosystem. What does Ada offer in these areas?
Let's see:

- Building - nothing. Every compiler vendor has their own, mutually incompatible approach for building programs. It was already pointed here how useful is GNATMake with Janus/Ada, for example.
- Installing - nothing. No, really. Seriously. Nothing.
- Packaging - nothing. Void. Null.

There are further things that you might ask for, like library dependency management utilities, remote repository management tools, etc. The more you ask, the less you will find in the Ada ecosystem.

There are systems like Debian where Ada benefits from the general, system-wide approach for these things (and of course from the voluntary effort of people who are doing the hard work). Thus, I can apt-get install whatever and it will just work. But like it or not, the infrastructure for all these useful tools was founded by those who you detest. It is *not* the Ada's achievement that Ada programs can be built, installed, packaged, downloaded and have their dependencies managed on such systems.

> To achieve C portability and ease
> of change, it takes a lot of knowledge and discipline, and also, typically,
> independent thinking of a courageous individual programmer using C.

Substitute Ada for C in the above and it is still true. Even more so if you take into account how much thinking independence is required to even consider Ada for new projects.

> > If autotools do not work for you, it's not the fault of C
> 
> Are you certain that the definition of C, its means for expressing
> configuration, or variations (#if[def], say, or its type system
> when LSP is desired?) will have no influence on how it is used
> with Make, "discipline", etc? Would it not give rise to autoconf?

I am certain that Ada did not give rise to autoadaconf. Instead, Ada programmers rely on the infrastructure built by C programmers, as explained above.

> So that's one data point I had actually been hoping to see:
> How useful is elaboration, a requirement that Ada does address?

I do not find it to be a critical language feature. Ada *does* have its killer features, but elaboration control is not one of them.
Actually, it is known that depending on the combination of compiler options, it is possible to have a program that will build on one compiler, but not on the other.

-- 
Maciej Sobczak * http://www.inspirel.com