I'm developing c++ code on Visual Studio 2019 (Version 16.5.4), and for the build i'm targeting Linux Ubuntu 18.04 with gcc 7.5 - both on a remote machine via ssh, and on my local machine via WSL2.
In both cases i have the same problem:
when using std::async, i have to add the compilation flag -lpthread to gcc's input, in order for the program to compile, otherwise i get
undefined reference to pthread_create
Moreover, the flag has to come after the cpp file name, i.e. g++ -lpthread xxx.cpp will fail with gcc 7.5, while g++ xxx.cpp -lpthread works fine.
so far so good, but here's the problem: i can't do a successful build through Visual Studio: when i add the -lpthread flag under Additional Options in the project's C/C++ properties, there doesn't seem to be any effect - the compilation still fails. moreover, since i don't see the flag being added to the full build command line (which is presented read-only), i have no way to see if the flag is actually being sent, and in the right order (namely after the cpp file name). since i don't see any way to manually edit the build command line, I'm out of ideas...
anyone?
Thanks.
Related
I am trying to run the example samples/sgemm.cpp from the CLBlast repo on
Windows 10 with a Nvidia graphics card. I have obtained the cl.hpp from the link. The makefile is simply as follows:
a.exe: sgemm.cpp
g++ sgemm.cpp -lopencl -clblast -O0 -g -DCL_TARGET_OPENCL_VERSION=300
I have the Nvidia CUDA toolkit v11.6 installed and the include directory is on the environment variable CPATH so that it is found by g++. Furthermore, the compiler is part of a Mingw-w64 installation on which clblast is installed.
The problem is that the compilation seems to succeed, but as soon as I try executing the a.exe it crashes without any error message. Similarly, attaching gdb does not help either, because the program exits immediatedly and gdb prints
During startup the program exited with code 0xc0000135.
What is the problem?
Update
I have opened an issue on the clblas github. Note that I can compile clinfo from here without problems. A missing library therefore should not be the first thing that comes to my mind.
To answer this, this was not a problem with gdb, a.exe or the CUDA toolkit but rather with the installed library which is build with Visual Studio. The resulting binary seems to be incompatible with g++. Therefore, installing the library from source using g++ fixed this.
I've been building my own c++ linux application in vs2017, using the built in tools that connect to my virtual ubuntu VM. I have gotten to a point where I want to integrate protobuf into my project, but I am running into issues as to how to do so.
I have installed the protobuf libraries and compiler on my VM using Google's UNIX C++ installation guide. And I am able to compiler without issue. After I compiled one message, I brought the files back over to my windows side so that I can bring them into my VS project. However that causes all sorts of errors, mainly:
undefined reference to 'google::protobuf::internal'
So I went through a previous Stack Overflow post where the user ran the following command on the VM:
pkg-config --cflags --libs protobuf
and the took the text in that output, and put it into his Linker > All Options > Library dependencies in his VS project on the windows side. For me, that was:
-pthread -lprotobuf -pthread -lpthread
However, when I compile, I get cannot find. I've been trying to find out what are the best practices when doing linux development through VS2017, and wanting to use protobuf. Any help on how to get that entire chain working would be great.
(this question similar to this one but is not the same)
I'm using QtCreator on Windows platform, usually with vc toolchain.
sometimes with MinGW-W64, so for now, I'd like to try clang for some reasons.
unlike the post above - I don't use Qt library , just qtcreator as IDE, so I suppose I don't need to re-build it and QtCreator for a using clang kit, is it correct?
there are a few questions about that:
CLang distribution doesn't contain platform or even c/c++ runtime library, should i use it from vc kit? or/and MinGW runtime? how to switch between?
Correct my understanding please if it's wrong - for Win platform, clang has two options to use: 1) normal use - clang.exe ,as on any other platform 2) clang-cl.exe - additional layer which "looks like" cl.exe, and just parses cl command line keys and calls normal clang.
as I understand there is no LLDB for Windows platform , can I use GDB or CDB depends of the used runtime lib and binary format of the executable?
and finally - how to configure all this in qtcreator?
The following steps apply only to MSYS2 64-bit installation of QT Creator 4.5.1 (install instructions here), where you also have MinGW-w64 and mingw32-make installed on MSYS2; and you are building a non-QT C or C++ application.
These instructions use QMake, because QBS doesn't support MSYS2 clang. Well, QMake doesn't support it either, but I did figure out how to add support to QMake and I didn't figure out QBS.
There is QMake support for MSVC-clang but it outputs MSVC makefiles, so you can't build it with MSYS2 make. So that does not apply to us.
Install clang with pacman. I used pacman -Ss mingw-w64-x86_64-clang, your flavour may vary.
Add support for clang to QMake:
In the MSYS2 shell, go into /msys64/mingw64/share/qt5/mkspecs/
Do cp -a win32-g++ win32-clang-msys
Edit win32-clang-msys/qmake.conf and change gcc to clang, and g++ to clang++ (2 places each)
In the same file, take out -fno-keep-inline-dllexport -mthreads which are not supported by clang.
In QT Creator, set up a new Kit:
Go to Manage Kits.
Add a Custom Compiler for C and browse to the installed path (/mingw64/bin/clang.exe under your MSYS2 install).
Add a Custom Compiler for C++ as clang++.exe in the same place)
Add a manual Kit called Clang and set those two compilers as its compilers.
In the manual kit config set "Qt mkspec" as win32-clang-msys
Set "QT Version" to something. Even though I am using a non-QT project, the IDE doesn't like using the kit if "Qt version" is set to None.
Now you can attempt to build your project with the Clang kit and QMake.
I initially tried with QBS and the build failed due to this bug . But the build commands do succeed if I copy-paste them and cut out the bogus -target switch. So for QBS users I guess you have to switch to QMake in the meantime until they fix that bug.
Troubleshooting: I sometimes got an error Project ERROR: failed to parse default search paths from compiler output. This is a problem with QMake's lack of support for clang. The error tended to not occur if I built in a subdirectory of the .pro file, but did occur if I built in a sibling directory.
As a workaround: go back into win32-clang-msys/qmake.conf. Change the first clang back to g++. Then "Run Qmake" (from QT creator or commandline), then change it back. The first time you run QMake it writes the file .qmake.stash and then does not need to generate it again. The contents of this file were bogus for me but building seemed to work anyway.
Undefined references: I found that linking with -static produced a bunch of undefined references to __imp__cxa_ names. Not sure what the problem is here but maybe related to the bug with generating .qmake.stash. I guess the Qt developers would need to officially add non-MSVC Clang support to QMake.
Multiple definitions: The CLang linker gave multiple definitions for inline DLLexport functions. I found no workaround yet for this; g++ has -fno-keep-inline-dllexport to avoid this problem but CLang 5 does not support that flag.
So I recently installed a new version of CodeBlocks with the MinGW 4.7.1 compiler, and I am no longer able to build my projects. The compiler throws the following error:
error: unrecognized command line option '-static-libstdc++'
I believe I was previously using 4.4.1 (going by the files in MinGW/bin). I installed the CobeBlocks 12.11 package that is supposed to come with the 4.7.1 compiler included.
How do I solve this? Removing that option from the compiler settings causes my previously functional application to instantly crash upon startup.
The compiler bundled with Codeblocks 12.11 is tdm-gcc 4.7.1, which by default links libstdc++ statically and reports -static-libstdc++ as an error. So if you want to dynamically link to libstdc++, add -shared-libstdc++.
I want to install Clang compliler on my system. I went to this link, but so many download options out there confused me, as to which version should I download?
I'm using Dell's laptop : Windows 7 Basic 64-bit. I've already installed MinGW version 4.5.0. I've also installed Visual Studio 2008 as well as 2010.
What do you think is the best choice for me? Which Clang should I download? How should I configure it? I'm going to use Clang for the first time. So suggest me the best options!
By the way, can I configure Clang (or Visual Studio) so that Visual Studio may use Clang compiler to compile my C and C++ code?
EDIT:
What does it mean when the download page cryptically says "Front End Binaries for Mingw32/x86"?
You can use Clang with Visual Studio or MinGW. The choice is yours. But you'll need an external linker to produce Windows executables (MSVS's link.exe or MinGW's ld.exe/g++.exe).
If you want to use MinGW, download the next to last item (frontend binaries to mingw).
You can also compile Clang/LLVM from source, for that see here. This allows you to try out MSVS or MinGW(-w64). You'll need CMake for the build process.
UPDATE: regarding your edit: the "frontend" description reflects either the fact that llvm can be used as a backend in a GCC compilation through llvm-gcc (google has loads of info on this) or the fact that Clang itself is unable to link your code together into an executable or library. You still need the system's linker as I described above.
Clang now started releasing Windows snapshot builds
None. Front End Binaries # Mingw32/x86 is close, but you explicitly mentioned Windows 7 Basic 64-bit
so to be very specific you'll avail 64-bit benefits. So you'll follow steps at http://clang.llvm.org/get_started.html#buildWindows You may get VS2012 Express and the string with CMake should be "Visual Studio 11 Win64" Select Release instead of the default debug configuration from the dropdown and then build. Tool-chains are tightly coupled hierarchy, and MS's indulgence in non-standard extensions was never up-to-date by any other vendor implementation. Till llvm libcpp completes MinGW-W64 is the closest libstdc++ that I got from http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-bin_i686-mingw_20111220.zip/download Check for newer build at http://mingw-w64.sourceforge.net/ Following are my trial calls for Hi console app
clang++.exe -fno-ms-compatibility -fno-use-cxa-atexit -IC:\mingw\include\c++\4.7.0 -IC:\mingw\include\c++\4.7.0\x86_64-w64-mingw32 -IC:\mingw\include\c++\4.7.0\backward -IC:\mingw\include -c C:\Users\Vipul\Documents\Hello.cpp -o C:\Users\Vipul\Documents\Hello.o
ld.exe -oC:\Users\Vipul\Documents\Hello.exe C:\Users\Vipul\Documents\Hello.o -m i386pep -Bdynamic -Lc:\mingw\lib c:\mingw\lib\crt2.o c:\mingw\lib\crtbegin.o -lstdc++ -lmingw32 -lgcc_s -LC:\Windows\SUA\opt\gcc64\lib\gcc\x86_64-pc-interix6\4.6.0 -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 c:\mingw\lib\crtend.o
The parameters are set on one single occasion of configuring IDE setting for say Code::Blocks The libs to pass to ld linker are determined using -v along-with g++ as clang++ will try to link libc++ sources against VS2012 binaries. Using g++ rather than ld is easier but seldom fails with ld not found internally owing to close coupling of tool-chain by hardcoding tool locations within source.