I'm cross compiling to an arm embedded system and receiving an error that I have questions about. Here is the error:
[ 19%] Built target cxjpeg-6b
Linking CXX shared library /home/botbear/JAUS++-2.110519- src/libraries/jaus++/2.0/lib/libcxutils.so
/home/botbear/openwrt/trunk/staging_dir/toolchain-arm_v6k_gcc-linaro_uClibc- 0.9.32_eabi/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.5.4/../../../../arm-openwrt-linux- uclibcgnueabi/bin/ld: cannot find -lpng
collect2: ld returned 1 exit status
make[2]: *** [/home/botbear/JAUS++-2.110519-src/libraries/jaus++/2.0/lib/libcxutils.so] Error 1
make[1]: *** [libcxutils/CxUtils/libcxutils/CMakeFiles/cxutils.dir/all] Error 2
make: *** [all] Error 2
As you can see the linker is looking for a static library named 'libpng'. In addition to the libpng lib., the command in the sub-make file using the -l switch to link to the following libraries: -lpng -lz -lX11 -lXtst -lpthread -Wl. All of the libraries (libpng,libz,libX11, etc) are in my host /usr/lib/ directory but my target toolchain does not have the the libraries. My question is if I manually recompile the libraries with my target compiler will that solved my problem? Or I'm going to have find and install packages for each of the libraries for my target platform.
Thanks in advance.
You seem to compile for the target, so you need target libraries. Either compiled by yourself or provided by the toolchain development environment (if you have one). The latter usually saves you some headaches (cross compiling and setting the paths where necessary).
I see you are using openwrt toolchain. Openwrt seems to have libpng as a package. I'd go with that if possible.
Related
I'm writting a extension for pyton3.6. My develop machine run gcc7.3, and production environment os is centos6. I use the following link option to static link glibc to avoid upgrade glibc2.12 to glibc2.14+.
-Wl,-Bdynamic -lpython3.6m -Wl,-Bstatic -lboost_python36
But get error:
[ 50%] Linking CXX shared module helloext.so
/usr/bin/x86_64-linux-gnu-ld: cannot find -lgcc_s
/usr/bin/x86_64-linux-gnu-ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status
CMakeFiles/helloext.dir/build.make:94: recipe for target 'helloext.so' failed
make[2]: *** [helloext.so] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/helloext.dir/all' failed
make[1]: *** [CMakeFiles/helloext.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
Anyone known? Thanks.
The reason might be although libgcc is present it may not be in the paths known to ldconfig. Check this by doing
/sbin/ldconfig -p | grep libgcc
Does the output show that there is a link to libgcc corresponds to paths that you have listed above?
A work around for you may be to add the link to the relevant library to your compile command e.g.
... -L /usr/lib/gcc/x86_64-linux-gnu/4.6/
Another may be to create a symbolic link to the library yourself.
ln -s /usr/lib/gcc/x86_64-linux-gnu/4.6/libgcc_s.so /usr/lib/gcc/libgcc_s.so
You have not informed us about Linux you are using. Update 4.6 with the proper number in the command above.
I'm building a shared library (C++ code using some C++11/14 features) which links to my own static library and uses threads. It all uses CMake. When I link my shared library ("gscore") and it tries to link to my static library ("gslicense"), I get and error regarding a symbol in pthreads. Full text is further down but the short version is this:
'__pthread_key_create' can not be used when making a shared object; recompile with -fPIC
I've tried following the advice and added -fPIC to the compile-time flags for both of my projects. I've verified that -fPIC is part of my compilation flags but the error persists. I'm not sure what I'm missing.
Here is the error.
[ 57%] Linking CXX shared library libgscore.so
/usr/bin/ld: ../gslicense/libgslicense.a(gslicensing.cpp.o): relocation R_X86_64_32 against `__pthread_key_create' can not be used when making a shared object; recompile with -fPIC
../gslicense/libgslicense.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
GSCore/CMakeFiles/gscore.dir/build.make:1014: recipe for target 'GSCore/libgscore.so' failed
make[2]: *** [GSCore/libgscore.so] Error 1
CMakeFiles/Makefile2:173: recipe for target 'GSCore/CMakeFiles/gscore.dir/all' failed
make[1]: *** [GSCore/CMakeFiles/gscore.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
Here is how I added threading to my project in my CMakeLists.txt file
#
# pthread
set(THREADS_PREFER_PTHREAD_FLAG ON)
find_package(Threads REQUIRED)
target_link_libraries(gscore Threads::Threads)
This is all part of a port of a Windows codebase to linux using CMake. I'm extremely familiar with Windows but fumble around in Linux. I've tried searching all the threads I can find on SO but I'm still at a loss.
Any idea what I'm missing?
I'm trying to get started with SDL and trying to compile a 'hello world' starter app to check my configuration and I get this error:
C:/MinGW-4.8.1/bin/g++.exe -c "C:/Users/Me/Documents/Cpp_Projects/Demo_Graphics/main.cpp" -g -O0 -Wall -o ./Debug/main.cpp.o -I. -IC:/Users/Me/Documents/Cpp_Projects/SDL2/32bit/include
C:/MinGW-4.8.1/bin/g++.exe -o ./Debug/Demo_Graphics #"Demo_Graphics.txt" -L. -lC:/Users/Me/Documents/Cpp_Projects/SDL2/32bit/lib/
c:/mingw-4.8.1/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -lC:/Users/Me/Documents/Cpp_Projects/SDL2/32bit/lib/
collect2.exe: error: ld returned 1 exit status
mingw32-make.exe[1]: *** [Debug/Demo_Graphics] Error 1
Demo_Graphics.mk:79: recipe for target 'Debug/Demo_Graphics' failed
mingw32-make.exe[1]: Leaving directory 'C:/Users/Me/Documents/Cpp_Projects/Demo_Graphics'
mingw32-make.exe: *** [All] Error 2
Makefile:4: recipe for target 'All' failed
1 errors, 0 warnings
The directory C:/Users/Me/Documents/Cpp_Projects/SDL2/32bit/lib/ certainly does exist and has the required SDL libraries in it, but I have no clue about compilers.
This is predefined code which should work so the problem is in set up somewhere?
The -l compiler flag is adding a library dependency. It does not specify a path in which to look for libraries (that is the -L flag), which appears to be what you are expecting.
In your error message:
-L. -lC:/Users/Me/Documents/Cpp_Projects/SDL2/32bit/lib/
You can see that the compiler is looking in your current working directory (.) for the library C:/Users/Me/Documents/Cpp_Projects/SDL2/32bit/lib/, but this is not a library -- this is the directory in which you're storing the SDL libraries.
In the CodeLite linker setup you want to change your library path to C:/Users/Me/Documents/Cpp_Projects/SDL2/32bit/lib/, or use
-LC:/Users/Me/Documents/Cpp_Projects/SDL2/32bit/lib/
as a build flag.
You also need to link to the SDL2 library, so you'll need to add -lSDL2 (possibly -lSDL2main as well, I can't remember the specifics of the SDL libraries) to your build/linker flags.
I have problem building Port Audio on windows machine. I am following this tutorial: http://portaudio.com/docs/v19-doxydocs/compile_windows_mingw.html
Running make after ./configure runs build process and finally outputs this message and that is where build process stop.
/bin/sh ./libtool --mode=link gcc -shared -rpath /usr/local/lib -no-undefined -
export-symbols-regex "(Pa|PaMacCore|PaJack|PaAlsa|PaAsio|PaOSS)_.*" -version-inf
o 2:0:0 -o lib/libportaudio.la src/common/pa_allocation.lo src/common/pa_convert
ers.lo src/common/pa_cpuload.lo src/common/pa_dither.lo src/common/pa_debugprint
.lo src/common/pa_front.lo src/common/pa_process.lo src/common/pa_stream.lo src/
common/pa_trace.lo src/hostapi/skeleton/pa_hostapi_skeleton.lo src/hostapi/wmme/
pa_win_wmme.lo src/os/win/pa_win_hostapis.lo src/os/win/pa_win_util.lo src/os/wi
n/pa_win_waveformat.lo -lwinmm
*** Warning: linker path does not have real file for library -lwinmm.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libwinmm but no candidates were found. (...for file magic test)
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
libtool: link: lib -OUT:lib/.libs/libportaudio.lib src/common/pa_allocation.o s
rc/common/pa_converters.o src/common/pa_cpuload.o src/common/pa_dither.o src/com
mon/pa_debugprint.o src/common/pa_front.o src/common/pa_process.o src/common/pa_
stream.o src/common/pa_trace.o src/hostapi/skeleton/pa_hostapi_skeleton.o src/ho
stapi/wmme/pa_win_wmme.o src/os/win/pa_win_hostapis.o src/os/win/pa_win_util.o s
rc/os/win/pa_win_waveformat.o
./libtool: line 1115: lib: command not found
make: *** [lib/libportaudio.la] Error 127
I am newbie in building libraries so i dont understand what is wrong here.
Any help is appreciated.
While compiling a project i get the following error as
c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/bin/ld.exe: cannot find lwxmsw28
collect2: ld returned 1 exit status
make[2]: *** [dist/Debug/MinGW-Windows/libRegistration.dll] Error 1
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2
I am using wxwidgets libraries however when i ran a command in cmd as
wx-config --libs
i could not see lwxmsw28 either let me know if it is downloadable from somewhere or any workaround to resolve this issue.
Thanks
This is a linker error, rather than a compilation error.
"lwxmsw28" looks to me like a wxwidgets v2.8 microsoft windows library. Should the linker be looking for this? Since you are using mingw, I would think you should NOT be linking to msw libraries. However, I am not familiar with mingw, so maybe this is the name used for mingw libraries.
If this is the correct library, then the next question is: have you built the wxWidgets libraries? The libraries are NOT "downloadable from somewhere" - you must download the source and build the libraries yourself.
A simple test to find out if you have built the libraries - try to build one of the sample projects.