-1

I have an executable in Ada compiled with gprbuild.the executable use some simple function (like sin e cos).This executable is operating in a App binded to a POS (Partition Operating System) designed with vxwork. Once recompiled the whole process it appears a bunch of multiple function declaration errors between the POS_API.o and the ada executable (hello.o) . These functions (sin, cos, ...) are all in the same library. Unfortunately the most easy solution to de-reference all this function in POS is not permitted (bound of design).Any suggestions on how to compile or proceed? Is this any possibility to compile without a specific library or some function in order to avoid the multiple reference error?

Simon Wright
  • 25,108
  • 2
  • 35
  • 62
Giovanni
  • 3
  • 2
  • 1
    Is there any VxWorks documentation about how to solve the same problem with C? I’m very surprised to find an _executable_ in a `.o` file, but it’s a long time since I used VxWorks (5.4) and such a thing wouldn’t have been possible then. Perhaps you need to build a library from your Ada source rather than an executable. – Simon Wright Feb 19 '19 at 20:39
  • @SimonWright When I used VxWorks 5.1.1, 5.4, and 5.5 versions there was a way to load a .o into memory and call custom C functions straight from the command line. I don't know if that was an artifact of a custom build of the OS (We had to modify C code just to add a hard drive to our system...so possible) or something else. – Jere Feb 20 '19 at 03:53
  • Are you following on from [this answer](https://stackoverflow.com/a/53334548/40851)? (which you didn’t respond to, by the way: was it any use?) If so, I’ll take another look – Simon Wright Feb 20 '19 at 11:46
  • I have exactly executed this previous step. The problem is how to modify the executable in order to avoid multiple ref. Is there any attribute to be use in package Linker to unlink double reference? I have succeed to add the POS_api.o in linker (gps environment) and had obtained same error. – Giovanni Feb 20 '19 at 13:39

1 Answers1

0

I'm afraid this isn't really an answer: largely because it's more than ten years since I worked with VxWorks and Ada, and things have got a bit hazy. Also, it's a bit long for a comment on your question

As I used it, VxWorks comes with a whole suite of software that you configure to hold just the components you need into your kernel: in this case, that would presumably include the maths package, functions like sin(), as well as the OS functions like taskSpawn().

The Ada/VxWorks build process that we used generates a partially-linked object file, with references to sin(), taskSpawn() unresolved (I can't remember how this is achieved; if using GNU ld, maybe the -r or --relocatable switch?). When VxWorks loads this object file over the configured kernel, the unresolved references get resolved, and away we go.

Now, I don't know what sort of thing your POS_API does. Is it a skin over a configured VxWorks kernel? Does it load yoour Ada program itself? If it is itself a VxWorks program, how come it's exporting sin()?

I suspect that the problem is to do with the way you've linked your executable. Maybe you could show us your GPR file? Otherwise, I'm just whistling in the dark.

Simon Wright
  • 25,108
  • 2
  • 35
  • 62