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.
Related
This is the following program.
#include <graphics.h>
int main(void)
{
drawRect(50,100,200,150);
drawLine(50,100,150,25);
drawLine(150,25,250,100);
drawRect(130,190,40,60);
drawRect(70,195,40,30);
drawRect(190,195,40,30);
drawRect(70,125,40,30);
drawRect(190,125,40,30);
return 0;
}
and following is the error
C:\Users\Balavardhan\Desktop\New folder\c language>gcc z.c -o z.exe
z.c: In function 'main':
z.c:4:6: warning: implicit declaration of function 'drawRect'; did you mean 'drawpoly'? [-Wimplicit-function-declaration]
drawRect(50,100,200,150);
^~~~~~~~
drawpoly
z.c:5:6: warning: implicit declaration of function 'drawLine'; did you mean 'drawpoly'? [-Wimplicit-function-declaration]
drawLine(50,100,150,25);
^~~~~~~~
drawpoly
C:\Users\BALAVA~1\AppData\Local\Temp\ccMnl0ZM.o:z.c:(.text+0x2e): undefined reference to `drawRect'
C:\Users\BALAVA~1\AppData\Local\Temp\ccMnl0ZM.o:z.c:(.text+0x52): undefined reference to `drawLine'
C:\Users\BALAVA~1\AppData\Local\Temp\ccMnl0ZM.o:z.c:(.text+0x76): undefined reference to `drawLine'
C:\Users\BALAVA~1\AppData\Local\Temp\ccMnl0ZM.o:z.c:(.text+0x9a): undefined reference to `drawRect'
C:\Users\BALAVA~1\AppData\Local\Temp\ccMnl0ZM.o:z.c:(.text+0xbe): undefined reference to `drawRect'
C:\Users\BALAVA~1\AppData\Local\Temp\ccMnl0ZM.o:z.c:(.text+0xe2): undefined reference to `drawRect'
C:\Users\BALAVA~1\AppData\Local\Temp\ccMnl0ZM.o:z.c:(.text+0x106): undefined reference to `drawRect'
C:\Users\BALAVA~1\AppData\Local\Temp\ccMnl0ZM.o:z.c:(.text+0x12a): undefined reference to `drawRect'
collect2.exe: error: ld returned 1 exit status
Can anyone tell me how can I solve this problem?
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 getting an undefined reference error when trying to link my application with code blocks and command line gcc. The file giving the error has the function prototype in the header. The source file the function the linker is complaining about has other functions in it that aren't giving this error. I copied and pasted the function declarator to the header and calling function (fixing the parameters of course) to ensure it is not a typo. What am I missing? Other functions called from linked_list.c don't give me linker errors.
Here are the code snippets:
mw_proxy.h:
struct addr_l_node
{
uint32_t address;
struct addr_l_node *next;
};
...
typedef struct addr_l_node addr_l_node;
...
void delete_addr_list(addr_l_node *first);
parse_config.c:
#include "mw_proxy.h"
...
addr_l_node *first;
...
delete_addr_list(first);
linked_list.c:
void delete_addr_list(addr_l_node *first)
{
...
}
Finally I am getting this error from code blocks:
obj/Debug/parse_config.o||In function `parse_config':|
/media/sf_H_DRIVE/src/codeblocks/mw_proxy/parse_config.c|240|undefined reference to `delete_addr_list'|
||=== Build finished: 1 errors, 0 warnings ===|
From a bash shell:
gcc int_array.o cleanup.o check_datagram.o mw_proxy.o parse_config.o linked_list.o
parse_config.o: In function `parse_config':
/media/sf_H_DRIVE/src/codeblocks/mw_proxy/parse_config.c:240: undefined reference to `delete_addr_list'
collect2: error: ld returned 1 exit status
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
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