So there's plenty of information about calling C APIs from within D, but how about the reverse? What do you need to do to write a library in D that works like a normal C shared library? Here's an easy case:
main.c
extern int foo(int x);
void main() {
printf("foo(5)=%d\n",foo(5));
}
foo.d
extern(C)
{
int foo(int x)
{
return x*x;
}
}
Naively trying to build and link these with gcc and dmd just results in linker errors.
Linking with gcc main.o foo.o:
doFoo.o: In function `no symbol':
doFoo.d:(.text+0x7): undefined reference to `_Dmodule_ref'
collect2: ld returned 1 exit status
Linking with dmd main.o foo.o:
/usr/lib64/libphobos2.a(deh2_2eb_525.o): In function `_D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0xa): undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x14): undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x1e): undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x46): undefined reference to `_deh_end'
/usr/lib64/libphobos2.a(lifetime.o): In function `_D2rt8lifetime18_sharedStaticCtor9FZv':
src/rt/lifetime.d:(.text._D2rt8lifetime18_sharedStaticCtor9FZv+0x15): undefined reference to `_tlsend'
src/rt/lifetime.d:(.text._D2rt8lifetime18_sharedStaticCtor9FZv+0x29): undefined reference to `_tlsstart'
/usr/lib64/libphobos2.a(thread_a3_258.o): In function `_D4core6thread6Thread6__ctorMFPFZvmZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvmZC4core6thread6Thread+0x2b): undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvmZC4core6thread6Thread+0x36): undefined reference to `_tlsstart'
/usr/lib64/libphobos2.a(thread_a3_258.o): In function `_D4core6thread6Thread6__ctorMFDFZvmZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvmZC4core6thread6Thread+0x28): undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvmZC4core6thread6Thread+0x33): undefined reference to `_tlsstart'
/usr/lib64/libphobos2.a(thread_a3_258.o): In function `_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x26): undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x31): undefined reference to `_tlsstart'
/usr/lib64/libphobos2.a(thread_a0_713.o): In function `thread_entryPoint':
src/core/thread.d:(.text.thread_entryPoint+0x36): undefined reference to `_tlsend'
src/core/thread.d:(.text.thread_entryPoint+0x41): undefined reference to `_tlsstart'
collect2: ld returned 1 exit status
--- errorlevel 1
My answer is about using D static libraries from C.
Yes, this is a bit off topic, but shared libraries for Windows are described in D's documentation (http://www.d-programming-language.org/dll.html) and for Linux are still under construction (http://www.digitalmars.com/d/2.0/changelog.html). Working examples for both systems are attached.
Win32: dmd+dmc works great. Example: test_d_from_c_win32.zip
Linux32: dmd adds some required stuff once it has found D main function, so D's main is needed (tested for dmd2+gcc on Linux32).
It's linkage name is "_Dmain" and it will not be mixed with C's one (real "main").
So one can just add the file dfakemain.d with text void main(){}.
dmd -c dfakemain.d will create dfakemain.o with missing symbols. Link it with your object files and you will be happy. Example: test_d_from_c_linux32.tar.gz
According to a quick glance at the compiler source code, _Dmodule_ref is the linked list of module constructors. To fix the issue, add this to your main.c:
void* _Dmodule_ref;
The program now links and runs fine.
(At least, that's how I think it works.)
If gcc is compiling as C++, the default linkage used for the extern will be C++, not C. Try this instead:
extern "C" int foo(int x);
There does not seem to be anything wrong with your D syntax. There is a paragraph confirming your approach here: http://www.digitalmars.com/d/2.0/interfaceToC.html
Related
I am working on a school project with Nachos and I am receiving some strange error. You can see my code here: just the c file, lemme know if you need more
The output from the console looks like this:
../gnu/gcc -G 0 -c -I../userprog -I../threads -I../machine -c threadtest.c
../gnu/ld -T newscript -N start.o threadtest.o -o threadtest.coff
threadtest.o: In function `CreateClerk':
threadtest.c:804: undefined reference to `memcpy'
threadtest.o: In function `ApplicationClerkNoCustomerAtRegister':
threadtest.c:902: undefined reference to `memcpy'
threadtest.c:902: undefined reference to `memcpy'
threadtest.c:902: undefined reference to `memcpy'
threadtest.o: In function `PictureClerkNoCustomerAtRegister':
threadtest.c:954: undefined reference to `memcpy'
threadtest.o:threadtest.c:954: more undefined references to `memcpy' follow
gmake: *** [threadtest] Error 1
In my entire Nachos project folder there isn't one single call to 'memcpy' (I did a find in files search with Brackets).
Here is line 804+:
struct Clerk CreateClerk(char* _name, int _number, struct PassportOffice* _theOffice, struct Line* theLine) {
struct Clerk theClerk;
theClerk.name = _name;
theClerk.number = _number;
theClerk.theOffice = _theOffice;
theClerk.myLine = theLine;
LineSetClerk(theClerk.myLine,&theClerk);
theClerk.dataLock = CreateLock("dataLock",8);
theClerk.myBribeCV = CreateCV("myBribeCV",9);
theClerk.breakCV = CreateCV("breakCV",7);
theClerk.breakLock = CreateLock("breakLock",9);
theClerk.walkUpCV = CreateCV("walkUpCV",8);
return theClerk;
}
You should use gcc to link, not ld.
When you link via gcc it supplies the system libraries to ld . If you link via ld you have to specify all that yourself, and a pile of other things.
I am compiling a test program to test the fftw3 (ver3.3.4). Since it is not installed with root previlidge the command I used is:
gcc -lm -L/home/my_name/opt/fftw-3.3.4/lib/ -I/home/my_name/opt/fftw-3.3.4/include/ fftwtest.c
where the library is installed in
/home/my_name/opt/fftw-3.3.4/
My code is the 1st tutorial on fftw3's website:
#include <stdio.h>
#include <fftw3.h>
int main(){
int n = 10;
fftw_complex *in, *out;
fftw_plan p;
in = (fftw_complex*) fftw_malloc(n*sizeof(fftw_complex));
out = (fftw_complex*) fftw_malloc(n*sizeof(fftw_complex));
p = fftw_plan_dft_1d(n, in, out, FFTW_FORWARD, FFTW_ESTIMATE);
fftw_execute(p); /* repeat as needed */
fftw_destroy_plan(p);
fftw_free(in); fftw_free(out);
return 0;
}
when I compiled the program it returns me following errors:
/tmp/ccFsDL1n.o: In function `main':
fftwtest.c:(.text+0x1d): undefined reference to `fftw_malloc'
fftwtest.c:(.text+0x32): undefined reference to `fftw_malloc'
fftwtest.c:(.text+0x56): undefined reference to `fftw_plan_dft_1d'
fftwtest.c:(.text+0x66): undefined reference to `fftw_execute'
fftwtest.c:(.text+0x72): undefined reference to `fftw_destroy_plan'
fftwtest.c:(.text+0x7e): undefined reference to `fftw_free'
fftwtest.c:(.text+0x8a): undefined reference to `fftw_free'
collect2: ld returned 1 exit status
A quick search implies that I am not linking to the library correctly, but interestingly it does not complain about the declaration of fftw_plan and fftw_complex. In fact if I remove all functions starting with "fftw_", keeping only the declaration, it will pass the compilation.
So where did I go wrong? Is the linking correct? Any suggestion would be appreciated.
You have told the linker where to find the library through -L, but you haven't told it which library to link to. The latter you do by adding -lfftw3 at the end of the line, before -lm.
Additionally, the -L flag needs to be listed after fftwtest.c.
You need to also add that you link to the fftw library.
Add something like:
-lfftw
It depends on what the library file is actually called. (Note how you do that for the math library with -lm.)
I wrote a makefile to link all the .c files that i wanted to.But then again i get errors of undefined reference.The code for the makefile is:
FILES.o=set.o hash.o nfa.o printnfa.o input.o terp.o dfa.o minimize.o defnext.o print_ar.o pairs.o squash.o print.o assort.o prnt.o printv.o bintoasc.o ferr.o onferr.o fputstr.o pchar.o driver.o searchenv.o hashadd.o
PROGRAM= lexer
all: ${PROGRAM}
${PROGRAM}: ${FILES.o}
${CC} -o $# ${CFLAGS} $^ ${LDFLAGS} ${LDLIBS}
But still it leads to undefined errors like :
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crt1.o: In function `_start':(.text+0x20): undefined reference to `main'
nfa.o: In function `parse_err':
nfa.c:(.text+0x21): undefined reference to `Actual_lineno'
nfa.o: In function `save':
nfa.c:(.text+0x2d1): undefined reference to `Lineno'
nfa.o: In function `advance':
nfa.c:(.text+0x8b4): undefined reference to `esc'
nfa.o: In function `rule':
nfa.c:(.text+0xae1): undefined reference to `Unix'
nfa.o: In function `term':
nfa.c:(.text+0xfbd): undefined reference to `Unix'
nfa.c:(.text+0x10a2): undefined reference to `Unix'
nfa.o: In function `thompson':
nfa.c:(.text+0x1355): undefined reference to `CLEAR_STACK'
nfa.c:(.text+0x13ab): undefined reference to `Verbose'
nfa.c:(.text+0x13d3): undefined reference to `printf_nfa'
nfa.c:(.text+0x13d9): undefined reference to `Verbose'
input.o: In function `get_expr':
input.c:(.text+0x13): undefined reference to `Input_buf'
input.c:(.text+0x20): undefined reference to `Verbose'
input.c:(.text+0x2b): undefined reference to `Actual_lineno'
input.c:(.text+0x52): undefined reference to `Actual_lineno'
input.c:(.text+0x7a): undefined reference to `Actual_lineno'
input.c:(.text+0x83): undefined reference to `Actual_lineno'
input.c:(.text+0x8a): undefined reference to `Input_buf'
input.c:(.text+0x93): undefined reference to `Input_buf'
input.c:(.text+0xe2): undefined reference to `Ifile'
input.c:(.text+0x10c): undefined reference to `Verbose'
input.c:(.text+0x11c): undefined reference to `Input_buf'
input.c:(.text+0x136): undefined reference to `Input_buf'
dfa.o: In function `dfa':
dfa.c:(.text+0x69): undefined reference to `Verbose'
dfa.c:(.text+0x1c6): undefined reference to `Verbose'
dfa.c:(.text+0x215): undefined reference to `Verbose'
dfa.o: In function `get_unmarked':
dfa.c:(.text+0x3a8): undefined reference to `Verbose'
minimize.o: In function `init_groups':
minimize.c:(.text+0x28c): undefined reference to `Verbose'
minimize.o:minimize.c:(.text+0x550): more undefined references to `Verbose' follow
print.o: In function `pdriver':
print.c:(.text+0x483): undefined reference to `No_lines'
print.c:(.text+0x4eb): undefined reference to `No_lines'
print.c:(.text+0x4f6): undefined reference to `Input_file_name'
print.c:(.text+0x585): undefined reference to `No_lines'
collect2: error: ld returned 1 exit status
make: *** [lexer] Error 1
All the undefined references are however present in 2 header files :1.stack.h 2.global.h..Still the errors.please help!
The global.h file i am using is:
#ifndef __GLOBAL_H
#define __GLOBAL_H
#include <stdio.h>
#ifdef ALLOC
# define CLASS
# define I(x) x
#else
# define CLASS extern
# define I(x)
#endif
#define MAXINP 2048
CLASS int Verbose I(=0);
CLASS int No_lines I(=0);
CLASS int Unix I(=0);
CLASS int Public I(=0);
CLASS char *Template I(="lex.par");
CLASS int Actual_lineno I(=1);
CLASS int Lineno I(=1);
CLASS char Input_buf[MAXINP]; //line buffer for input
CLASS char *Input_file_name; //Input file name
CLASS FILE *Ifile; //Input Stream
CLASS FILE *ofile; //Output Stream
#endif
Your problem isn't related to the Makefile per se. The header-only include file global.h contains declarations of variables. These declarations have to be turned into actual definitions in one compilation unit, so that they have space for them allocated in one of your object files.
The way your header file is designed, the definition of the variable ALLOC determines whether the variables are just declared or defined.
The regular include without ALLOC yields for example:
extern int Verbose;
The extern keyword indicates that the variable Verbose is not defined. No memory is allocated for it (and it therefore can't have an initialiser) and that it is probably defined in another object file.
When ALLOC is defined, the declaration becomes a definition with initialisation:
int Verbose = 0;
Pick one of the files that include global.h and define ALLOC before including it, for example:
input.c
#define ALLOC
#include "global.h"
You should then have the symbol Verbose defined as an int with initial value 0 in global.o:
> nm input.o | grep Verbose
0000000000000000 B Verbose
> nm set.o | grep Verbose
U Verbose
(nm is a Linux utility that lists the symbols in an object file. Windows has dumpbin.)
The U in the object file without ALLOC means that the symbol is undefined, i.e. referenced but not defined in this object file. The B in input.o denotes the section where the symol is defined. When you link, you can have many Us, but for each symbol that is undefined in an object file, you also need one object file where the symbol is defined.
you should add header files in all files which are contained in makefile...
otherwise those files will not able to recognize those variables
For some reason this line of code is giving me quite a problem.
struct socketaddr_in clientaddr;
The error message is:
tiny.c:23:24: error: storage size of ‘clientaddr’ isn’t known
If I remove that line of code I get the following error message:
s2s2#s2s2-ThinkPad-T61:~/Documents/Cprogramming/web_server$ make
gcc -std=gnu99 -O2 -lpthread -lrt -o server tiny.c csapp.c
/tmp/ccVxw07i.o: In function `Pthread_create':
csapp.c:(.text+0x7e5): undefined reference to `pthread_create'
/tmp/ccVxw07i.o: In function `Pthread_cancel':
csapp.c:(.text+0x805): undefined reference to `pthread_cancel'
/tmp/ccVxw07i.o: In function `Pthread_join':
csapp.c:(.text+0x825): undefined reference to `pthread_join'
/tmp/ccVxw07i.o: In function `Pthread_detach':
csapp.c:(.text+0x845): undefined reference to `pthread_detach'
/tmp/ccVxw07i.o: In function `Sem_init':
csapp.c:(.text+0x895): undefined reference to `sem_init'
/tmp/ccVxw07i.o: In function `P':
csapp.c:(.text+0x8b5): undefined reference to `sem_wait'
/tmp/ccVxw07i.o: In function `V':
csapp.c:(.text+0x8d5): undefined reference to `sem_post'
/tmp/ccVxw07i.o: In function `Pthread_once':
csapp.c:(.text+0x881): undefined reference to `pthread_once'
collect2: ld returned 1 exit status
make: *** [webServer-gcc] Error 1
Here are links to the csapp.c and csapp.h files.
Thanks for all the help.
tiny.c:23:24: error: storage size of ‘clientaddr’ isn’t known
There's a reason you need to declare structs as struct structname instancename in C - that's so that the C compiler knows how much memory to allocate - and possibly how to align that data, etc.
This is the C compiler's way of telling you no such struct socketaddr_in exists - it'd be sockaddr_in.
A common way to work around the naming of structs in this way is to define them like this:
typedef struct _struct_name
{
/* ... */
} structname;
then structname can be used as a type without the struct qualifier. You don't have to do this on the definition of the struct, either, you could do it later.
So, the short answer is socketaddr_in doesn't exist as a struct in POSIX - it's sockaddr_in.
Just a simple program, but I keep getting this compiler error. I'm using MinGW for the compiler.
Here's the header file, point.h:
//type for a Cartesian point
typedef struct {
double x;
double y;
} Point;
Point create(double x, double y);
Point midpoint(Point p, Point q);
And here's point.c:
//This is the implementation of the point type
#include "point.h"
int main() {
return 0;
}
Point create(double x, double y) {
Point p;
p.x = x;
p.y = y;
return p;
}
Point midpoint(Point p, Point q) {
Point mid;
mid.x = (p.x + q.x) / 2;
mid.y = (p.y + q.y) / 2;
return mid;
}
And here's where the compiler issue comes in. I keep getting:
testpoint.c: undefined reference to 'create(double x, double y)'
While it is defined in point.c.
This is a separate file called testpoint.c:
#include "point.h"
#include <assert.h>
#include <stdio.h>
int main() {
double x = 1;
double y = 1;
Point p = create(x, y);
assert(p.x == 1);
return 0;
}
I'm at a loss as to what the issue could be.
How are you doing the compiling and linking? You'll need to specify both files, something like:
gcc testpoint.c point.c
...so that it knows to link the functions from both together. With the code as it's written right now, however, you'll then run into the opposite problem: multiple definitions of main. You'll need/want to eliminate one (undoubtedly the one in point.c).
In a larger program, you typically compile and link separately to avoid re-compiling anything that hasn't changed. You normally specify what needs to be done via a makefile, and use make to do the work. In this case you'd have something like this:
OBJS=testpoint.o point.o
testpoint.exe: $(OBJS)
gcc $(OJBS)
The first is just a macro for the names of the object files. You get it expanded with $(OBJS). The second is a rule to tell make 1) that the executable depends on the object files, and 2) telling it how to create the executable when/if it's out of date compared to an object file.
Most versions of make (including the one in MinGW I'm pretty sure) have a built-in "implicit rule" to tell them how to create an object file from a C source file. It normally looks roughly like this:
.c.o:
$(CC) -c $(CFLAGS) $<
This assumes the name of the C compiler is in a macro named CC (implicitly defined like CC=gcc) and allows you to specify any flags you care about in a macro named CFLAGS (e.g., CFLAGS=-O3 to turn on optimization) and $< is a special macro that expands to the name of the source file.
You typically store this in a file named Makefile, and to build your program, you just type make at the command line. It implicitly looks for a file named Makefile, and runs whatever rules it contains.
The good point of this is that make automatically looks at the timestamps on the files, so it will only re-compile the files that have changed since the last time you compiled them (i.e., files where the ".c" file has a more recent time-stamp than the matching ".o" file).
Also note that 1) there are lots of variations in how to use make when it comes to large projects, and 2) there are also lots of alternatives to make. I've only hit on the bare minimum of high points here.
I had this issue recently. In my case, I had my IDE set to choose which compiler (C or C++) to use on each file according to its extension, and I was trying to call a C function (i.e. from a .c file) from C++ code.
The .h file for the C function wasn't wrapped in this sort of guard:
#ifdef __cplusplus
extern "C" {
#endif
// all of your legacy C code here
#ifdef __cplusplus
}
#endif
I could've added that, but I didn't want to modify it, so I just included it in my C++ file like so:
extern "C" {
#include "legacy_C_header.h"
}
(Hat tip to UncaAlby for his clear explanation of the effect of extern "C".)
I think the problem is that when you're trying to compile testpoint.c, it includes point.h but it doesn't know about point.c. Since point.c has the definition for create, not having point.c will cause the compilation to fail.
I'm not familiar with MinGW, but you need to tell the compiler to look for point.c. For example with gcc you might do this:
gcc point.c testpoint.c
As others have pointed out, you also need to remove one of your main functions, since you can only have one.
Add the "extern" keyword to the function definitions in point.h
I saw here that this question
In c programming language, i keep getting this error
has been answered here so the thread seems closed for answers.
I disagree. It is different code.
The answer should be that we don't know what is in custom header file "functions.h".
Also, we don't know what are
MAPA m;
POSICAO heroi;
Are these functions, constants?
If these were some constants, one should expect #define in front of them, and no semicolon e.g.
#define MAPA m
#define POSICAO heroi
If You intended to prototype the function, since there's is semicolon behing, than You did not insert the parentheses ().
In that case MAPA and POSICAO are some custom-type functions, whose content should be determined in "Functions.h"
Also, there's a possibilty that You wanted to import the functions or variable or constant from some other directory, and in that case You're missing the word
extern MAPA m;
I had a similar problem running a bunch of .c files in a directory all linking to one header file with custom function prototypes.
I ran:
$gcc -Wall -Werror -Wextra -pedantic -std=gnu89 *.c
Getting these errors:
/usr/bin/ld: /tmp/ccovH4zH.o: in function `_puts': 3-puts.c:(.text+0x2f): undefined reference to `_putchar'
/usr/bin/ld: 3-puts.c:(.text+0x51): undefined reference to `_putchar'
/usr/bin/ld: /tmp/ccGeWRqI.o: in function `main': _putchar.c:(.text+0xe): undefined reference to `_putchar'
/usr/bin/ld: _putchar.c:(.text+0x18): undefined reference to `_putchar'
/usr/bin/ld: _putchar.c:(.text+0x22): undefined reference to `_putchar'
/usr/bin/ld: /tmp/ccGeWRqI.o:_putchar.c:(.text+0x2c): more undefined references to `_putchar' follow
collect2: error: ld returned 1 exit status
Note: All files were linked to the same header file with all the function declarations.
I manage to compile successfully after adding -c option to the gcc compiler like:
$gcc -Wall -Werror -Wextra -pedantic -std=gnu89 -c *.c
This run successfully.
Just in case anyone comes across the same.