Getting stared with DDE: Make and libraries

Hi,

I’ve installed DDE from NutPi but haven’t yet managed to compile my first application. Here’s what I’ve done so far:
1) Create a set of directories – c, compiled, h, files, o
2) Written a simple helloworld.c type-application (includes scanf, printf functions – nothing more).
3) Dropped said file into CC. Default setting used (Throwback ticked). This puts helloworld.c into my o directory. This all seems reasonable so far. As not using make, I expect I need to link this with the stdio library binary – as well as the stdio.h header file…
4) Tried dragging helloworld.c (from the o directory) into Linker. Default options (AIF selected). Run. Errors, complaining of “undefined symbols”.

What am I not doing? I suspect the link can’t see the header/object library files? Hopefully I’m close.

Also, if I want to install my own library – specifically bringing a library across from the Linux world, do I need to go back to the .c implementation of the library’s binary file and compile that for RISC OS?

Many thanks in advance.

1) Create a set of directories – c, compiled, h, files, o

The DDE expects:

• appdir – the resulting executable is placed here
• appdir.c – for the C source
• appdir.h – for headers, if you use any
• appdir.o – for the intermediate object files

2) Written a simple helloworld.c type-application (includes scanf, printf functions – nothing more).

I’ll do the same, only without scanf as I never remember the syntax. Here, it’s this:

#include <stdio.h>

int main(void)
{
   printf("Hello!\n\n");

   return 0;
}

It is saved as “RAM:$.c.Text1”.

3) Dropped said file into CC. Default setting used (Throwback ticked). This puts helloworld.c into my o directory. This all seems reasonable so far. As not using make, I expect I need to link this with the stdio library binary – as well as the stdio.h header file…

? With my version, doing that calls the linker automatically and eventually offers me an executable called “Text1”.

Are you sure you don’t have “Compile only” ticked?

4) Tried dragging helloworld.c (from the o directory) into Linker. Default options (AIF selected). Run. Errors, complaining of “undefined symbols”.

You mean this:

ARM Linker: (Error) Undefined symbol(s).
ARM Linker:     __rt_stkovf_split_small, referred to from RAM::RamDisc0.$.o.Text1.
ARM Linker:     _printf, referred to from RAM::RamDisc0.$.o.Text1.
ARM Linker:     __main, referred to from RAM::RamDisc0.$.o.Text1.
ARM Linker: Errors in link, no output generated.
ARM Linker: finished,  4 informational, 0 warning and 1 error messages.

That’s because the linker can’t find the standard library. What happens is the linker will take your program, then link it with with CLib stubs (to initialise the C program) and any other bits and pieces as necessary to arrive at a proper executable. It knows where your program is, but…

In the Link window, you’ll see that it holds the name of your object file. Following that, enter a space character and then C:o.stubs and your program will then build.

What am I not doing? I suspect the link can’t see the header/object library files? Hopefully I’m close.

That’s exactly it. However do note that this all gets a bit messy when it comes to a C program built up of multiple source files and libraries. You ought to investigate MakeFiles and AMU (it’s better than Make).

Also, if I want to install my own library – specifically bringing a library across from the Linux world, do I need to go back to the .c implementation of the library’s binary file and compile that for RISC OS?

Yes. RISC OS is not able to use Linux style libraries so you will need to port it across from source – but note that RISC OS is very very far from POSIX (refer to another thread today for a brief discussion on “threads”).

Having said this, it may be worth looking at the GCCSDK project http://www.riscos.info/index.php/GCC_for_RISC_OS as there are a fair few Linux libraries already ported.

I don’t want to complicate things too much, but “shared makefiles” seem to be ROOL’s recommended way of doing things now. You don’t touch CC directly at all, and rather let AMU (the command-line component of Make) do all the work [Edit: I see that Rick also mentioned this]. When you have multiple source files in your app, this becomes quite a bit easier than manually compiling with CC.

Admittedly this requires a bit of initial setup, but it tends to be worth doing.

Create your “c” directory and put your helloworld file in there. Then, in your project’s root directory, create a text file called Makefile with:

COMPONENT = HelloWorld
TARGET = !RunImage
OBJS = helloworld
CINCLUDES = -IC:
include CApp

The first line is the name of your app and the second is the name of the resulting binary (absolute) file. The third is a list of all the C files to compile, separated by spaces. Then we include the C libraries, and finally tell AMU that it’s a C app.

You can then build by running AMU from a task window, but it can be easier to create a TaskObey file (typically named Mk):

Dir <Obey$Dir>
WimpSlot -min 1024k
amu all

Dropped said file into CC. Default setting used (Throwback ticked). This puts helloworld.c into my o directory. This all seems reasonable so far. As not using make, I expect I need to link this with the stdio library binary – as well as the stdio.h header file…

The “said” file should be named as “helloworld” and placed in the “c” directory. that is c.helloworld. Drop the source file onto !CC, o.helloworld is created and an executable produced in one pass with no further user action required.

The DDE expects
appdir – the resulting executable is placed here
appdir.c – for the C source
appdir.h – for headers, if you use any
appdir.o – for the intermediate object files

If !Builder has been seen everything is correctly set and running a taskobey file as described by Chris, the o directory is created.

@Stevyn
Take the setup one stage further than Chris described and do

and the setup cleans old objects out and rebuilds everything.
Note: The !Builder shared makefile route is pretty easy. Rick doesn’t like it as it hides a fair bit of the nuts and bolts and he likes the atoms of the nuts and bolts :)

Thank you all for the excellent help.

I’ve now got an application to compile, using Rick’s instructions – although for some reason it isn’t automatically launching the Linker. When I take CC’s object code and drop it manually into Link, then append C:o.stubs, I get a Save As dialogue with a nice RunImage.

Having a play with AMU which half-works again, but not all the way to creating the RunImage. I suspect it’s the same problem.

I’m going to try and reinstall I think.

Rick doesn’t like it as it hides a fair bit of the nuts and bolts and he likes the atoms of the nuts and bolts :)

Exactly. I like all my nuts and bolts in order and exactly where I put them, not someplace else.
I write my own MakeFiles and pretty much ignore ROOL’s shared makefiles stuff. ;-)

Admittedly this requires a bit of initial setup, but it tends to be worth doing.

Damn straight. I write my code using Zap and you know how I perform a new build? I press Shift-Ctrl-C. This saves the current source (in the editor) and then kicks the MakeFile to AMU.

It isn’t so hard to insert other stuff into the MakeFile, such as deleting CMHG’s object file (means CMHG must be run every time, ensuring the module header contains the correct build date etc). If I want a full build (though it isn’t that common I’d want to perform a clean build), I just open the ‘o’ directory, delete all the object files, then press Sh-Ctrl-C in Zap.

If !Builder has been seen everything is correctly set and running a taskobey file as described by Chris, the o directory is created.

I’ve only ever tried shared makefiles in DDE 25 so I can’t speak for other versions, but Builder isn’t required. So long as SetPaths has been seen then shared makefiles should work.

amu clean

Personally I avoid doing this; it’s not going to make any practical difference for a tiny app, but will slow things down when you have, say, 20 source files. Cleaning on build will result in all 20 being recompiled every time, even if they haven’t changed. I keep a separate “MkClean” TaskObey file for situations such as when making a backup, but most of the time I just let AMU work out what needs to be rebuilt.

Having a play with AMU which half-works again, but not all the way to creating the RunImage. I suspect it’s the same problem.

It should go all the way to the RunImage. Can you post the taskwindow output?

Rick doesn’t like it as it hides a fair bit of the nuts and bolts and he likes the atoms of the nuts and bolts :)

I remembered Rick saying that in the past, and tried to choose my words carefully in my earlier post :)

I keep a separate “MkClean” TaskObey file for situations such as when making a backup

Yup, I do that. I was just pointing out the possibility for the quick cleanup.

Here’s what I get taking the AMU route:

ram
*.
Dir. RAM::RamDisc0.$ Option 00 (Off)
CSD RAM::RamDisc0.$
Lib. RAM:“Unset”
URD RAM:“Unset”
c D/ Makefile WR/ Mk WR/ o D/ od D/
*WimpSlot -min 1024k
*amu clean
x wipe o FR~C~V
x wipe od FR~C~V
remove !RunImage
remove !RunImage-D
HelloWorld: cleaned
*amu all
do mkdir -p o
do mkdir -p od
create o._dirs
cc -c -depend !Depend -IC: -ff -fah -o o.helloworld c.helloworld
Norcroft RISC OS ARM C vsn 5.70 [12 Oct 2012]
“c.helloworld”, line 7: Error: missing newline before EOF – inserted
c.helloworld: 0 warnings, 1 error, 0 serious errors
AMU: ** exit (1) *

AMU: * ‘all’ not re-made because of errors *

*

Note – still no !RunImage is being created..AMU doesn’t seem to be seeing the CLib stuff.

c.helloworld”, line 7: Error: missing newline before EOF

Have you tried going to line 7, moving to the end of the line and hitting the return key to add a line feed after the code and before what I presume is the end of the file immediately afterward?

That looks to be the issue. Every line in a C program, including the last one, must end with a newline (return) character.

Dismissed that for being too simple!

All seems to be working now. Thank you all.