I'm trying to compile a C library and then some external C code liked against it and I'm having issues with my external code finding the symbols within the library. I don't understand the big flick and am hoping someone can help. Here are the details:
1) I'm working on a Mac. I've compiled the library as a static .a library in xcode.
2) I'm attempting to compile external code calling functions from the library. I've included the header file and I'm specifying it's location and the library in the gcc call. The compilation seems to complete ok, but the linking fails stating that symbols cannot be found.
3) The missing symbols are listed as _FunctionName where FunctionName is the name of the function I called.
It is not clear to me why the compiler/linker has added underbars to my function names. But my naive guess is that is why the symbols can not be found in the library.
The external code compilation is being done through MATLAB's mex() function which is making the gcc calls below in the background.
I'd be thankful for any thoughts anyone might have.
gcc-4.2 -c -Igsf_0303/ -I/Applications/MATLAB_R2011b.app/extern/include \
-DMATLAB_MEX_FILE -fno-common -no-cpp-precomp -arch x86_64 -isysroot \
/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.5 -fexceptions \
-DMX_COMPAT_32 -O2 -DNDEBUG "gsf_tester.c"
gcc-4.2 -O -Wl,-twolevel_namespace -undefined error -arch x86_64 -Wl, \
-syslibroot,/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.5 -bundle -Wl,\
-exported_symbols_list,/Applications/MATLAB_R2011b.app/extern/lib/maci64/mexFunction.map \
-o "gsf_tester.mexmaci64" gsf_tester.o gsf_0303/libgsf.a \
-L/Applications/MATLAB_R2011b.app/bin/maci64 -lmx -lmex -lmat -lstdc++
Undefined symbols:
"_gsfOpen", referenced from:
_mexFunction in gsf_tester.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
mex: link of ' "gsf_tester.mexmaci64"' failed.
Here's a guess. Firstly, Joachim's comment is correct. C function names will always be prepended with an underscore. So that's not the issue.
So either gfsOpen() is missing from the library or it's not visible or it can't be seen when gfs_tester.o is linked.
So check that gfsOpen is in the library. This should do it
otool -t -v sgsf_0303/libgsf.a | grep gsfOpen
The above disassembles the file and then greps the symbol you are interested in from it. There's probably a better way, but I haven't bothered to research it.
Check it's not declared static.
Make sure the architecture of the library matches (otool -fv)
Related
I have two static library files (.a) and one bitecode file (.bc) ,which created with an opt pass.In this bitecode file i have added my own code and in this code i need to call a function which is declared in the static libraries. I 've noticed that the llvm-ld tool no longer exists for clang newer versions so i tried two different ways to link these three files (two libraries and one bitecode file):
1. try to link with gcc :
create with llc the object file of file.bc
$llc -filetype=obj file.bc -o file.o
link object and libs with gcc
$gcc -I lib1.a lib2.a -O3 file.o -o file
these commands give me this error:
file.o: In function `main':
file.bc:(.text+0xc0): undefined reference to `function_in_lib'
collect2: error: ld returned 1 exit status
(function_in_lib is the function that i need to call from lib and compilers can't find this function)
2. the second way is with ld command
create with llc the object file of file.bc
$llc -filetype=obj file.bc -o file.o
link object and libs with ld
$ld -o linked lib1.a lib2.a file.o -lc
these commands give me this error:
ld: warning: cannot find entry symbol _start; defaulting to 00000000004002b0
new.o: In function `main':
new.bc:(.text+0xc0): undefined reference to `function_in_lib'
i tried to change the order of arguments but i have more errors when i did it.I think that the fault become from the linking,any idea?
The reason you're getting undefined references is because you're linking your libraries in the wrong way. A linker works in an incremental order - it looks at the first file you provided and gathers a list of things that file references but can't be found. Then the linker moves onto the next library and does the same thing, but also looks for opportunities to fix the undefined references from the previous libraries.
The reason that ld can't find function_in_lib is because it links file.o after the libraries and therefore doesn't get a chance to fill in the references that file.o requires. If you're looking for more specifics about linking and why you're running into this problem, this is a pretty good introduction.
If you just want to fix your problem, move the library files to after file.o in your command, i.e.
ld -o linked file.o lib1.a lib2.a -lc
I am working with c++ code for a physics simulation, which uses a lot of external libraries (like GSL and cern`s ROOT). Trying to recompile project I encountered problems with linking. When running compilation of final file via:
g++ -fno-inline -O2 -fpic -o main.out ${ROOTINCS} main.o ext.o ${ROOTLIBS} $(objects2)
with :
objects2= many .o files made by us
ROOTLIBS=-L/usr/local/lib/root -lTree -lRIO -lNet -lHist -lMathCore -lCore -lGraf -lGraf3d -lGpad -lMatrix -lThread -lCint -lPhysics -lPostscript -lRint -lSpectrum -lg
ROOTINCS=-pthread -m64
I get annoying error:
/usr/bin/ld: /usr/local/lib/root/libHist.so: undefined reference to symbol 'gRandom'
/usr/local/lib/root/libMathCore.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
The problem is nm -C run on libMathCore states 'gRandom' is declared there. Also -lMathCore is present in my command line.
When I run ld to check if it understands the flag:
ld -L/usr/local/lib/root -lMathCore --verbose 2>/dev/null
it does not complain and tries to link properly.
According to https://stackoverflow.com/a/24675715/3602168 order of libraries is correct in my linking (libHist uses libMathCOre and therefore is stated first).
Compilation runs under g++ 4.8.2 on ubuntu 14.04, 64 bit
Converting comment to answer:
Have you tried moving $(objects2) before ${ROOTLIBS}? I think the issue may be that you have libraries specified before the object files that use them.
I am working on embedded software for a ARM microcontroller (SAM7) and using Yagarto toolchain.
My code currently links libc.a. However I'd like to use a custom implementation of the builtin function memcpy that my code already has.
I have tried using -fno-builtin and/or -fno-builtin-memcpy as specified in the GCC Manual but the linker still complains will the following warning:
contiki-crazy-horse.a(flashd_efc.o): In function `memcpy':
C:\Users\Melvin\GitRepo\projects\Amatis_Project\SAM7_Contiki\examples\er-rest-example/../../cpu/arm//at91sam7s-x/./flashd_efc.c:669: multiple definition of `memcpy'
c:/toolchains/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libc.a(lib_a-memcpy.o):C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\string/../../../../../newlib-1.19.0/newlib/libc/string/memcpy.c:78: first defined here
collect2: ld returned 1 exit status
make: *** [rest-server-example-nosyms.crazy-horse] Error 1
../../cpu/arm/at91sam7s-x/Makefile.at91sam7s-x:181: recipe for target `rest-server-example-nosyms.crazy-horse' failed
What is the correct way to use custom implementations of certain gcc built-in functions?
Edit 1: Adding the linking command I am using. In the code below Porject.a is an archive file created with all the project's object files.
CC = arm-none-eabi-gcc
CFLAGSNO = -I. -I$(CONTIKI)/core -I$(CONTIKI_CPU) -I$(CONTIKI_CPU)/loader \
-I$(CONTIKI_CPU)/dbg-io \
-I$(CONTIKI)/platform/$(TARGET) \
${addprefix -I,$(APPDIRS)} \
-DWITH_UIP -DWITH_ASCII -DMCK=$(MCK) \
-Wall $(ARCH_FLAGS) -g -D SUBTARGET=$(SUBTARGET)
CFLAGS += $(CFLAGSNO) -O -DRUN_AS_SYSTEM -DROM_RUN -ffunction-sections
LDFLAGS += -L $(CONTIKI_CPU) --verbose -T $(LINKERSCRIPT) -nostartfiles -Wl,-Map,$(TARGET).map
$(CC) $(LDFLAGS) $(CFLAGS) -nostartfiles -o project.elf -lc Project.a
If it is finding memcpy() in libc.a, then it is not conflicting with any "built-in", but rather with the newlib implementation. You may need also to specify -nostdlibs option and explicitly link libc.a and libm.a as necessary.
Object (.o) files are linked before library archives (.a) files are searched, so if a symbol is resolved by an object file, it will not be searched for in the archives. If you place your overrides in an static-link library, then you simply list it ahead of the standard library (or any other libraries that use the standard library) on the linker command line.
[Added] The following was originally a "comment" but should probably be in the answer; it is in response to "Edit 1" in the question, and the comment below about link order:
Change -nostartfiles -o project.elf -lc Project.a to -nostdlib -o project.elf -start-group Project.a -lc -end-group. The switch -nostdlib disables default linking of both start-up files (i.e. -nostartfiles) and standard libraries. The library grouping causes the libraries in the group to be searched iteratively until no further symbols can be resolved, allowing out-of-order and circular dependencies like yours to be resolved. An alternative form for the grouping switches is -( Project.a -lc -).
I am trying to compile a C++ project (openFrameworks + CodeBlocks), using an external C library. I get "undefined reference" error, although I succesfully compile and use the library elsewhere.
The code consists of sources main.cpp, testApp.cpp and header files, including one for my library "myprocessing". When I make , the code is compiled and dies at linking with error
obj/i686Release/./src/testApp.o: In function `testApp::update()':
testApp.cpp:(.text+0x261): undefined reference to `gauss_5(datarect_t)'
collect2: ld returned 1 exit status
make: *** [bin/faceGrabber] Error 1
where gauss_5 is my library function, and it is called in testApp.cpp (header with declarations is included there).
Below I paste the make commands used to compile the code, generated by CodeBlocks (I strip it for clarity)
# compiling object for: ./src/testApp.cpp
g++ -c -g [some -I...] -DOF_USING_GTK -DOF_USING_MPG123 -Wall
-fexceptions -I. -Ilib/ -MMD -MP -MFobj/i686Debug/./src/testApp.d
-MTobj/i686Debug/./src/testApp.d -oobj/i686Debug/./src/testApp.o
-c ./src/testApp.cpp
# compiling object for: ./src/main.cpp
g++ -c -g -pthread [some -I...] -DOF_USING_GTK -DOF_USING_MPG123
-Wall -fexceptions -I. -Ilib/ -MMD -MP -MFobj/i686Debug/./src/main.d
-MTobj/i686Debug/./src/main.d -oobj/i686Debug/./src/main.o
-c ./src/main.cpp
# linking bin/faceGrabber_debug . ./src ./lib
g++ -o bin/faceGrabber_debug obj/i686Debug/./src/testApp.o
obj/i686Debug/./src/main.o -Wl,-rpath=./libs -Llib/ -lz
-lmyprocessing [some libs...]
Note that my library is referenced (-lmyprocessing) in the last, linking step. So, all the headers and libraries are found by the compiler, but somehow they are not compiled-in.
I tried both .a static and .so dynamic files for myprocessing, unsuccessfully. As I mentioned, I use the same library in other project (outside openFrameworks and CodeBlocks) and it works.
You say that the library is written in C. However, the fact that the linker is able to print out the type of the argument to gauss_5() suggests that it's working with the mangled, C++ name of the function.
I suspect you might be missing extern "C" { ... } guards around your C header.
Good morning,
I'm trying to build luabind using bjam binaries and g++ (mingw).
Lua root is in 'D:\Dev\lua-5.1.4\',
*.a file here: 'D:\Dev\lua-5.1.4\lib\libluadll.dll.a'
*.dll file here: 'D:\Dev\lua-5.1.4\lib\luadll.dll'
All these *.o files were compiled well, but when it started linking it, something went wrong:
gcc.link.dll bin\gcc-mingw-4.4.1\debug\libluabindd.dll.a
d:/programms/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/b
in/ld.exe: cannot find -llibluadll.dll.a
collect2: ld returned 1 exit status
"g++" -L"D:\Dev\lua-5.1.4\lib" "-Wl,--out-implib,bin\gcc-mingw-4.4.1\debug\
libluabindd.dll.a" -o "bin\gcc-mingw-4.4.1\debug\libluabindd.dll" -shared -Wl,-
-start-group "bin\gcc-mingw-4.4.1\debug\src\class.o" "bin\gcc-mingw-4.4.1\debug\
src\class_info.o" "bin\gcc-mingw-4.4.1\debug\src\class_registry.o" "bin\gcc-ming
w-4.4.1\debug\src\class_rep.o" "bin\gcc-mingw-4.4.1\debug\src\create_class.o" "b
in\gcc-mingw-4.4.1\debug\src\error.o" "bin\gcc-mingw-4.4.1\debug\src\exception_h
andler.o" "bin\gcc-mingw-4.4.1\debug\src\function.o" "bin\gcc-mingw-4.4.1\debug\
src\inheritance.o" "bin\gcc-mingw-4.4.1\debug\src\link_compatibility.o" "bin\gcc
-mingw-4.4.1\debug\src\object_rep.o" "bin\gcc-mingw-4.4.1\debug\src\open.o" "bin
\gcc-mingw-4.4.1\debug\src\pcall.o" "bin\gcc-mingw-4.4.1\debug\src\scope.o" "bin
\gcc-mingw-4.4.1\debug\src\stack_content_by_name.o" "bin\gcc-mingw-4.4.1\debug\s
rc\weak_ref.o" "bin\gcc-mingw-4.4.1\debug\src\wrapper_base.o" -Wl,-Bstatic -Wl
,-Bdynamic -llibluadll.dll.a -Wl,--end-group -g
...failed gcc.link.dll bin\gcc-mingw-4.4.1\debug\libluabindd.dll.a bin\gcc-mingw
-4.4.1\debug\libluabindd.dll...
...failed updating 2 targets...
So, I renamed libluadll.dll.a into lua5.1, lua5.1.a, but it's still prints the same error message.
Thanks, beforehand.
Firstly, -l{name} directive searches for lib{name}.dll and lib{name}.a. So, yours should be -llua, not -llibluadll.dll.a.
Secondly, are Lua libraries compiled with g++ too? Object files and libraries compiled by different compilers are incompatible in general.
This part of the g++ command line is wrong:
-llibluadll.dll.a
If you want to link against libfoo.dll, the right linker flag is -lfoo (no lib, no dll).
If you have a static archive and you want a static link, just name the archive, with no -l prefix (and specify a path if it's not found).