"no known features for CXX compiler" when compiling with MSVC++ 2013 - cmake

I have a relatively simple CMakeLists.txt that contains the following line(s):
target_compile_features(myapp PRIVATE
cxx_generalized_initializers
cxx_lambdas
cxx_nullptr)
When I run cmake on a Windows 2012 Server with MSVC++ 2013 Express installed, I get the following error:
CMake Error at CMakeLists.txt:61 (target_compile_features):
target_compile_features no known features for CXX compiler
"MSVC"
version 18.0.30723.0.
What is causing this error, and what can I do about it? CMake doesn't seem to have any problems when I build the project in Ubuntu 14.10 with GCC.
I am using CMake 3.1.0, in case that helps (it was the first CMake release to support target_compile_features).

CMake 3.1.0 only supports 'compile features' for GCC 4.7+ (on UNIX but not APPLE) and Clang (but not AppleClang) 3.4+.
CMake 3.2.0 will extend the support to GCC 4.4+ (on UNIX, including APPLE), AppleClang 4.0+ (Xcode 4.4+), SolarisStudio 12.4 and MSVC 2010+.
Patches and maintenance for other compilers can be sent to the cmake mailing list.
Make sure CMP0025 is NEW if you are on APPLE.
https://cmake.org/cmake/help/v3.6/command/cmake_policy.html

Related

Buildroot toolchain for BBB: gclib version error

I was trying to cross-compile from a Debian PC for a BeagleBone Black, and i was able to build an "hello-world" sample, and build the wxWidgets, but when i compiled a wxWidgets app (the "minimal" sample) i failed, 'cause i've not been able to find how to get and link the needed libraries for armhf (GTK+, X11, etc... see my question here)
I've found a page explaining how to use BuildRoot to compile for a Raspberry, so i took that route and i was able to configure and make a "host" which compiled the wxWidgets first, and the "minimal" sample app next.
Problem is that on my BBB it does'nt run 'cause different gclib version
debian#beaglebone:~$ ./minimal
./minimal: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.28' not found (required by ./minimal)
debian#beaglebone:~$ ldd --version
ldd (Debian GLIBC 2.24-11+deb9u3) 2.24
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
So, i'm again bashing my head against a wall.
What options should i use in BuildRoot to be able to use the same gcc (and all the required libraries, which i don't know to what should i look) that are present in my BBB?
Linux version 4.9.88-ti-r111 (root#b9-am57xx-beagle-x15-2gb) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP PREEMPT Sun Apr 22 08:04:34 UTC 2018
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
It sounds like you are building with one environment and running in a different environment.
That's akin to compiling on one distro and trying to run on another distro.
Or even compiling on one distro release and using another to run - e.g. Debian Jessie vs. Stretch.
Further evidence is that you mention:
BuildRoot as your build environment
debian#beaglebone and ldd (Debian GLIBC 2.24-11+deb9u3) 2.24
The fundamental version conflict is that BuildRoot and Debian 9 use different versions of libc (and other libraries)
The proper way to address this is by building inside a matching environment. In this case that would be Debian 9 - either as distro proper or at least as a chroot. The package that you should install is: crossbuild-essential-armhf
That will get you the necessary tool-chains and dependencies.

Latest CMake and LLVM on Windows 10

All
latest LLVM is 7.0 and it is working quite well on Windows 10 x64, building native executables etc.
latest CMake is 3.12.x.
I have VS 2017 Pro installed as well.
Downloaded them both and tried to make simple project with it on Windows, and it didn't work, even if I set CC/CXX, linker pointing to lld, failing on compiling test problem, not finding rc (resource compiler).
Tried targeting GNU make as well as Ninja as build system.
Is this a supported configuration? If yes, how to make it work?
Basically, I would like to use CMake/LLVM with editor/terminal like I'm doing it on Linux
Run CMake from Developer Command Prompt.
That should make rc available in your PATH, and then CMake should be able to find it.

g++ programs for windows 98

I am trying to make programs for an old computer running Windows 98 second edition, but they won't run.
The programs are written in c++, and they are compiled with MinGW (g++ version 4.8.1) installed on a Windows Vista computer. For testing I tried this simple Hello World program:
#include <iostream>
using namespace std;
int main(){
cout <<"hello world";
return 0;
}
For compiling I used this command:
g++ hello.cpp -o hello.exe
When trying to run this program on the Windows 98 computer I get the following message:
A required .DLL file, LIBGCC_S_DW2-1.DLL, was not found.
So to make the executable as independent of dll-files as possible, I tried compiling the program with the command:
g++ hello.cpp -static -o hello.exe
But on trying the program on the Windows 98 computer, I now get the message:
The hello.exe file is linked to missing export MSVCRT.DLL:_fstat64
To analyze the problem, I tried a few things. And I noticed that compiling the same code with the same command using g++ version 2.95.2 instead, the program was able to run on the Windows 98 machine. However, I would prefer not to use this old version of g++ as it contains a few problematic bugs.
I also noticed that a similar program made in regular c (compiled with gcc version 4.8.1) also worked fine on the old computer, but I would prefer not to use regular c as this would require rewriting a lot of c++ code.
So the question is: how can I make c++ programs compiled with g++ 4.8.1 (or later) run on a Windows 98 machine?
Late but better than never
found out later versions of MinGW doesn't run on windows 98 giving the error "A required .DLL file, LIBGCC_S_DW2-1.DLL, was not found."
the version of MinGW i tried and gave the error was this one (6.3.0-1)
(i think you are referring to the dev version there, probably the bin version you had was more modern)
oddly, i recalled that time ago i compilled a build using Code::Blocks using MinGW that ran in windows 98, so i downloaded Code::Blocks version 17.12, and compilled the very same exe using the MinGW provided there directly, and worked just fine
and noticed it was a fairly older version ((tdm-1) 5.1.0)
idk which was the latest version MinGW compilations worked on windows 98, i'll write a post about it in their forum soon
for the record, i'll show the pics of the test i did
on MinGW 6.3.0-1:
on MinGW (tdm-1) 5.1.0:
so, to answer the question; yes, you can make programs for windows 98 using MinGW's g++ greater than version 4.8.1 (up to a certain version, i'll ask in the forum for more information)
EDIT: no need to, found this:
"The default mode is C++98 for GCC versions prior to 6.1, and C++14 for GCC 6.1 and above. You can use command-line flag -std to explicitly specify the C++ standard. For example,
-std=c++98, or -std=gnu++98 (C++98 with GNU extensions)
-std=c++11, or -std=gnu++11 (C++11 with GNU extensions)
-std=c++14, or -std=gnu++14 (C++14 with GNU extensions), default mode for GCC 6.1 and above.
-std=c++17, or -std=gnu++17 (C++17 with GNU extensions), experimental.
-std=c++2a, or -std=gnu++2a (C++2a with GNU extensions), experimental."
i added the -std=c++98 -std=gnu++98 flags to the 6.3.0-1 compiler and it worked fine on Windows 98 SE
You can usually find msvcrt.dll by installing IE4
http://gnuwin32.sourceforge.net/packages/gcc.htm

How do I get gcc 4.5 (compiled from source) to work with Objective C|C++ programs on Mac OS X?

Anyone,
I have been unable to compile some packages, like WxWidgets, on Mac OS 10.6.4 using gcc 4.5 (compiled from source, not from MacPorts, Fink, etc. with all default languages and Obj-C++). Typically, when trying to compile against the Foundation framework, I get errors such as the following:
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:123:35:error: expected ‘;’ before ‘__attribute__’
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:138:1:error: stray ‘#’ in program
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:139:1:error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘-’ token In file included from main2.m:2:0:
/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:139:63:error: expected ‘;’ before ‘__attribute__’
I'm somewhat somewhat new developing on the Mac (more experience with Linux and Windows). Right now, I don't need to use Objective-C or Objective-C++. It's just getting in the way of being able to compile other packages (though I may want to start using it down the road). If anyone has any thoughts I would appreciate it. Thank you.
You...don't. GNU's GCC is not compatible with Apple's GCC in terms of Objective-C runtime support. You'll get the GNU Objective-C runtime which is the compatibility problem.
My strong suggestion to you is to not use C++0x features until the new standard is...a standard, and not a draft. Don't expect compiler support for draft features on all platforms.
On Lion, I was able to install gcc 4.7 using brew. I don't know if it will work on snow leopard.
You can try to install it from the homebrew-dupes container:
brew install --use-llvm --enable-cxx https://raw.github.com/Homebrew/homebrew-dupes/master/gcc.rb
Compiled gcc 4.7 successfully with c and c++ enabled on Lion.

Compiling a binary to work with valgrind on Snow Leopard

I installed valgrind on Snow Leopard using the patch at https://bugs.kde.org/show_bug.cgi?id=205241 . However, when I run it with a binary I compiled from C++ code, I'm told that valgrind "cannot execute binary file". What g++ flags should I set to make my program work with valgrind?
Be sure to use the -m32 option to generate a 32-bit executable. The compiler default is 64-bit (assuming you have a 64-bit machine), but valgrind does not yet officially support 64-bit executables on Mac OS X. The file command on your executable should report "Mach-O executable i386".