I'm trying to compile a program using mixed C and Ocaml sources, with the main of the application in C calling some pieces of OCaml code.
All right, no problem here, It's seems to be a common operation, fully documented, easy to do with the standard Ocaml tools.
Let me explain a bit, this kind of compilation is divided in 4 steps : Caml compiling to Caml objects, then compiling the Caml to C objects, then compiling the C files, and lastly compiling all the C objects together and getting the executable.
The theory is, the Ocaml compiler will embed the Caml runtime, GC, and all its stuff automatically, and we just have to indicate if we use whichever the ocaml bytecode (referencing -lcamlrun) or the native binary (referencing -lasmrun).
So, it seems to be quite simple, let's do it. Steps 1, 2 and 3 went as expected, good!
Only the 4th step is problematic. Just take a look:
cc -o /home/thomas/Documents/projects/ocaml/GogoGame/bin/GogoPlayer.exe \
-L/usr/lib/ocaml -lcamlrun \
/home/thomas/Documents/projects/ocaml/GogoGame/src/init_camlcode.o \
/home/thomas/Documents/projects/ocaml/GogoGame/src/init.o \
/home/thomas/Documents/projects/ocaml/GogoGame/src/interface.o \
/home/thomas/Documents/projects/ocaml/GogoGame/src/caml_func.oo
/home/thomas/Documents/projects/ocaml/GogoGame/src/interface.o: In function `main':
interface.c:(.text+0x0): multiple definition of `main'
/usr/lib/ocaml/libcamlrun.a(main.o):(.text+0x0): first defined here
/usr/lib/ocaml/libcamlrun.a(floats.o): In function `caml_exp_float':
(.text+0x488): undefined reference to `exp'
/usr/lib/ocaml/libcamlrun.a(floats.o): In function `caml_fmod_float':
(.text+0x4f9): undefined reference to `fmod'
/usr/lib/ocaml/libcamlrun.a(floats.o): In function `caml_log_float':
(…)
/usr/lib/ocaml/libcamlrun.a(unix.o): In function `caml_dlopen':
(.text+0x2ed): undefined reference to `dlopen'
/usr/lib/ocaml/libcamlrun.a(unix.o): In function `caml_dlclose':
(.text+0x300): undefined reference to `dlclose'
/usr/lib/ocaml/libcamlrun.a(unix.o): In function `caml_dlsym':
(.text+0x31b): undefined reference to `dlsym'
/usr/lib/ocaml/libcamlrun.a(unix.o): In function `caml_dlerror':
(.text+0x342): undefined reference to `dlerror'
/home/thomas/Documents/projects/ocaml/GogoGame/src/init_camlcode.o:(.data.rel+0xc): undefined reference to `caml_array_get_addr'
/home/thomas/Documents/projects/ocaml/GogoGame/src/init_camlcode.o:(.data.rel+0x10): undefined reference to `caml_array_get_float'
(...)
/home/thomas/Documents/projects/ocaml/GogoGame/src/init_camlcode.o:(.data.rel+0x31c): undefined reference to `caml_lazy_make_forward'
/home/thomas/Documents/projects/ocaml/GogoGame/src/init_camlcode.o:(.data.rel+0x320): undefined reference to `caml_get_public_method'
/home/thomas/Documents/projects/ocaml/GogoGame/src/init_camlcode.o:(.data.rel+0x3ac): undefined reference to `caml_terminfo_setup'
/home/thomas/Documents/projects/ocaml/GogoGame/src/init_camlcode.o:(.data.rel+0x3b0): undefined reference to `caml_terminfo_backup'
/home/thomas/Documents/projects/ocaml/GogoGame/src/init_camlcode.o:(.data.rel+0x3b4): undefined reference to `caml_terminfo_standout'
/home/thomas/Documents/projects/ocaml/GogoGame/src/init_camlcode.o:(.data.rel+0x3b8): undefined reference to `caml_terminfo_resume'
/home/thomas/Documents/projects/ocaml/GogoGame/src/init.o: In function `camlInit__f_1030':
(.text+0xc): undefined reference to `camlPervasives'
/home/thomas/Documents/projects/ocaml/GogoGame/src/init.o: In function `camlInit__f_1030':
(.text+0x11): undefined reference to `camlPervasives__output_string_1191'
/home/thomas/Documents/projects/ocaml/GogoGame/src/init.o: In function `camlInit__f_1030':
(.text+0x19): undefined reference to `camlPervasives__string_of_int_1130'
/home/thomas/Documents/projects/ocaml/GogoGame/src/init.o: In function `camlInit__f_1030':
(.text+0x20): undefined reference to `camlPervasives'
/home/thomas/Documents/projects/ocaml/GogoGame/src/init.o: In function `camlInit__f_1030':
(.text+0x25): undefined reference to `camlPervasives__output_string_1191'
/home/thomas/Documents/projects/ocaml/GogoGame/src/init.o: In function `camlInit__format_result_1034':
(.text+0x9c): undefined reference to `camlPrintf__sprintf_1414'
/home/thomas/Documents/projects/ocaml/GogoGame/src/init.o: In function `camlInit__entry':
(.text+0xe1): undefined reference to `caml_c_call'
/home/thomas/Documents/projects/ocaml/GogoGame/src/init.o: In function `camlInit__entry':
(.text+0xfb): undefined reference to `caml_c_call'
/home/thomas/Documents/projects/ocaml/GogoGame/src/init.o: In function `camlInit__entry':
(.text+0x115): undefined reference to `caml_c_call'
/home/thomas/Documents/projects/ocaml/GogoGame/src/init.o: In function `camlInit__f_1030':
(.text+0x32): undefined reference to `camlPervasives__print_newline_1276'
collect2: ld returned 1 exit status
make: *** [GogoPlayer] Error 1
IMHO, it seems that there is two errors:
Multiple definitions of main
The linker doesn't find the module Pervasive
I have really no idea how to fix that, maybe I have to link an other file.
Does someone have an idea ?
As asked, I put the code that give these errors. It will be quite simple because there is very little code, most of it was given in an example in the documentation.
init.ml
let f x = print_string "f is applied to "; print_int x; print_newline()
let rec fib n = if n < 2 then 1 else fib(n-1) + fib(n-2)
let format_result n = Printf.sprintf "Result is: %d\n"
let _ =
Callback.register "Arbitrary Name" f;
Callback.register "fib" fib;
Callback.register "format_result" format_result
caml_func.c
#include <stdio.h>
#include <string.h>
#include <caml/mlvalues.h>
#include <caml/callback.h>
void call_caml_f(int x)
{
static value * closure_f = NULL;
if (closure_f == NULL) /* First time around, look up by name */
closure_f = caml_named_value("Arbitrary Name");
caml_callback(*closure_f, Val_int(x));
}
int fib(int n)
{
static value * fib_closure = NULL;
if (fib_closure == NULL) fib_closure = caml_named_value("fib");
return Int_val(caml_callback(*fib_closure, Val_int(n)));
}
char * format_result(int n)
{
static value * format_result_closure = NULL;
if (format_result_closure == NULL)
format_result_closure = caml_named_value("format_result");
return strdup(String_val(caml_callback(*format_result_closure, Val_int(n))));
/* We copy the C string returned by String_val to the C heap
so that it remains valid after garbage collection. */
}
interface.c
#include <stdio.h>
#include "caml_func.c"
#define BYTECODE
int main(int argc, char **argv)
{
#ifdef BYTECODE
caml_startup(argv);
#else
caml_main(argv);
#endif
/* Make sure that stdout is not block buffered. */
setbuf(stdout, NULL);
/* Process GTP commands. */
//gtp_main_loop(commands, stdin, NULL);
// CAML code here ?
return 0;
}
And this is all. Obviously, I skipped all the meaningless stuff as this simple example should work and does not. It must be my Makefile, which follows.
By the way, it's quite ugly. If you have proposals for this kind of application (Caml inside C), or refactoring suggestions, I'll take them all.
Makefile.ocaml
.PHONY: all clean mrproper
# RULES and EXEC are magically set in Makefile.magic
all: depend $(RULES) $(EXE)
#echo [DONE]
mli: $(CAML_ONLY:.ml=.mli)
ml-byte: $(CAML_ONLY:.ml=.cmo)
ml-called-byte: $(CAML_CALLED_BY_C:.ml=.$(OBJ))
ml-nativ: $(CAML_ONLY:.ml=.cmx)
ml-called-nativ: $(CAML_CALLED_BY_C:.ml=.$(OBJ))
c-wrapper: $(C_WRAPPERS:.c=.oo)
c-only: $(C_ONLY:.c=.o)
$(EXE):
$(CC) -o $(BIN)/$(EXE).exe \
$(FLAGS) \
-L$(OCAMLLIB) $(LINKED) -l$(RUNLIB) \
$(wildcard $(SRC)/*.$(OBJ)) $(wildcard $(SRC)/*.oo) # */
%.o: %.c
$(CC) $(FLAGS_C) -c $< -o $(SRC)/$(*F).o
%.mli: %.ml
$(OCAMLC) $(FLAGS_ML) -i $< > $(SRC)/$(*F).mli
%.cmi: %.mli
$(OCAMLC) $(FLAGS_ML) -c $< -o $(SRC)/$(*F).cmi
%.cmo: %.ml
$(CAMLC) $(FLAGS_ML) -c $< -o $(SRC)/$(*F).cmo
%.cmx: %.ml
$(CAMLOPT) $(FLAGSOPT) -c $< -o $(SRC)/$(*F).cmx
# native
%.o: %.ml
$(cd $(SRC))
$(OCAMLC) -output-obj -o $(*F)_camlcode.o \
$(FLAGS_MLC) \
$<
# bytecode
%.ob: %.ml
$(cd $(SRC))
$(OCAMLOPT) -output-obj -o $(*F)_camlcode.ob \
$(FLAGS_MLC) \
$<
%.oo: %.c
$(CC) $(FLAGS_WRAP) -c $< -o $(SRC)/$(*F).oo
clean_mli:
rm -f $(SRC)/*.mli # */
clean:
rm -f $(BIN)/*.{a,o,oo,cmi,cmo,cmx} # */
rm -f $(SRC)/*.{a,o,oo,cmi,cmo,cmx} # */
mrproper: clean, clean_mli
rm -f $(BIN)/$(EXE)
depend:
$(OCAMLDEP) $(INCLUDES) $(SRC)/*.ml $(SRC)/*.mli > .depend # */
include .depend
Your link command is incorrect in two ways:
You need to link with -ldl for dlopen, etc.
You must put libraries after objects that reference them (i.e. your -lcamlrun arguments is in the wrong place on the link line). The order of arguments on the link line matters.
Related
I am getting undefined reference error while trying to compile main that refers to two libraries. I have two files lib1/func1.c and lib2/func2.c in separate folders. Those files contain two functions print1() and print2(), function print1() is calling print2().
I am compiling those separately into two libraries libfunc1.a and libfunc2.a.
But when I am trying to compile main which is calling print1(), I get the following error:
/usr/bin/ld: /home/sv/ztest2/lib1/libfunc1.a(func1.o): in function print1:
/home/sv/ztest2/lib1/func1.c:7: undefined reference to print2
collect2: error: ld returned 1 exit status
make: *** [Makefile:21: DP] Error 1
Here is the code and Makefiles:
Makefile:
TARGET = DP
HOME = /home/slav/FORECAST/ztest2
INCDIRS = -I./ \
-I$(HOME)/lib1 \
-I$(HOME)/lib2
LIBDIRS = -L$(HOME)/lib1 \
-L$(HOME)/lib2
SRCFILES = DP.c
OBJFILES = DP.o
CFLAGS = -g -O3 $(INCDIRS)
all: $(TARGET)
$(TARGET): $(OBJFILES)
cc $(CFLAGS) -o $(TARGET) $(OBJFILES) $(LIBDIRS) -lfunc2 -lfunc1
clean:
-rm *.o $(TARGET)
DP.c:
#include "func1.h"
int main()
{
print1();
return 0;
}
func1.h:
void print1();
func1.c:
#include <stdio.h>
void print1()
{
printf("print1 is called!\n");
print2();
}
func2.h:
extern void print2();
func2.c:
#include <stdio.h>
void print2()
{
printf("print2 is called!\n");
}
Libraries must be listed in the order their symbols are needed.
The command cc $(CFLAGS) -o $(TARGET) $(OBJFILES) $(LIBDIRS) -lfunc2 -lfunc1 tells the linker to first use the func2 library to resolve any pending references in the executable it is building and then to use the func1 library.
Since the linker processes func2 first, and, at the time it does so, there is no pending reference to print2, the linker does not include the module with print2 in the executable.
Later, when the linker is processing func1, it includes the module with print1 in the executable because main uses it. That module print1 uses print2, so including that module adds a new reference to print2. Then, when the linker is done processing func1, it has an unresolved reference. The linker does not go back to func2 to check it again.
Since the func1 library depends on func2, change the link command to cc $(CFLAGS) -o $(TARGET) $(OBJFILES) $(LIBDIRS) -lfunc1 -lfunc2.
(If the func2 library also depends on func1, that is a bad design and should be reconsidered. If it is not changed, asking the linker to reconsider the libraries multiple times, as with -lfunc1 -lfunc2 -lfunc1, might fix the immediate problem, but others can arise.)
I am trying to compile an example program to use HDF-EOS. The example code is taken from the HDF-EOS website (I will therefore only post the top section):
/* This example shows how to read a data field in HDF-EOS2 grid data. */
#include <mfhdf.h>
#include <hdf.h>
#include <HdfEosDef.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
int32 gridfile1;
int32 grid1;
int32 datafield1rank;
int32 datafield1dimsize[32];
int32 datafield1type;
char datafield1dimname[512];
float32 *datafield1data;
int32 i, j;
/* Open 'AMSR_E_L3_RainGrid_B05_200707.hdf' using grid API */
if ((gridfile1 = GDopen("AMSR_E_L3_RainGrid_B05_200707.hdf", DFACC_RDONLY)) == -1) {
fprintf(stderr, "error: cannot open grid 'AMSR_E_L3_RainGrid_B05_200707.hdf'\n");
return -1;
}
return 0;
The corresponding make file looks like this:
HDF4_DIR=<hdf4_path>
HDFEOS2_DIR=<hdfeos2_path>
CC=$(HDF4_DIR)/bin/h4cc
CFLAGS=-I$(HDFEOS2_DIR)/include
LDFLAGS=-L$(HDFEOS2_DIR)/lib
LIBS=-lhdfeos -lGctp
read_grid: read_grid.c
$(CC) $(CFLAGS) $(LDFLAGS) $< $(LIBS) -o $#
In addition to the above mentioned paths I have also added links to the hdf5 library, so my make file looks like this:
HDF4_DIR=<hdf4_path>
HDFEOS2_DIR=<hdfeos2_path>
HDF5_DIR=<hdf5_path>
CC=$(HDF4_DIR)/bin/h4cc
CFLAGS=-I$(HDFEOS2_DIR)/include -I$(HDF4_DIR)/include -I$(HDF5_DIR)/include
LDFLAGS=-L$(HDFEOS2_DIR)/lib64 -L$(HDF4_DIR)/lib64 -L$(HDF5_DIR)/lib64
LIBS=-lhdfeos -lGctp
read_grid: read_grid.c
$(CC) read_hdf_eos.c $(CFLAGS) $(LDFLAGS) $(LIBS) -o $#
The problem now is that it does not compile, throwing linking errors such like this:
<hdfeos2_path>/lib64/libhdfeos.a(GDapi.o): In function `lamazDxDtheta':
<hdfeos2_path>/src/GDapi.c:9579: undefined reference to `sin'
<hdfeos2_path>/src/GDapi.c:9580: undefined reference to `sin'
...
collect2: error: ld returned 1 exit status
So for me this looks like a linking problem, however I have no idea why.
To add to the confusion I get another error:
read_grid.o: In function `main':
read_grid.c:(.text.startup+0x0): multiple definition of `main'
read_grid.o:read_grid.c:(.text.startup+0x0): first defined here
Of course I have not defined main more than once. In a second example program that throws the same linking errors I do not get this error.
So if some one would have an idea on the first problem, the linking, I would be very happy.
SOLUTION:
add -lm at the end of the compile statement in the, removes the linking problem
remove the read_hdf_eos.c in the compile statement, that caused the multiple main issue
Thanks for the comments and hints.
Hello and thank you for your assistance.
I'm attempting to create a simple 'hello world' using only low-level OS X kernel calls to allocate memory and write out to stdout. Why? I'm finishing up chapter 8 of 2nd Edition K&R which is focused on writing standard file library from scratch. It is, of course, totally out of date but the concept of the chapter remains. Anyway, I cannot seem to figure out how to properly link to get everything to work out and are thus earning myself lots of nice undefined symbol errors.
I have parsed through many other questions causing the same error, but have not found any that address how to link in the kernel library I'm attempting to use. The crazy long path in the third #include was needed to just get the thing to compile even prior to the link errors.
The Code:
#include <fcntl.h>
#include <unistd.h> // equivalent to (K&R) #include "syscalls.h"
#include </Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/libkern/OSMalloc.h> // for low-level memory allocation
#define MINSTDIOTAG "com.apple.minstdio" // Used by OSMalloc from <libkern/OSMalloc.h>
#define PAGE_SIZE_64K (64 * 1024) // Page size to allocate
int main(void) {
char *base = NULL; // Memory buffer
char *ptr = base; // Location in buffer
// Create tag
OSMallocTag mytag = OSMalloc_Tagalloc(MINSTDIOTAG, OSMT_DEFAULT);
// Attempt to allocate PAGE_SIZE_64K of memory
if ((base = (char *)OSMalloc(PAGE_SIZE_64K, mytag)) == NULL)
return 1;
ptr = base;
// Stuff the buffer with stuff
*ptr++ = 'f';
*ptr++ = 'o';
*ptr++ = 'o';
*ptr++ = '\n';
*ptr = '\0';
// Write it out to stdout
(void)write(STDOUT_FILENO, base, (size_t)(ptr - base));
// Free allocated memory
OSFree(base, PAGE_SIZE_64K, mytag);
// Get out of Dodge City, Kansas
return 0;
}
Makefile:
BIN = ../../bin
ODIR = obj
CC = cc
CFLAGS = -std=c99 -Wall -g -I.
_OBJ = minstdio3.o
_BIN = minstdio3
OBJ = $(patsubst %,$(ODIR)/%,$(_OBJ))
.PHONY: all clean
all: $(_BIN)
clean:
rm -rv $(ODIR) $(_BIN)
minstdio3: $(ODIR)/minstdio3.o
$(CC) $(CFLAGS) $^ -o $#
cp -v $# $(BIN)/$#
$(ODIR)/%.o: %.c $(DEPS)
mkdir -pv $(ODIR)
$(CC) $(CFLAGS) -c -o $# $<
Errors Received:
Todds-MBP-2:cbasics todddecker$ make
mkdir -pv obj
cc -std=c99 -Wall -g -I. -c -o obj/minstdio3.o minstdio3.c
cc -std=c99 -Wall -g -I. obj/minstdio3.o -o minstdio3
Undefined symbols for architecture x86_64:
"_OSFree", referenced from:
_main in minstdio3.o
"_OSMalloc", referenced from:
_main in minstdio3.o
"_OSMalloc_Tagalloc", referenced from:
_main in minstdio3.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [minstdio3] Error 1
-- EDITS --
"Why are you not using the sbrk system call if you want low-level? This would match your use of write and shouldn't give any linking issues." (from CRD)
Using 'sbrk' (and it's cousin 'brk') was the original path I was headed down; however, the man page for 'sbrk' states, "The brk and sbrk functions are historical curiosities left over from earlier days before the advent of virtual memory management." This statement put me on a path toward trying to discover its replacement. 'malloc' is, of course, the correct and normal utility for memory allocation. However, K&R Chapter 8 is all about writing your own from base OS system calls. So, the base call I was able to find for OS X Darwin is 'OSMalloc' which I'm trying to use.
OSMalloc is only available for writing the kernel itself (kernel extensions, device drivers). User programs have to use sbrk.
I'm attempting to convert a go library to be called by C and I'm starting with a simple test (based on an example answering another question I found that worked) file but I'm getting errors when I try to build. I have a struct in C that I'm trying to pass to a go function which uses data from that struct and returns a value (in this case an integer, but eventually it would be another struct).
Go version: 1.4.2
gccgo version: 5.0.1
gcc version: 4.9.2
type.h
typedef struct num {
int n;
} num;
foo.go
package main
// #include "type.h"
import "C"
func New(x int) C.struct_num {
num := C.struct_num{}
num.n = C.int(x)
return num
}
func Add(num C.struct_num, x int) int {
return int(num.n) + x
}
bar.c
#include <stdio.h>
#include "type.h"
extern num go_new(int) __asm__ ("example.main.New");
extern int go_add(num, int) __asm__ ("example.main.Add");
int main() {
num n = go_new(2);
int x = go_add(n, 3);
printf("Result: %d\n", x);
}
Makefile
all: main
main: foo.o bar.c
gcc foo.o bar.c -o main
foo.o: foo.go
go build -compiler gccgo -gccgoflags '-c -o foo.o -fgo-prefix=example' foo.go
clean:
rm -f main *.o
When I run make I get the error:
gcc foo.o bar.c -o main
foo.o:(.rodata.__go_td_pN23_example.main._Ctype_int[__go_td_pN23_example.main._Ctype_int]+0x18): undefined reference to `__go_type_hash_identity'
foo.o:(.rodata.__go_td_pN23_example.main._Ctype_int[__go_td_pN23_example.main._Ctype_int]+0x20): undefined reference to `__go_type_equal_identity'
foo.o:(.rodata.__go_tdn_example.main..example_main._Ctype_int+0x18): undefined reference to `__go_type_hash_identity'
foo.o:(.rodata.__go_tdn_example.main..example_main._Ctype_int+0x20): undefined reference to `__go_type_equal_identity'
foo.o:(.rodata.__go_td_pN30_example.main._Ctype_struct_num[__go_td_pN30_example.main._Ctype_struct_num]+0x18): undefined reference to `__go_type_hash_identity'
foo.o:(.rodata.__go_td_pN30_example.main._Ctype_struct_num[__go_td_pN30_example.main._Ctype_struct_num]+0x20): undefined reference to `__go_type_equal_identity'
foo.o:(.rodata.__go_tdn_example.main..example_main._Ctype_struct_num+0x18): undefined reference to `__go_type_hash_identity'
foo.o:(.rodata.__go_tdn_example.main..example_main._Ctype_struct_num+0x20): undefined reference to `__go_type_equal_identity'
foo.o:(.rodata.__go_td_pN24_example.main._Ctype_void[__go_td_pN24_example.main._Ctype_void]+0x18): undefined reference to `__go_type_hash_identity'
foo.o:(.rodata.__go_td_pN24_example.main._Ctype_void[__go_td_pN24_example.main._Ctype_void]+0x20): undefined reference to `__go_type_equal_identity'
foo.o:(.rodata.__go_tdn_example.main..example_main._Ctype_void+0x18): undefined reference to `__go_type_hash_identity'
foo.o:(.rodata.__go_tdn_example.main..example_main._Ctype_void+0x20): undefined reference to `__go_type_equal_identity'
collect2: error: ld returned 1 exit status
Makefile:4: recipe for target 'main' failed
make: *** [main] Error 1
From what I understand from other searches, these errors relate to the calls made to the C go library, indicating this may not be getting compiled into the object file. I've tried running gccgo directly in the make file as well with the same results. Any insight and/or assistance is appreciated. Thanks.
Edit
I figured this out thanks to this post. Apparently I needed to call gccgo for main in the Makefile since gcc doesn't know how to properly link the go runtime.
I am currently writing a short test app.
The compilation gives me these errors :
CC main.c
Building ../bin/pmono
./main.o:(.data+0x18): undefined reference to `busy'
./main.o:(.data+0x58): undefined reference to `busy'
./main.o:(.data+0x98): undefined reference to `busy'
./main.o:(.data+0xd8): undefined reference to `busy'
./main.o:(.data+0x118): undefined reference to `busy'
./main.o:(.data+0x158): more undefined references to `busy' follow
collect2: ld a retourné 1 code d'état d'exécution
I will try to narrow the code down to the specific parts.
Here is a structure I use which contain the desired reference :
/*
* Chained list of blocks from a frame of the cyclic executive
*/
typedef struct block {
long c; /* Worst case execution time */
long d; /* Deadline */
long p; /* Period */
void (*action) (long); /* Action performed by this frame */
struct block * next;
} *Frame;
The function pointer is placeholder for a generic function not written yet, declared as such in the same .h file :
/*
* Load the CPU for a determined time expressed in nanosecond
*/
void busy(long t);
The function is currently hollow in the c file :
void busy(long t) {
}
Finally, here is a sample default structure I use in my tests :
struct block D = {8,20,20,busy,0};
struct block C = {2,20,20,busy,&D};
struct block B = {3,10,10,busy,&C};
struct block A = {1,10,10,busy,&B};
Frame sequence0 = &A;
All of these parts are contained in a common source file shared between numerous implementations of periodic tasks. The compilation of the object file seems fine.
When I try to compile a given implementation, I first include the .h file, compile the .o file, then try to link the whole thing, using makefile. Here is one makefile to give you an idea :
BIN = ../bin/pmono
CC = gcc
SUBDIR = .
SRC = $(foreach dir, $(SUBDIR), $(wildcard $(dir)/*.c))
OBJ = $(SRC:.c=.o) $(wildcard ../common/*.o)
INCLUDES =
WARNINGS =
OPTIMISATION =
DEBUG =
XENO_CONFIG = /usr/xenomai/bin/xeno-config
XENO_POSIX_CFLAGS = $(shell $(XENO_CONFIG) --skin=posix --cflags)
XENO_POSIX_LDFLAGS = $(shell $(XENO_CONFIG) --skin=posix --ldflags)
CFLAGS = $(INCLUDES) $(XENO_POSIX_CFLAGS) $(WARNINGS) $(OPTIMISATION)
LDFLAGS = -lm $(XENO_POSIX_LDFLAGS) $(DEBUG)
all:.depend $(BIN)
%.o:%.c
#echo "CC $<"
#$(CC) -c $(CFLAGS) $< -o $#
$(BIN): $(OBJ)
#echo "Building ${BIN}"
#$(CC) $(OBJ) -o $# $(LDFLAGS)
clean:
rm -f $(OBJ)
distclean: clean
rm -f $(BIN)
rm -f ./.depend
.depend: $(SRC)
#echo "Génération des dépendances"
#$(CC) $(CFLAGS) -MM $(SRC) > .depend
-include .depend
So, I'm a beginner in this, and this is my understanding : the symbol of the busy function is missing in the main.o, while it exists in the cyclic_executive.o file. I don't understand how this is possible, as I include the cyclic_executive.h file, thus giving the proper declaration and prototype.
I think I'm doing it wrong, but I'm short on idea.
Also, I really dislike how I declare my "default" sequence. I know there is a proper way to do it, but I can't recall it... Does someone has a name to help search for it ?
Thanks.
You are not linking the file with the busy() function call.
Try this from the command line:
gcc main.c cyclic_executive.c
If it works, or at least doesn't give errors on the busy() function, that will confirm the issue. Then try
make all
This should print all the commands as they are executed. If you are still in the dark, try
make -d
That will give you a ton of diagnostics about what make is actually doing.