I'm getting the following linker errors...
/bin/ld: /home/david/C/vcpkg/installed/x64-linux/lib/libFreeImage.a(PluginEXR.cpp.o): in function `InitEXR(Plugin*, int)': PluginEXR.cpp:(.text+0x2ab): undefined reference to `Imf_2_5::staticInitialize()' /bin/ld: /home/david/C/vcpkg/installed/x64-linux/lib/libFreeImage.a(PluginEXR.cpp.o): in function `Save(FreeImageIO*, FIBITMAP*, void*, int, int, void*)': PluginEXR.cpp:(.text+0x45b): undefined reference to `iex_debugTrap()' /bin/ld: PluginEXR.cpp:(.text+0x639): undefined reference to `Imf_2_5::OStream::OStream(char const*)' /bin/ld: PluginEXR.cpp:(.text+0x719): undefined reference to `Imf_2_5::Header::Header(Imath_2_5::Box<Imath_2_5::Vec2<int> > const&, Imath_2_5::Box<Imath_2_5::Vec2<int> > const&, float, Imath_2_5::Vec2<float> const&, float, Imf_2_5::LineOrder, Imf_2_5::Compression)' /bin/ld: PluginEXR.cpp:(.text+0x7db): undefined reference to `iex_debugTrap()' /bin/ld: PluginEXR.cpp:(.text+0x9ac): undefined reference to `iex_debugTrap()' /bin/ld: PluginEXR.cpp:(.text+0xbe1): undefined reference to `Imf_2_5::PreviewImage::PreviewImage(unsigned int, unsigned int, Imf_2_5::PreviewRgba const*)' /bin/ld: PluginEXR.cpp:(.text+0xd4e): undefined reference to `Imf_2_5::Header::channels()' /bin/ld: PluginEXR.cpp:(.text+0xd70): undefined reference to `Imf_2_5::Channel::Channel(Imf_2_5::PixelType, int, int, bool)' /bin/ld: PluginEXR.cpp:(.text+0xd86): undefined reference to `Imf_2_5::ChannelList::insert(char const*, Imf_2_5::Channel const&)'
(shortened for brevity, full log here)
when using g++ to link, I am passing -lIlmImf-2_5, I've checked this file with `nm' and it seems to have the symbols that the linker is looking for.
$ nm --demangle libIlmImf-2_5.a | grep staticInit
0000000000000ec0 T Imf_2_5::staticInitialize()
0000000000000033 t Imf_2_5::staticInitialize() [clone .cold]
0000000000000000 b Imf_2_5::staticInitialize()::initialized
0000000000000020 b Imf_2_5::staticInitialize()::criticalSection
$ nm --demangle libIlmImf-2_5.a | grep iex
U iex_debugTrap()
U iex_debugTrap()
U iex_debugTrap()
U iex_debugTrap()
U iex_debugTrap()
...
Does anyone know how to fix this?
Edit: I now understand that the order of the libs matters, thanks n-1-8e9. However I still have some problems I can't sort out.
/bin/ld: /home/david/C/vcpkg/installed/x64-linux/lib/libshaderc_util.a(compiler.cc.o): in function `shaderc_util::GlslangInitializer::GlslangInitializer()':
compiler.cc:(.text+0x59): undefined reference to `glslang::InitializeProcess()'
This error message tells me that I need -lglslang after -lshaderc_util but I already have it that way...
-lshaderc -lshaderc_util -lglslang -lglslang-default-resource-limits
How do I fix it?
Related
I want to test an example of cfs Contiki on Wismote. I used the example here:
Coffee filesystem example
This example works well on sky mote. when I want to implement on Wismote I change the target to Wismote and here is the makefile :
CONTIKI_PROJECT = [project_name]
all: $(CONTIKI_PROJECT)
#UIP_CONF_IPV6=1
CONTIKI_WITH_RIME = 1 CFLAGS =-DUIP_CONF_IPV6
MODULES += core/net/ipv6/multicast
ifeq ($(TARGET),avr-raven)
COFFEE_FILES = 4
endif
CONTIKI =../../../
include $(CONTIKI)/Makefile.include
After compiling, I get this error message :
/usr/local/msp430/bin/../lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: cfstest.wismote section .data' will not fit in regionrom'
/usr/local/msp430/bin/../lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: section .vectors loaded at [0000ff80,0000ffff] overlaps section .data loaded at [0000fe82,0000ff81]
/usr/local/msp430/bin/../lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: region rom' overflowed by 2 bytes
contiki-wismote.a(cfs-coffee.o): In functioncfs_coffee_get_protected_mem':
/home/user/contiki/examples/mySim/Dscv/../../..//core/cfs/cfs-coffee.c:1369: undefined reference to xmem_pread'
/home/user/contiki/examples/mySim/Dscv/../../..//core/cfs/cfs-coffee.c:1369: undefined reference toxmem_pread'
/home/user/contiki/examples/mySim/Dscv/../../..//core/cfs/cfs-coffee.c:1369: undefined reference to xmem_pwrite'
/home/user/contiki/examples/mySim/Dscv/../../..//core/cfs/cfs-coffee.c:1369: undefined reference toxmem_erase'
/home/user/contiki/examples/mySim/Dscv/../../..//core/cfs/cfs-coffee.c:1369: undefined reference to xmem_pread'
/home/user/contiki/examples/mySim/Dscv/../../..//core/cfs/cfs-coffee.c:1369: undefined reference toxmem_pread'
/home/user/contiki/examples/mySim/Dscv/../../..//core/cfs/cfs-coffee.c:1369: undefined reference to xmem_pread'
/home/user/contiki/examples/mySim/Dscv/../../..//core/cfs/cfs-coffee.c:1369: undefined reference toxmem_pread'
/home/user/contiki/examples/mySim/Dscv/../../..//core/cfs/cfs-coffee.c:1369: undefined reference to xmem_pwrite'
/home/user/contiki/examples/mySim/Dscv/../../..//core/cfs/cfs-coffee.c:1369: undefined reference toxmem_pread'
/home/user/contiki/examples/mySim/Dscv/../../..//core/cfs/cfs-coffee.c:1369: undefined reference to xmem_pread'
/home/user/contiki/examples/mySim/Dscv/../../..//core/cfs/cfs-coffee.c:1369: undefined reference toxmem_pwrite'
/home/user/contiki/examples/mySim/Dscv/../../..//core/cfs/cfs-coffee.c:1369: undefined reference to xmem_pwrite'
/home/user/contiki/examples/mySim/Dscv/../../..//core/cfs/cfs-coffee.c:1369: undefined reference toxmem_pwrite'
/home/user/contiki/examples/mySim/Dscv/../../..//core/cfs/cfs-coffee.c:1369: undefined reference to `xmem_pwrite'
collect2: error: ld returned 1 exit status
rm cfstest.co obj_wismote/contiki-wismote-main.o
make: *** [cfstest.wismote] Error 1
Process returned error code 2
I checked core/cfs/cfs-coffee.c to see the code in line 1369, but as you can see in cfs-coffee.c, there was not such a line.
Does anyone has any idea to solve the 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 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.
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