This probably very easy when you know how, but I don't :)
I'm trying to build some code that takes uses opengl/glut. I'm using the cygwin version of cmake opengl etc. The only reference I see to opengl/gult is in the CMakeLists.txt:
find_package(OpenGL REQUIRED)
find_package(GLU REQUIRED)
find_package(GLUT REQUIRED)
Everything works fine up till the linking stage, which ends with:
CMakeFiles/glview.dir/glview.c.o: In function `DrawGLScene': /cygdrive/C/code/libfreenect/examples/glview.c:88: undefined reference to `__imp__glutSwapBuffers#0'
CMakeFiles/glview.dir/glview.c.o: In function `keyPressed': /cygdrive/C/code/libfreenect/examples/glview.c:96: undefined reference to `__imp
etc.
After a git of googling I figured out this because cmake is feading the linker a -lglut flag, when it should be feading it a -lgut32 flag. By manually executing the linking command, I can get the program to build:
/usr/bin/gcc.exe -Wall -O3 -g -Wl,--enable-auto-import CMakeFiles/glview.dir/glview.c.o -o glview.exe -Wl,--out-implib,libglview.dll.a -Wl,--major-image-version,0,--minor-image-version,0 -L/cygdrive/C/code/libfreenect/lib ../lib/libfreenect.a -lGL -lGLU -lglut32 -lm -lpthread -lusb-1.0
But I can't figure out how to get cmake to generate this command for me so no manual steps are needed. Any ideas what I should be doing?
Cheers,
Rob
this is how to add libraries to link to:
target_link_libraries( ${TargetName} gut32 )
find_package only assures the package is found, no more.
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.
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.
Do I understand it correctly on how to use cmake for linking
cmake_minimum_required(VERSION 3.2)
project(Sdltest)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Werror -lmingw32 -lSDL2main -lSDL2")
set(SOURCE_FILES main.c)
add_executable(Sdltest ${SOURCE_FILES})
I'm trying to link the sdl2 to my project but I get a lot of errors.
like /src/mingw-org-wsl/4.0-dev/src/libcrt/crt/main.c:91: undefined reference to `WinMain#16'
When I use gcc on cmd, it compiles perfectly
gcc main.c -o test -Wall -Werror -lmingw32 -lSDL2main -lSDL2
By the way I use clion 1.0.5
The problem is the flags, you mix compiler and linker flags. First of all this is problematic because the compiler flags aren't used when linking, and secondly because the GNU linker needs the libraries to come after the main source (or object) file on the command line, just like when you build manually.
You set the libraries by using the target_link_libraries command in your CMakeLists.txt file:
target_link_libraries(Sdltest mingw32 SDL2main SDL2)
Also, you're not building a C++ project, you're building a C project, so the flags variable should be CMAKE_C_FLAGS.
Finally, if you're wondering about the command and arguments that CMake uses when building, try making with VERBOSE set to non-zero, e.g.
make VERBOSE=1
I'm sure it's possible to add that argument to CLion.
PS.
If you want to enable more warnings, there are even more flags you could add, like -Wextra and -pedantic. Yes it might sometime give false positives, especially when including header files from external libraries, but I think it's better to have to many warnings when developing than to few.
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 am trying to create an C application on Debian GNU/Linux which uses the PortAudio interface. To do this I must compile my program with gcc -lrt -lasound -ljack -lpthread -o YOUR_BINARY main.c libportaudio.a from this docs.
For this I installed libasound2-dev, and I checked where the files are using apt-file search libasound.so, this is the output:
lib32asound2: /usr/lib32/libasound.so.2
lib32asound2: /usr/lib32/libasound.so.2.0.0
lib32asound2-dev: /usr/lib32/libasound.so
libasound2: /usr/lib/x86_64-linux-gnu/libasound.so.2
libasound2: /usr/lib/x86_64-linux-gnu/libasound.so.2.0.0
libasound2-dev: /usr/lib/x86_64-linux-gnu/libasound.so
So the libasound should be installed correctly, but when I compile my program with this makefile:
DMXTest: main.c libdmx.a
gcc -static -Wall main.c -L. -ldmx -lusb -lrt -lasound -ljack -lfftw3 -g -o main libportaudio.a
I get the following error: /usr/bin/ld: cannot find -lasound.
How can I link this library correctly?
You don't have libasound.a for -static, you will need that, or you can almost certainly just remove -static from the Makefile (likely in LDFLAGS or CFLAGS).
There's is a related Debian bug 522544, and a related Ubuntu bug #993959.
You may be able to build your own libasound from source, though as it also uses other libraries (notably libpthread.so, librt.so and libdl.so) I suspect it may remove some functionality when you build it statically, though it's supported with ./configure --enable-static at build time
(or try --enable-shared=no --enable-static=yes).
FWIW, the use of static binaries is "discouraged" by the glibc maintainers, though I don't agree...
To compile my code i used the following command
gcc -o rec_mic rec_mic.c -lasound
and it works perfectly, without create my own static library.