Using code::blocks 17.02 and gcc 7.3.0 (mingw distro #nuwen.net) I am stuck with this error:
Cannot find -lgtk-3
Cannot find -lglib-2.0
Cannot find -lgobject-2.0
even though i have added these libraries in the linker settings. I downloaded the GTK 3 static libraries from: http://www.tarnyko.net/en/?q=node/31
I tried to, not link these libraries from the linker settings; then i got undefined functions.
So I was using 32-bit gtk+3.0 libraries, with 64-bit mingw (GCC).
That caused this:
ld.exe uncompatible with -libxxxxx.a;
ld.exe cannot find-lxxxxx
error.
Solution: either replace GTK+'s 32-bit libraries with 64-bit ones to match the 64-bit compiler collection.
Or download mingw32(GCC) 32-bit to match the 32-bit libraries. all should be fine then.
Here:
Related
My os is Kali, running GLIBC_2.32. I need to build an CGO application for a debian 10 system, which is running GLIBC_2.28.
If I go build with dynamic linking, it can't be run on the debian system, it shows GLIBC mismatch:
version `GLIBC_2.29` not found
version `GLIBCXX_3.4.29` not found
version `GLIBC_2.32` not found
So I tried static linking: CGO_LDFLAGS='-static' go build. A gui library uses OpenGL and it shows error:
# github.com/go-gl/gl/v3.2-core/gl
/usr/bin/ld: cannot find -lGL
After searching a while I found the libGL is related to the gpu driver and can't be statically linked.
Then I tried linking libGL.so dynamically and statically linking other libraries by:
CGO_LDFLAGS='-L/usr/lib/x86_64-linux-gnu -Bdynamic -lGL -static' go build
But same error: "cannot find -lGL"
I don't want to use docker, it's too heavy. And I don't think upgrading from debian 10 to 11 solves the problem, there maybe some other clients running different os in the future. What's the best solution?
Then I tried linking libGL.so dynamically and statically linking other libraries by:
CGO_LDFLAGS='-L/usr/lib/x86_64-linux-gnu -Bdynamic -lGL -static' go build
The -static flag tells the linker: perform a completely static link. It doesn't matter whether you put it before or after -lGL, the meaning is the same.
To link some libraries statically and link others dynamically, see this answer.
That said, what you are trying to do is impossible: if you have any dynamic libraries in your link, then libc.so.6 must also be dynamically linked.
I don't want to use docker, it's too heavy.
Too bad. You'll have to use docker, or set up a chroot environment, or build yourself a "Linux to older Linux" crosscompiler. The docker is likely easiest to implement.
I want to do the static compilation of my code with glibc using codeblocks.For that , I have done the following ,
Project->Build Options->Linker settings->Other-linker-options , and then added -static-libgcc. And then build and the ran the code. The code was working fine in that Ubuntu-14.04 machine having glib version 2.19. Then I copied the code to another machine having 2.12. The sole purpose of doing static linking was to make the code running in 2.12 as well. But it is giving the same error like that no static linking,as follows,
/usr/lib64/libstdc++.so.6: version GLIBCXX_3.4.15' not found
/lib64/libc.so.6: versionGLIBC_2.14' not found
Can anybody please help me on this ? Am I doing the static linking of glibc correctly?
glibc is not libgcc (the GCC compiler support library). glibc is libc (the GNU C Library). -static-libgcc statically
links libgcc. You can't statically link libc except by statically
linking the entire executable, with -static.
On upgrading to boost 1.60.0 some applications are failing to link with boost log when built with MinGw 4.9.2 on Windows 7.
I get the following linker errors:
undefined reference to `_imp___ZN5boost3log9v2_mt_nt67trivial6logger3getEv'
undefined reference to `_imp___ZN5boost3log9v2_mt_nt63aux15stream_providerIcE17allocate_compoundERNS1_6recordE'
undefined reference to `_imp___ZN5boost3log9v2_mt_nt63aux25unhandled_exception_countEv'
undefined reference to `_imp___ZN5boost3log9v2_mt_nt611record_view11public_data7destroyEPKS3_'
bad reloc address 0x1 in section `.text$_ZNK5boost4asio5error6detail13misc_category4nameEv[__ZNK5boost4asio5error6detail13misc_category4nameEv]'
Note: BOOST_LOG_DYN_LINK is defined:
g++ -c -pipe -fno-keep-inline-dllexport -Wall -Wextra -Wpedantic -Ofast -std=c++1y -frtti -fexceptions -mthreads -DUNICODE -DLOGGING_ENABLED -DNTDDI_VERSION=NTDDI_WIN7 -D_WIN32_WINNT=_WIN32_WINNT_WIN7 -DBOOST_THREAD_USE_LIB=1 -DBOOST_LOG_DYN_LINK=1
The boost 1.60.0 build log file shows that both boost log and boost log_setup built without any errors or warnings, including some of the files that it's failing to link with e.g.:
gcc.compile.c++ bin.v2\libs\log\build\gcc-mingw-4.9.2\release\threading-multi\trivial.o
gcc.compile.c++ bin.v2\libs\log\build\gcc-mingw-4.9.2\release\threading-multi\unhandled_exception_count.o
The applications link OK using boost 1.59.0 with MinGw 4.9.2 on Windows 7 and also link OK using boost 1.60.0 with gcc 5.1.1 on Fedora 23.
boost asio hasn't changed since boost 1.58.0. So what's changed in boost log between boost 1.59.0 and boost 1.60.0 to cause MinGw linking to fail on Windows?
Boost.Log was probably built with different options than your application, so it has a differently named version namespace. Have a look at the exported symbols with Dependency Walker and see the description. I suspect, the difference will be in the OS API component of the namespace, as the setup of the target Windows version has changed in 1.60. You're building your application for Windows 7 while Boost.Log is most likely built for Windows XP.
When you identify the difference, you have to correct Boost building options and rebuild Boost. E.g. to set target Windows version to 7 define BOOST_USE_WINAPI_VERSION to 0x0601. If you don't want to change Windows version Boost is targeted for, you can define BOOST_USE_WINAPI_VERSION to 0x0501 while building your application, indicating that you want Boost to keep targeting XP even though your application is targeting 7.
I am trying to link my program statically with glibc, because version of the glibc on the target machine is pretty much unpredictable. I used linker flags -static-libgcc and -static-libstdc++ and it worked fine. The executable is big, but I can live with it. Unfortunately, when I run my executable on the target machine (it is named 'mytest' in the example below) I get the following error:
./mytest: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by libboost_log.so.1.53.0)
./mytest: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by libboost_log.so.1.53.0)
./mytest: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by libboost_log.so.1.53.0)
./mytest: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by libboost_date_time.so.1.53.0)
./mytest: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by libboost_thread.so.1.53.0)
If I do 'strings' on mytest, it gives me
$ strings mytest | grep GLIBC
GLIBC_2.9
GLIBC_2.7
GLIBC_2.8
GLIBC_2.3.2
GLIBC_2.2.5
GLIBCXX_3.4.15
GLIBCXX_3.4.11
GLIBCXX_3.4.14
GLIBCXX_3.4.9
GLIBCXX_3.4
What means, I think, that the static linking was working ok. Why does the loader still tries to look for my functions in shared glibc and libstdc++? What am I doing wrong?
Thanks!
I am trying to link my program statically with glibc, because version of the glibc on the target machine is pretty much unpredictable. I used linker flags -static-libgcc and -static-libstdc++ and it worked fine.
That didn't affect the version of glibc (libc), which is different from libgcc and libstdc++. With these flags, you still have produced a dynamically-linked executable, which is expected to not work on an older distribution.
You can link your executable with -static flag, and that should give you a completely static executable.
Update:
After re-reading your question; your problem is not with glibc. Your problem is that you are linking with libboost_log.so, which itself depends on libstdc++.so.6.
The answer then is to link with libboost*.a instead of libboost*.so. You can try to achieve it this way:
g++ $(OBJS) -static-libgcc -static-libstdc++ -Wl,-Bstatic -lboost_log ... \
-Wl,-Bdynamic
(It is very important to have the trailing -Wl,-Bdynamic.)
Linking with -static-libgcc and -static-libstdc++ will only work for those libraries. It looks like you are also linking against the boost libraries (likely dynamically) which then link against libgcc and libstdc++.
Try running the following:
ldd mytest
It should show "not a dynamic executable". If it shows anything else, it means it is dynamically linked against other libraries. It doesn't always work so easily, but try adding -static to the compilation line as well to take care of remaining libraries.
I have downloaded and installed the ffmpeg library. I want to use it for reading the separate frames of different videos and manipulate them. For that I tried to follow some tutorial from here: http://dranger.com/ffmpeg/tutorial01.html
But I can't compile my cpp file since I get the following compilation:
Undefined symbols for architecture x86_64:
"av_register_all()", referenced from:
_main in cc9zyUBe.o
_main in ccRz35d4.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
When I was installing ffmpeg library, I used arch=x86_64 option in ./configure step.
I use OS X Mountain Lion 10.8.2 and gcc 4.2 compiler.
Does somebody have any clue what can be the reason of this error?
Thanks in advance.
UPDATE:
I've already tried many different install options, with static libraries, shared libraries, with/without --arch=x86_64 option. Also installed it with homebrew, result remains the same. Library isn't recognized. But ffmpeg binary works pretty well, when I use it as a command-line tool.
Finally I have managed to compile my program which uses ffmpeg library.
For some reason I still couldn't compile it using gcc compiler, but I could do it with g++ compiler.
When the static libraries are installed, all the dependencies must be specified explicitly, and the order of linking of these libraries is also important. So here is the compilation code which finally compiled my program:
g++ readVideo.cc -o readVideo $(pkg-config --libs --cflags libavformat)
pkg-config here is a utility which prints all the flags and libraries that are needed to properly link the specified libavformat library.
Also it's worth of mentioning, that the source file was renamed from readVideo.C to readVideo.cc, and that #include statements have been encompassed using extern "C" as follows:
extern "C" {
#include <libavformat/avformat.h>
}
It is needed because ffmpeg is a C project and program will not compile with C++ compiler if you don't explicitly state that it is C library.
And if you don't want to bother with pkg-config to include all dependencies for ffmpeg libraries, you can install ffmpeg with shared libraries instead of static ones. Then it will compile by simpler call:
g++ readVideo.cc -o readVideo -lavformat
To install shared libraries, you need to add these 2 options to ./configure program when installing ffmpeg:
--disable-static --enable-shared
Hope it helps somebody some time ...
The error means that you aren't linking to the ffmpeg libraries. Simply including the header files is not enough. You need to also link to the actual library files. On Windows they have .lib extension, on Linux usually .a extension, not sure about Mac.