I need to get familiar with Eclipse-CDT (indigo) for the first time so created the the project "First" with first.c and first.h, and then created a static library project Staticlib with mylib.c. I
cannot get the projects to link using Build All (after cleaning all). The output is:
Building target: First
Invoking: MacOS X C Linker
gcc -static -L"/Users/nate/Eclipse Workspaces/cdtWorkspace/Staticlib/Debug" -L"/Users/nate/Eclipse Workspaces/cdtWorkspace/Staticlib/Release" -o "First" ./src/first.o
ld: library not found for -lcrt0.o
Any idea of how to fix this?
The problem was that I forgot the in's and out's of make. When I figured out what eclipse-cdt wanted in the make file and the correct syntax it all worked.
Related
I am trying to run libFuzz on a C project that usually compiles to an executable. The examples I found for libFuzz almost exclusively link with a library, i.e. a mylibary.a file. So I compiled the project with the normal Makefile, and combined the generated object files into a library with ar rcs a.o b.o etc.. Now I want to link this library file with the fuzzing target using clang++, but the linker is not able to find the implementation of the function I want to fuzz.
The command I use for linking inside the src directory of the project is
clang++ -Wall -fsanitize=fuzzer -Wno-cpp -Wpedantic -std=c++11 -O2 -g -I/usr/include/libxml2 -g -O2 -rdynamic -o fuzzing libmylib.a fuzztarget.cc -lcurl -lxml2 -I.
The error I get is "Undefined reference to function_xy()"
So the compiler finds the import of the function but not the implementation of it.
I am new to clang and generally building complex C projects so all help is greatly appreciated. Thank you!
I tried compiling the project with the included Makefile, then combining the generated object files into a .a library and finally linking the library with my fuzzing target.
The error you got is about linking, not the LibFuzzer. If you can compile and link your file without implementing function in LLVMFuzzerTestOneInput, then the fuzz-target should work: Include header in your code, call the function, compile file and link with libraries. Please check the order of include path, file, linked libraries. Be careful with the option of optimization (-O2), sometimes the fuzzer does not give crash with this option.
It is my first time trying to link external libraries to a C file. I read that I can use a Makefile and this is what I have:
all: src/main.c
gcc src/main.c -o main.exe -IC:\src\C\GameTry\dependencies\include -LC:\src\C\GameTry\dependencies\lib -lglfw3 -lgdi32 -lglew32s
clean:
rm *.o
The reason I included -lgdi32 is beacuse the official glfw documentation states that:
When using MinGW to link an application with the static version of GLFW, you must also explicitly link with gdi32
This makefile works but OpenGL throws the warning corrupt .drectve at end of def file repeatedly many times and it throws undefined reference to '__security_cookie' error may times aswell which causes the program to not compile.
I have looked all arround the internet and haven't been able to find an answer. I believe these errors have something to do with the default MSVN libraries but I'm not sure
If you have libglfw3.a that matches your compiler and platform (make sure to not mix win32 and win64), then a .def file should not be needed.
Somehow the linker is picking up a .def file anyway.
If there is a .def for glfw3, can you try to remove or rename it and try again?
I'm using OSX command line gcc and attempting to build a dynamic library. when I do the build I get the following warning. How is it it is not finding this library given /usr/lib is well known? And /usr/lib does indeed exist on my machine
this is what I am using:
gcc -arch i386 cata/*.c -dynamiclib -o build/cata.dylib -LC_ID_DYLIB=/usr/lib
Thanks
the way i solved it was to make it so the string that got stuck in the library (on where to find the library at runtime) was relative to nowhere -- if that makes sense. so it would be forced to use the LD_LOAD_PATH.
I was using the other flags because someone suggested I use them.
so the gcc i ended up using is this:
# my tree is like this
# cata/*.c
# build/*.dylib
#
cd build
gcc -arch i386 ../cata/*.c -dynamiclib -o cata.dylib
Doing this compiles/makes a library in the same directory where it thinks it is 'used' (basically having no path). I am now free to put it somewhere else. When it is later linked at compile time by a different program and then examined using
otool -L
it appears with no path in front of the library name. This is apparently preferable as now when the system goes to try to find it it resorts to looking at the standard libraries and eventually finds it (because I install it to one of the standard locations).
In the original way, otool -L was showing it having a required path of
'build/cata.dylib'
This made it un-findable and which is why i was trying to use the apple documentation to get around the problem.
This doesn't really solve why LC_ID_DYLIB doesn't work. I looked into the Loader.h file (line 643) and it has room for an identifier(0xd), a path, and a structure, so I don't really understand why my path wasn't getting picked up. but its two different topics. Loader.h is runtime and the other is gcc AFAIK. I'm still learning apple.
I wrote a little Lua module in C, that generates a UUID leveraging libuuid. You can find the source at https://github.com/Mashape/lua-uuid
The library properly works on OSX and CentOS. I am currently having a problem on Ubuntu where although the library successfully compiles, executing it throws the following exception:
lua: error loading module 'lua_uuid' from file './lua_uuid.so':
./lua_uuid.so: undefined symbol: uuid_generate
stack traceback:
[C]: ?
[C]: in function 'require'
/test.lua:1: in main chunk
[C]: ?
It seems like the library can't find the libuuid dependency, although in the Makefile includes the -luuid flag (https://github.com/Mashape/lua-uuid/blob/master/Makefile#L4).
To replicate the problem, these are the dependencies required:
apt-get install lua5.1 luarocks unzip git make gcc uuid-dev
wget https://github.com/Mashape/lua-uuid/archive/0.1-7.zip -O /tmp/lua_uuid.zip
unzip /tmp/lua_uuid.zip -d /tmp
cd /tmp/lua-uuid-0.1-7/ && luarocks make lua_uuid-0.1-7.rockspec
Then you can run the following Lua script:
local uuid = require "lua_uuid"
local uuid_str = uuid()
print("New UUID: "..uuid_str)
I am not proficient with C and Makefiles, is there something obvious that I am missing?
Compiling this module using LuaRocks on Ubuntu results in the following compiler command lines:
gcc -c -O2 -fPIC -I/usr/include/lua5.1 lua_uuid.c -o lua_uuid.o
gcc -shared -luuid -o lua_uuid.so -L/usr/lib lua_uuid.o
The library libuuid is available as a static library, and it is listed before the object file that references its symbols. Since the GNU linker inspects libraries/object files from left to right, all symbolds in libuuid are deemed unnecessary and left out of the final build because they haven't been referenced yet. Moving -luuid to the end of the linker command line (to the right of lua_uuid.o) fixes the issue.
There are already some Stackoverflow answers that explain the particulars:
Why does the order in which libraries are linked sometimes cause errors in GCC?
Why does the order of '-l' option in gcc matter?
I started experimenting with C/C++ the other day because I needed it for reading level-4 MAT-files without needing to purchase the Matlab editor or compiler. So I found just the library that I needed but I'm not familiar with C or C++ at all so I'm a beginner with those two languages. Anyhow I need to include the 'matio' library. I've tried many things but I've had no luck.
I right clicked on the C/C++ project > properties > C/C++ General > Paths & Symbols > GNU C and added the path to the matio library.
I also went to C/C++ Build > Settings > Tool settings > GCC C Compiler > Includes and added the path there aswell.
Since I'm not any good with makefiles yet I did not specify my own makefile, instead I chose a executable project.
When I try to build my project it complains about a function called 'Mat_Open' in the matio library. When I hover over it, it says "undefined reference to 'Mat_Open'" the header 'matio.h' seems to work fine but it can't refer to 'Mat_Open' for some reason.
How do I solve this?
EDIT:
Here is the whole build console output.
10:42:52 **** Incremental Build of configuration Debug for project Project ****
Info: Internal Builder is used for build
gcc -IC:/matio-1.5.2/src -O0 -g3 -Wall -c -fmessage-length=0 -o CComponent.o "..\\CComponent.c"
gcc -Xlinker -lm -o Project.exe CComponent.o -lC:/matio-1.5.2/src
c:/mingw(x64)/bin/../lib/gcc/x86_64-w64-mingw32/4.8.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lC:/matio-1.5.2/src
collect2.exe: error: ld returned 1 exit status
10:42:53 Build Finished (took 330ms)
This is not necessarily an answer but may be useful for a comparison.
First of all, where did you install it? If your using Linux or Mac OSX you will want to install in the system directories (not sure about Windows). I use OSX so in my makefile (by the way I use Qt):
LIBS += -L/usr/local/lib/ -lmatio
INCLUDEPATH += /usr/local/include
Then of course, in the *.h files of my source I use:
#include "matio.h"
But I assume you have already tried that?