I am receiving the following error after this linker command from qmake generated Makefile.
clang++ -headerpad_max_install_names -mmacosx-version-min=10.6 -o bin/Clock tmp/clock.o tmp/config.o tmp/main.o tmp/qrc_resources.o tmp/moc_clock.o -L/Users/foo/Qt5.0.0/5.0.0/clang_64/lib -lQt5Widgets -lQt5Gui -lQt5Core -framework OpenGL -framework AGL
error:
ld: library not found for -lQt5Widgets
I can confirm that the library is not there with that spelling.
However there is a QtWidgets.la as well there is a QtWidgets.framework dir that has a QtWidgets.
In the lib directory none of the files have a Qt5 prefix is there some way of changing Qt so it does not look for it etc.
I understand that I could rename things and move them around but this is a big job remaining all libs to have a Qt5 prefix.
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 hitting a linker error (compile time, not run time):
ld: library not found for -l:/usr/lib/libobjc.A.dylib
That's just the latest version of the error. I'm trying to link against /usr/lib/libobjc.A.dylib, and I want to hard-code the path; the library is guaranteed to exist at this path on the platform I'm on. And it does:
bhaller#lanois % ls -l /usr/lib/libobjc.A.dylib
-rwxr-xr-x 1 root wheel 859536 Jan 23 08:59 /usr/lib/libobjc.A.dylib
I have tried:
-L/usr/lib/ -llibobjc.A.dylib
-L/usr/lib/ -llibobjc.A
-l/usr/lib/libobjc.A.dylib
-l:/usr/lib/libobjc.A.dylib
In every case I get the same error, that ld couldn't find the library. But it's right there, and I'm giving the complete path to it! What am I missing??
Here's the full invocation, with a bunch of other cruft:
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -headerpad_max_install_names -macosx_version_min 10.10.0 -o QtSLiM.app/Contents/MacOS/QtSLiM -L/Users/bhaller/Desktop/QtSLiM QMAKE/QtSLiM/../core/ -L/Users/bhaller/Desktop/QtSLiM QMAKE/QtSLiM/../eidos/ -L/Users/bhaller/Desktop/QtSLiM QMAKE/QtSLiM/../treerec/tskit/ -L/Users/bhaller/Desktop/QtSLiM QMAKE/QtSLiM/../gsl/ -L/Users/bhaller/Desktop/QtSLiM QMAKE/QtSLiM/../eidos_zlib/ -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -rpath #executable_path/Frameworks -rpath /Users/bhaller/Qt5.9.8/5.9.8/clang_64/lib main.o QtSLiMWindow.o QtSLiMAppDelegate.o QtSLiMWindow_glue.o QtSLiMChromosomeWidget.o QtSLiMExtras.o QtSLiMPopulationTable.o QtSLiMIndividualsWidget.o QtSLiMEidosPrettyprinter.o QtSLiMAbout.o QtSLiMPreferences.o QtSLiMSyntaxHighlighting.o QtSLiMFindRecipe.o QtSLiMHelpWindow.o QtSLiMScriptTextEdit.o QtSLiMEidosConsole.o QtSLiMEidosConsole_glue.o QtSLiMConsoleTextEdit.o QtSLiM_SLiMgui.o QtSLiMTablesDrawer.o QtSLiMFindPanel.o QtSLiMGraphView.o QtSLiMGraphView_FixationTimeHistogram.o QtSLiMGraphView_FrequencySpectra.o QtSLiMGraphView_LossTimeHistogram.o QtSLiMGraphView_PopulationVisualization.o QtSLiMGraphView_FitnessOverTime.o QtSLiMGraphView_FrequencyTrajectory.o QtSLiMHaplotypeManager.o QtSLiMHaplotypeOptions.o QtSLiMHaplotypeProgress.o QtSLiMVariableBrowser.o qrc_buttons.o qrc_icons.o qrc_recipes.o qrc_help.o moc_QtSLiMWindow.o moc_QtSLiMAppDelegate.o moc_QtSLiMChromosomeWidget.o moc_QtSLiMExtras.o moc_QtSLiMPopulationTable.o moc_QtSLiMIndividualsWidget.o moc_QtSLiMAbout.o moc_QtSLiMPreferences.o moc_QtSLiMSyntaxHighlighting.o moc_QtSLiMFindRecipe.o moc_QtSLiMHelpWindow.o moc_QtSLiMScriptTextEdit.o moc_QtSLiMEidosConsole.o moc_QtSLiMConsoleTextEdit.o moc_QtSLiMTablesDrawer.o moc_QtSLiMFindPanel.o moc_QtSLiMGraphView.o moc_QtSLiMGraphView_FixationTimeHistogram.o moc_QtSLiMGraphView_FrequencySpectra.o moc_QtSLiMGraphView_LossTimeHistogram.o moc_QtSLiMGraphView_PopulationVisualization.o moc_QtSLiMGraphView_FitnessOverTime.o moc_QtSLiMGraphView_FrequencyTrajectory.o moc_QtSLiMHaplotypeManager.o moc_QtSLiMHaplotypeOptions.o moc_QtSLiMHaplotypeProgress.o moc_QtSLiMVariableBrowser.o -lcore -leidos -ltskit -lgsl -leidos_zlib -l:/usr/lib/libobjc.A.dylib -framework QtOpenGL -framework QtWidgets -framework QtGui -framework QtCore -framework DiskArbitration -framework IOKit -framework OpenGL -framework AGL -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0/lib/darwin/libclang_rt.osx.a -F/Users/bhaller/Qt5.9.8/5.9.8/clang_64/lib
ld: library not found for -l:/usr/lib/libobjc.A.dylib
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [QtSLiM.app/Contents/MacOS/QtSLiM] Error 1
make: *** [sub-QtSLiM-make_first] Error 2
I feel like I must just be an idiot, but I can't see it. Help?
Your linkage command shows that your linker is the OS X linker. Refer to it's manual
with respect to the -l option:
-lx
This option tells the linker to search for libx.dylib or libx.a in the library search path.
If string x is of the form y.o, then that file is searched for in the same places, but
without prepending lib or appending .a or .dylib to the filename.
This will show you why all of:
-L/usr/lib/ -llibobjc.A.dylib
-L/usr/lib/ -llibobjc.A
-l/usr/lib/libobjc.A.dylib
-l:/usr/lib/libobjc.A.dylib
are wrong. In each of your attempts, where name is whatever you have typed after -l,
the linker will be directed to search for libname.dylib or libname.a. Of course
none of those files - e.g. liblibobjc.A.dylib.dylib,liblibobjc.A.dylib.a - exists
in /usr/lib/ or any of the other specified or default search directories, and
in the third and fourth attempts, libname.(dylib|a) resolves to strings that that
cannot even possibly be unqualified filenames.
Your final variation evidently wants to used -l:name in an attempt to make the linker
search precisely for name ( = /usr/lib/libobjc.A.dylib). However,
-l:name is an option for the GNU Binutils linker, (the default linker in Linux)
and as per the documentation, is not an option for the OS X linker. (Furthermore, that option of the Binutils linker
directs the linker to search in each directory for a file with the exact unqualified name name, which /usr/lib/libobjc.A.dylib
could not be).
To get the linker to locate libobjc.A.dylib in /usr/lib/ you require the option:
-lobjc.A
Consider for example the other -l options in your your linkage command:
-lcore -leidos -ltskit -lgsl -leidos_zlib
Before you try that however, I suggest that you check in /usr/lib for the existence
of a symbolic link:
libobjc -> libobjc.A
This would indicate that libobjc.A is the version of libobjc that your toolchain
is configured to select, and that the linkage option you require is simply:
-lobjc
The search option -L/usr/lib/ is in any case redundant, since /usr/lib/ is a default
linker search directory.
I have an application that links again SDL and cairo that I would like to cross-compile on ubuntu for win64. I used this excellent blog post to get SDL cross compiling and I've used another blog post to cross-compile zlib, libpng and libpixman.
However, I now get a linker error trying to compile my minimal test program:
$ make cairotest.exe
x86_64-w64-mingw32-gcc -o cairotest.o -c cairotest.c -I/usr/x86_64-w64-mingw32/include/SDL2 -Dmain=SDL_main -I/home/jshaw/x86_64-w64/include/cairo -I/home/jshaw/x86_64-w64/include/pixman-1 -I/home/jshaw/x86_64-w64/include/libpng16
x86_64-w64-mingw32-gcc -o cairotest.exe cairotest.o -L/usr/x86_64-w64-mingw32/lib -lmingw32 -lSDL2main -lSDL2 -mwindows -L/home/jshaw/x86_64-w64/lib -lcairo
collect2: error: ld returned 1 exit status
Makefile:13: recipe for target 'cairotest.exe' failed
I should mention that this test program works correctly if I just use SDL2 without any cairo code, so I suspect something is wrong with the cairo library that I cross-compiled. How should I go about diagnosing the problem?
Looking at your Makefile it appears as though your are using normal pkg-config for discovering your Cairo libs. CAIRO_LDFLAGS := $(shell $(PKG_CONFIG) cairo --libs). This will find the path to your host libraries, which is presumably a different architecture than the target. An architecture mismatch like that can really cause strange problems with the linker. I believe you should be looking for something like usr/x86_64-w64-mingw32/bin/pkg-config.
Other things to try;
Run the compilation commands manually, as the makefile could be suppressing output.
Also, when running the command, add the -v flag to the command line to get the verbose output to better figure out where the issue is.
I am trying to link GLFW to my C program.
The docs seem to suggest #include<GLFW/glfw3.h> however I have installed 2.7.2 (from my distro's repository) and don't have that header file:
find / -name *glfw* 2> /dev/null
/usr/lib/libglfw.so.2.6
/usr/lib/libglfw.a
/usr/lib/libglfw.so
/usr/lib/pkgconfig/libglfw.pc
/usr/lib/libglfw.so.2
/usr/include/GL/glfw.h
/usr/share/doc/libglfw-dev
/usr/share/doc/libglfw2
/var/cache/apt/archives/libglfw2_2.7.2-1_i386.deb
/var/cache/apt/archives/libglfw-dev_2.7.2-1_i386.deb
/var/lib/dpkg/info/libglfw2.list
/var/lib/dpkg/info/libglfw2.postinst
/var/lib/dpkg/info/libglfw-dev.md5sums
/var/lib/dpkg/info/libglfw2.postrm
/var/lib/dpkg/info/libglfw2.md5sums
/var/lib/dpkg/info/libglfw2.shlibs
/var/lib/dpkg/info/libglfw-dev.list
I tried #include<GL/glfw.h> but I still get undefined reference to 'glfwLoadTexture2D'
How do I link to GLFW and use glfwLoadTexture2D()?
An #include does nothing for the linker; it just brings in declarations, not the actual functions.
The documentation indicates that GLFW uses pkg-config (not surprising; #elmindreda knows her stuff), so your compilation line should be something like:
$ cc `pkg-config --cflags glfw3` -o foo foo.c `pkg-config --static --libs glfw3`
Also note that since the library uses pkg-config, you're not supposed to "care" about details such as where the header and library files are located on your particular installation. Just ask using the --cflags and --libs modes, and you will get the proper locations returned, as the example above indicates.
You are mixing up compilation and linking. If you were missing headers, you would probably have errors a lot sooner than the linking stage.
"Undefined reference" results from symbols not being found by the linker. The most likely cause is you not telling gcc that it should link to the GLFW libraries:
gcc myfile.c -lglfw
When I am on Linux, I compile opengl/glfw projects like this:
gcc main.c -lGL -lglfw
When I am on windows, I compile them by writing:
gcc main.c libglfw3.a -lopengl32 -lgdi32
and I put libglfw3.a file in the same directory where main.c is. I have read people say that they couldn't link properly before writing
-lopengl32 -lgdi32 -luser32 -lkernel32 -lws2_32.
Another thing which may be worth mentioning is that I couldn't link glfw libraries when I downloaded 32bit glfw binaries. When I downloaded 64bit glfw binaries everything worked fine. I have a 64 bit machine and a x86_64-w64-mingw32. I have read comments from people with the opposite experience, where they weren't able to link glfw libraries when they downloaded 64bit binaries, but they were able to link them after downloading 32bit binaries. My advice would be to try both.