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.
Related
I am trying to compile a C file containing this code :
#include <stdio.h>
#include <stdlib.h>
#include <curl/curl.h>
int main()
{
curl_global_init( CURL_GLOBAL_ALL );
CURL * myHandle;
CURLcode result; // We’ll store the result of CURL’s webpage retrieval, for simple error checking.
myHandle = curl_easy_init ( ) ;
// Notice the lack of major error checking, for brevity
curl_easy_setopt(myHandle, CURLOPT_URL, "http://www.example.com");
result = curl_easy_perform( myHandle );
curl_easy_cleanup( myHandle );
printf("LibCurl rules!\n");
return 0;
}
,
Well when I try to compile :
gcc url.c -lcurl
I get the following errors:
F:\MinGW\home>gcc url.c -lcurl
C:\Users\Ehsan\AppData\Local\Temp\ccF7doFN.o:url.c:(.text+0x8e): undefined reference to `_imp__curl_global_init'
C:\Users\Ehsan\AppData\Local\Temp\ccF7doFN.o:url.c:(.text+0x95): undefined reference to `_imp__curl_easy_init'
C:\Users\Ehsan\AppData\Local\Temp\ccF7doFN.o:url.c:(.text+0xbf): undefined reference to `_imp__curl_easy_setopt'
C:\Users\Ehsan\AppData\Local\Temp\ccF7doFN.o:url.c:(.text+0xcd): undefined reference to `_imp__curl_easy_perform'
C:\Users\Ehsan\AppData\Local\Temp\ccF7doFN.o:url.c:(.text+0xdf): undefined reference to `_imp__curl_easy_cleanup'
collect2.exe: error: ld returned 1 exit status
I downloaded this distribution
and copied all files to bin, include , and lib folder.
What am I missing?
Update
Well I fixed the problem by using -lcurldll.
In my lib folder I have both libcurl.a and libcurldll.a.
Why linking with libcurl.a can't compile but with libcurldll.a it works fine?
You can check the lib name by:
readelf -d [LIB_PATH]
That would solve you the problem.
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
I'm trying to build a basic FANN (Fast Artificial Neural Network) project on Windows with MinGW. However, whenever I try to link the executable, I run into a bunch of undefined reference to errors. Interestingly, if I don't link the library at all, I get more errors, implying that at least some of the library is working. The code for the file I'm trying to compile and link is:
#include "doublefann.h"
int main() {
const unsigned int num_input_neurons = 9;
const unsigned int num_output_neurons = 1;
const unsigned int num_layers = 3;
const unsigned int num_hidden_neurons = 9;
const float desired_error = (const float) 0;
const unsigned int max_epochs = 500000;
const unsigned int epochs_between_reports = 1000;
struct fann *ann = fann_create_standard(num_layers,
num_input_neurons,
num_hidden_neurons,
num_output_neurons);
fann_set_activation_function_hidden(ann, FANN_SIGMOID_SYMMETRIC);
fann_set_activation_function_output(ann, FANN_SIGMOID_SYMMETRIC);
fann_train_on_file(ann,
"titanic-training.data",
max_epochs,
epochs_between_reports,
desired_error);
fann_save(ann, "titanic.net");
fann_destroy(ann);
return 0;
}
and the command I'm using to compile and link is:
gcc -Wall -Ifann\src\include titanic-train.c -Lfann\bin -lfanndouble -o titanic-train.exe
The errors I'm getting back are:
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0x7f): undefined reference to `fann_set_activation_function_hidden'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0x93): undefined reference to `fann_set_activation_function_output'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0xbf): undefined reference to `fann_train_on_file'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0xd3): undefined reference to `fann_save'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0xdf): undefined reference to `fann_destroy'
c:/fragileprograms/mingw-native/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o: bad reloc address 0x64 in section `.rdata'
c:/fragileprograms/mingw-native/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: final link failed: Invalid operation
collect2.exe: error: ld returned 1 exit status
If I don't link the library at all, I instead get:
C:\Users\kunkelwe\AppData\Local\Temp\ccyOO3jL.o:titanic-train.c:(.text+0x67): undefined reference to `fann_create_standard'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0x7f): undefined reference to `fann_set_activation_function_hidden'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0x93): undefined reference to `fann_set_activation_function_output'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0xbf): undefined reference to `fann_train_on_file'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0xd3): undefined reference to `fann_save'
C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o:titanic-train.c:(.text+0xdf): undefined reference to `fann_destroy'
c:/fragileprograms/mingw-native/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:\Users\kunkelwe\AppData\Local\Temp\ccsWQg66.o: bad reloc address 0x64 in section `.rdata'
c:/fragileprograms/mingw-native/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: final link failed: Invalid operation
collect2.exe: error: ld returned 1 exit status
Edit:
As per Haroogan's request, I ran nm fanndouble.lib. The output is rather extensive, so rather than paste it all here, I've made it available via pastebin here: http://pastebin.com/raw.php?i=vybFhEcX
I'm not familiar with nm, but it appears that the missing symbols do exist in the file.
Edit #2:
The contents of doublefann.h are: http://pastebin.com/mrHKJi8C
and the contents of fann.h, which it includes are: http://pastebin.com/gTrHCYAg
Could the problem just be solved by recompiling the library with MinGW?
Edit #3:
Making the changes that Haroogan suggested worked! In addition to those changes, I had to modify the CMakeLists.txt file for FANN by adding:
if (WIN32)
ADD_DEFINITIONS(-DFANN_DLL_EXPORTS)
endif (WIN32)
Then, running cmake -G "MinGW Makefiles" and then mingw32-make in the root of the project produced a file, libdoublefann.dll, that when linked against and included in the directory of the .exe, allowed me, finally, to run my program.
In doublefann.h on the line #116:
#if (_MSC_VER > 1300)
change to:
#if (_MSC_VER > 1300) || defined(__MINGW32__) || defined(__MINGW64__)
Furthermore, on the line #121:
#if defined(_MSC_VER) && (defined(FANN_USE_DLL) || defined(FANN_DLL_EXPORTS))
change to:
#if (defined(_MSC_VER) || defined(__MINGW32__) || defined(__MINGW64__)) && \
(defined(FANN_USE_DLL) || defined(FANN_DLL_EXPORTS))
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.
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