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.
Related
Problem with linking portaudio into an c program on Linux.
System: Linux Ubuntu 20.4 i5 16 GB
ALSA and pulseaudio were preinstralled.
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
gcc -Wall wm_1.c -lm libportaudio.a -o wm_1
The linker gives me more than 100 error messages all of type "undefined reference"
Here 2 examples out of >100
/home/max/Desktop/dev/portaudio/src/hostapi/alsa/pa_linux_alsa.c:504: undefined reference to snd_pcm_status_get_delay' /home/max/Desktop/dev/portaudio/src/hostapi/oss/pa_unix_oss.c:1778: undefined reference to __pthread_unregister_cancel'
So its obvious that the named parameter/function can not be found.
The error messages all point to source files in the source directory (the directory of the portaudio
package I downloaded to creatie the libs which were all created without error.
The libs are in /usr/local/..
libportaudio.a libportaudio.la libportaudio.so libportaudio.so.2 libportaudio.so.2.0.0 pkgconfig python3.8
and I copied libportaudio.a into the project directory. The lib has a a size of 1.1 MB .
if I use the dynamic libportaudio.so I get the error messages at run time.
I suspect that something went totally wrong with creating the libraries but I have no idea how to solve that
Other option:
Linking parameter or files missing ?
Header file ?
The same program compiles, links and runs without any problem on a iMac OS 10.13.6
where I used the dynamic lib .dylib.
gcc -v wm_1.c libportaudio.dylib -o wm_1
From the documentation:
Note that you will usually need to link with the approriate libraries that you used, such as ALSA and JACK, as well as with librt and libpthread. For example:
gcc main.c libportaudio.a -lrt -lm -lasound -ljack -pthread -o YOUR_BINARY
A little googling goes a long way...
This works:
gcc -Wall wm_1.c -lm libportaudio.a -lasound -pthread -o test.
gcc main.c libportaudio.a -lrt -lm -lasound -ljack -pthread -o YOUR_BINARY
I used that page and the command line at the begin using all 3 parameter but got errors, probably of misspelling, so I gave up on that (also because on the Mac OS it was not necessary). It now links without errors using -lasound and -pthread only (-pthread alone gives still errors and the use/not use of -ljack makes no difference).
I get some errors when I run the program but probably because of missing or wrong ALSA parameter settings. I found -pthread but I could not find -ljack and -lasound.
So the question: what are this 2 parameter doing?
It must be link parameter, but where is the documentation, I searched ld and gcc and did not find anything, while -pthread is documented.
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've build a shared library on my desktop that uses statically linked gstreamer and gstreamer plugins (base, good, rtsp-server).
Now I'm trying to compile the library using yocto but its giving me a linker error:
version node not found for symbol _IO_do_write##GLIBC_2.17
failed to set dynamic section sizes: Bad value
The solutions I found on stack overflow did not seem to help me.
use compiler with --disable-symvers
link libc libs in different orders (-ldl -lm -lc -lpthread -ltinfo -lrt)
link libc libs statically/shared
What I find particularly odd is that the linker is looking for GLIBC_2.17 while yocto uses 2.27 and my system is using 2.24. I don't know if this matters or if it is normal (the function did not change since 2.17?).
NM -C shows the symbol in libc.a:
nm -C recipe-sysroot/usr/lib/libc.a | grep IO_do_write
U _IO_do_write
U _IO_do_write
0000000000001ba8 W _IO_do_write
So I would thinks that lib is linked incorrectly?
The linker command is a long one because of all the shared libs so I shortend it a bit (removed boost and custom libs):
aarch64-poky-linux-g++ -fPIC --sysroot=recipe-sysroot -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=recipe-root/git-r0 -fdebug-prefix-map=recipe-sysroot= -fdebug-prefix-map=recipe-sysroot-native= -fvisibility-inlines-hidden --sysroot=recipe-sysroot -Wl,-allow-multiple-definition -Wall -Wextra -Wpedantic -Wsuggest-override -Wswitch-default -Wduplicated-cond -Wshadow -Werror -ftemplate-depth=1024 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -lc -Wl,--no-as-needed -Wl,--no-undefined -pthread -ldl -shared -Wl,-soname,rtsp_streamer.so -o rtsp_streamer.so ... custom static libs .and boost static libs ... -lpthread recipe-sysroot/usr/lib/gstreamer-1.0/libgstrtsp.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstrtp.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstrtpmanager.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstcoreelements.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstadder.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstapp.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstaudioconvert.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstaudiorate.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstaudioresample.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstaudiotestsrc.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstgio.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstpango.a recipe-sysroot/usr/lib/gstreamer-1.0/libgsttypefindfunctions.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstvideoconvert.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstvideorate.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstvideoscale.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstvideotestsrc.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstvolume.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstautodetect.a recipe-sysroot/usr/lib/gstreamer-1.0/libgstvideofilter.a recipe-sysroot/usr/lib/libBrokenLocale.a recipe-sysroot/usr/lib/libBrokenLocale_pic.a recipe-sysroot/usr/lib/libanl.a recipe-sysroot/usr/lib/libanl_pic.a recipe-sysroot/usr/lib/libatomic.a recipe-sysroot/usr/lib/libatomic_ops.a recipe-sysroot/usr/lib/libatomic_ops_gpl.a ... more boost static libs ... recipe-sysroot/usr/lib/libc.a recipe-sysroot/usr/lib/libc_nonshared.a recipe-sysroot/usr/lib/libc_pic.a recipe-sysroot/usr/lib/libcidn_pic.a recipe-sysroot/usr/lib/libcrypt.a recipe-sysroot/usr/lib/libcrypt_pic.a recipe-sysroot/usr/lib/libcrypto.a recipe-sysroot/usr/lib/libdl.a recipe-sysroot/usr/lib/libdl_pic.a recipe-sysroot/usr/lib/libg.a recipe-sysroot/usr/lib/libgomp.a recipe-sysroot/usr/lib/libgstallocators-1.0.a recipe-sysroot/usr/lib/libgstaudio-1.0.a recipe-sysroot/usr/lib/libgstbase-1.0.a recipe-sysroot/usr/lib/libgstcheck-1.0.a recipe-sysroot/usr/lib/libgstcontroller-1.0.a recipe-sysroot/usr/lib/libgstfft-1.0.a recipe-sysroot/usr/lib/libgstpbutils-1.0.a recipe-sysroot/usr/lib/libgstreamer-1.0.a recipe-sysroot/usr/lib/libgstriff-1.0.a recipe-sysroot/usr/lib/libgstrtp-1.0.a recipe-sysroot/usr/lib/libgstrtsp-1.0.a recipe-sysroot/usr/lib/libgstrtspserver-1.0.a recipe-sysroot/usr/lib/libgstapp-1.0.a recipe-sysroot/usr/lib/libgstnet-1.0.a recipe-sysroot/usr/lib/libgstsdp-1.0.a recipe-sysroot/usr/lib/libgsttag-1.0.a recipe-sysroot/usr/lib/libgstvideo-1.0.a recipe-sysroot/usr/lib/libhistory.a recipe-sysroot/usr/lib/libitm.a recipe-sysroot/usr/lib/liblicensing.a recipe-sysroot/usr/lib/libm.a recipe-sysroot/usr/lib/libm_pic.a recipe-sysroot/usr/lib/libmcheck.a recipe-sysroot/usr/lib/libncurses++.a recipe-sysroot/usr/lib/libncurses++w.a recipe-sysroot/usr/lib/libnsl.a recipe-sysroot/usr/lib/libnsl_pic.a recipe-sysroot/usr/lib/libnss_compat_pic.a recipe-sysroot/usr/lib/libnss_db_pic.a recipe-sysroot/usr/lib/libnss_dns_pic.a recipe-sysroot/usr/lib/libnss_files_pic.a recipe-sysroot/usr/lib/libnss_hesiod_pic.a recipe-sysroot/usr/lib/libnss_nis_pic.a recipe-sysroot/usr/lib/libnss_nisplus_pic.a recipe-sysroot/usr/lib/libprotobuf-lite.a recipe-sysroot/usr/lib/libprotobuf.a recipe-sysroot/usr/lib/libprotoc.a recipe-sysroot/usr/lib/libpthread.a recipe-sysroot/usr/lib/libpthread_nonshared.a recipe-sysroot/usr/lib/libreadline.a recipe-sysroot/usr/lib/libresolv.a recipe-sysroot/usr/lib/libresolv_pic.a recipe-sysroot/usr/lib/librpcsvc.a recipe-sysroot/usr/lib/librt.a recipe-sysroot/usr/lib/librt_pic.a recipe-sysroot/usr/lib/libsqlite3.a recipe-sysroot/usr/lib/libssl.a recipe-sysroot/usr/lib/libssp.a recipe-sysroot/usr/lib/libssp_nonshared.a recipe-sysroot/usr/lib/libstdc++.a recipe-sysroot/usr/lib/libstdc++fs.a recipe-sysroot/usr/lib/libsupc++.a recipe-sysroot/usr/lib/libthread_db_pic.a recipe-sysroot/usr/lib/libutil.a recipe-sysroot/usr/lib/libutil_pic.a recipe-sysroot/usr/lib/libz.a recipe-sysroot/usr/lib/librt.a recipe-sysroot/usr/lib/libpthread.a recipe-sysroot/usr/lib/libm.a recipe-sysroot/usr/lib/libc.a
Does anybody know what is wrong? If more info is needed please ask. Thanks in advance!
Does anybody know what is wrong?
I suspect that you are not linking against GLIBC-2.27 from Yocto, but against some other GLIBC, though it is hard to see how that could happen.
Your first step should be to find out which libc.so.6 is actually being used. You can do so by adding -Wl,-t flag to your link line. Also add -Wl,-y,_IO_do_write while you are at it.
After you know which libc.so.6 is being used, run readelf -Ws /path/to/libc.so.6 | grep _IO_do_write to see what (if any) versioned symbols are defined in it.
I don't know if this matters or if it is normal (the function did not change since 2.17)?
Yes: that is normal -- the function didn't change its ABI since GLIBC-2.17, so that's the version that is attached to it.
I figured out what went wrong. The shared library is build using a CMAKE project and our own written FindGSTREAMER.cmake. To find gstreamer, among other things, a glob is used to find all the static libs. Because on my desktop I have gstreamer installed in its seperate location this works. With Yocto however this causes every static lib in the recipe-sysroot/usr/lib directory to be linked. Including every libc library (.a, _pic.a and .so). Apparently this causes the linker unable to resolve the symbols.
Correctly filtering the libraries needed by gstreamer fixed the problem.
I'm trying to compile some c code via make with gcc, but I keep getting:
/usr/bin/ld: cannot find -lnetlink
I have -lnetlink included in the gcc make parameters. Using locate netlink is able to find multiple items. I've even told gcc exactly where to find one by using -L/usr/include/linux, but it still gives the error.
The gcc command arguments below:
gcc -g -ggdb -Wall -Wextra -o mt6d mt6d.o address_worker.o tunnel_worker.o mt6d_assoc.o addr_gen.o send_utils.o if_utils.o tun_utils.o icmp_utils.o utils.o -lcrypto -lssl -lnetlink -lpthread -lnetfilter_queue
I've also been having errors with libnetlink.h, but was able to get them resolved, but I've included that here if that might be related and this error appears immediately after the other was fixed. Fixed by using C_INCLUDE_PATH
I've recently upgraded to Ubuntu 13.04 and was using 11.04 before that.
Let me know if you need any more information. Any help would be greatly appreciated!
Thanks,
-Alan
I'm trying to compile some c code via make with gcc, but I keep getting:
Technically, this stage is called linking. That difference may seem subtle at first, but it's a really important one and can help frame the investigation when problems like this arise.
You should not reference /usr/include paths with -L. -L adds to the search path for libraries and generally only header files should show up under /usr/include.
libnl enables pkg-config, so you should use that.
For example (assuming you have libnl-3-dev installed):
gcc -o my_executable $(pkg-config --libs libnl-3.0) my_foo.o my_bar.o
In a Makefile, you could do the following to achieve that effect:
LDLIBS+=$(shell pkg-config --libs libnl-3.0)
CFLAGS+=$(shell pkg-config --cflags libnl-3.0)
I've compiled shared library (pppd plugin) with no errors or warnings but when pppd tries to load this plugin, it fails with "undefined symbol g_string_sized_new" message.
Plugin source can be found here: https://raw.github.com/openshine/ModemManager/master/test/mm-test-pppd-plugin.c
To compile shared library I use the following commands:
gcc -fPIC -c ./mm-test-pppd-plugin.c -o mm-test-pppd-plugin.o `pkg-config --cflags --libs glib-2.0`
gcc -shared -o ./mm-test-pppd-plugin.so ./mm-test-pppd-plugin.o
As I find this g_string_sized_new should be in GLib. So as I understand it should be available systemwide?
OS: Ubuntu 13.04
Any ideas what could be wrong? Thanks in advance!
Compilation is not linkage and linkage is not compilation.
On the first line, you are invoking the compiler so as to compile your C source text into object code. Here supplying the --libs flag to pkg-config is completely superfluous, pure compiler can do nothing with libraries.
However, on the second line, you are trying to link the resulting object files into a proper executable using the linker, but now you are missing the pkg-config --libs from the end of the command line - the linker needs to know the libraries to be linked against in order it to be able to resolve symbols.
Long story short, read this.