Problems Linking boost log 1_60 with MinGw on Windows 7 - windows

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.

Related

How to build CGO program static linking to glibc and dynamic linking to libGL.so?

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.

g++ with -m32 --coverage profile .gcda: Cannot open

When I'm trying to compile my C/C++ software using gcc/g++ with -m32 option on RedHat 6.10 which is a 64bit OS, we have a Dell isilon file system exporting 64 bit file ID's we get a run-time error using code coverage compile options. I wrote a simple main() test app test.cpp and compile with the following compile options.
g++ --coverage -m32 test.cpp -o test
When I run the 32bit executable we get a run-time error relating to our file system exporting 64bit file ID's vs 32 bit. We don't want to change to a 32bit file ID export.
./test
profiling:test.gcda: Cannot open
If we compile the app without the -m32 option the problem goes away. However, I need to compile with -m32 for other reasons outside the scope of this discussion.
gcc version 4.4.7 20120313 (Red Hat 4.4.7-23) (GCC)
RedHat 6.10 64bit OS
Thank you for any help.
It appears that a later version of gcc has fixed this problem. I now know that gcc version 8.2.0 compiles properly and doesn't have the error about not being able to find the .gcda file. This makes sense since the Dell isilon system is newer and the gcc compiler version we've been using with RedHat 6.10 is quite old.

GCC gprof complaining GLIBC_2.16 is not found

I have a code running on a PowerPC e500v2 embedded Linux and I want to measure its performance since it is running in an infinite loop. I tried gcc's gprof which was simply by adding -pg option to gcc. When I run the binary on the target device I get this:
./main: /lib/libc.so.6: version GLIBC_2.16 not found (required by ./main)
I am using ELDK 5.6 toolchain with the default CFLAGS and LDFLAGS and these flags: -Wall -lrt -pthread -D_GNU_SOURCE nothing else. Some article suggested defining FORTIFY_SOURCE along with an optimization level but it did not work. I searched for some gcc's feature test macros and tried defining some GLIBC 2.16 specific macros but it did not work.
I faced similar issue with GLIBC 2.17 when I used some structures and functions from <sched.h>, adding _GNU_SOURCE resolved it. Any idea on how to resolve it?
When I run the binary on the target device I get this
Your tool chain targets a version of GLIBC that is newer than what is installed on the target.
This doesn't bite you in non-pg compiles only by accident. An "innocent" change to your source can cause the same problem.
You need to upgrade your target to the version of GLIBC which your toolchain actually builds for.

LLVM / Clang 8 Compilation of OpenMP Code in Windows

I'm using the Windows version of Clang (LLVM) 8 under Windows.
I'm compiling a code which uses OpenMP.
Under the lib folder of Clang there are 2 files which are OpenMP related:
libomp.lib.
libiomp5md.dll.
My questions are:
When I compile the code I use the flags -Xclang -fopenmp for the compiler. In in GCC and ICC using the flags tell the compiler to link the OpenMP library automatically. What about Clang? Does it do it automatically or must I link with libomp.lib manually? Is there a way to trigger automatic linking to the OpenMP library?
Answer: This was answered in Michael Klemm's answer below - Use the clang driver both for compiling and linking and then the -fopenmp will work as in GCC.
When I link with libomp.lib manually (Defining as a library for the linker) the output exe requires libomp.dll while the supplied OpenMP Dynamic Library is libiomp5md.dll. Is that a bug or is it because I link manually?
Answer: The libomp.dll is supplied in the bin folder and not the lib folder.
What's the proper way to utilize OpenMP in Clang under Windows? The clang-cl driver doesn't work with /openmp or -openmp as the MSVC's cl compiler.
Answer: Currently it can be done either with clang -fopenmp ..., clang-cl -Xclang -fopenmp ... or clang-cl /clang:-fopenmp ... (Which is equivalent of -Xclang -fopenmp).
Remark
On Windows I use Windows Driver of Clang using clang-cl.
Adding clarity to what the OpenMP libraries actually are, and how to use them on Windows with clang-cl
libomp.dll and libiomp5md.dll ARE THE SAME FILES!
When compiling for Windows, you link against libomp.lib OR libiomp5md.lib which will link to the same-named DLL at runtime, i.e. libomp.dll OR libiomp5md.dll respectively.
If you load 2 files that use the "different-name DLL," the interpreter will crash and give you a nasty error like: OMP: Error #15: Initializing libiomp5md.dll, but found libomp.dll already initialized.
Why? Because the program has no idea they are the same DLL, they have different names, so it assumes they are different. And it crashes. For this reason only, you can choose to swap which OpenMP DLL you link to in your program.
If your program doesn't crash and give you an error, you can keep using the same link to OpenMP. Otherwise, to silence the error, link to the one that is loaded by another program already.
If using clang-cl.exe which is the "drop-in" Clang replacement for MSVC cl.exe you should pass a compiler argument such as -Xclang -fopenmp which will convert the argument over to "Clang language." Don't forget to still pass to the linker the OpenMP LIB you chose, because on Windows, it won't be automatic.
That's all I've learned as brief as possible about OpenMP linking on Windows.
To compile and link OpenMP code with clang on Windows, you will have to pass -fopenmp to both the compiler and the linker:
clang -fopenmp -o bla.obj -c bla.c
clang -fopenmp -o bla.exe bla.obj

How to link GTK-3 static libs through codeblocks? [-ld.exe uncompatible with -libxxxxx.a -ld.exe Cannot find -lxxxxx] error

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:

Resources