Latest CMake and LLVM on Windows 10 - cmake

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.

Related

Linux or Windows version of a library in Cygwin?

I have developed some codes in Linux which use boost::serialization library. Now I want to copy my files into Cygwin and compile them to produce executable for Windows. I know that I should use Mingw-64 g++ compiler. But how about boost library? Should I download the Windows version or the Linux version of this library?
In Cygwin, you install Boost libraries as per Unix/Linux. From the documentation
Getting Started on Windows
A note to Cygwin and MinGW users
If you plan to use your tools from the Windows command prompt, you're in the right place.
If you plan to build from the Cygwin bash shell, you're actually running on a POSIX
platform and should follow the instructions for getting started on Unix variants.
Other command shells, such as MinGW's MSYS, are not supported—they may or may not work.

CMake Windows Phone problems

I have a project that is using CMake as a build system, and I need to port it to Windows Phone. Sadly, but when I try to run cmake .. -G "Visual Studio 12 2013" it fails, saying
A Windows Phone component with CMake requires both the Windows Desktop SDK
as well as the Windows Phone '8.0' SDK. Please make sure that you have
both installed
And this is really weird, because I do have both of them installed. Adding -DCMAKE_SYSTEM_NAME and -DCMAKE_SYSTEM_VERSION doesn't help, still the same result. Even if I specify the system version to 8.1, it still says I'm missing '8.0' SDK.
I tried googling, but it didn't help either. It seems that some people have run into same problem, but similar questions are all unanswered for some reason. I'm using CMake 3.2.2 now, tried on 3.2.0 with same output.
Completely lost at this now and have no idea what to do with that. Any suggestions?
Looks like its been fixed in CMake 3.4 https://public.kitware.com/Bug/view.php?id=15662
The location in the registry CMake uses to find the SDK's seem to have changed in Windows 10.

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

cmake on Solaris 10 Sparc: Configured not to use shared libraries?

I'm trying to port some software over to Solaris 10 Sparc, using GCC 3.4.6, and the software's build system uses cmake. When I run the command cmake CMakeLists.txt, I get a lot of output like this:
ADD_LIBRARY for library <library_name> is used with the SHARED
option, but the target platform supports only STATIC libraries.
Building it STATIC instead. This may lead to problems.
Obviously Solaris 10 Sparc supports shared libraries, and I have built this software on x86 Solaris 10 before.
Anyone run into this or can provide direction? I'm about to dive into the cmake source to figure out if it has issues with Sparc Solaris.
Thanks.
After fighting with this a couple hours, and making little headway, I decided to install cmake-2.8.6 from OpenCSW using pkgutil, and this issue cleared up.
Also asked this question in #cmake#irc.freenode.net before I fixed it, looks to be an issue with cmake 2.6.4 on Sparc Solaris 10.

Building an NPAPI browser plugin on Linux x86 and x86_64, how do I ensure that it loads the correct version of its dependent libraries?

I'm attempting to build a Linux browser plugin using Firebreath that runs on 32bit and 64bit Linux.
In my X11/projectDef.cmake I have
target_link_libraries(${PROJECT_NAME}
${PLUGIN_INTERNAL_DEPS}
"${CMAKE_CURRENT_SOURCE_DIR}/lib/libOIS-1.4.0_32.so"
)
Currently I'm just manually changing that line switching 32 to 64 when I want to do a different build, so that's probably wrong. But my issue is that even when I build with the 32bit library and it compiles successfully, I get the following error when trying to load the plugin in Firefox:
$ firefox
LoadPlugin: failed to initialize shared library /home/daniel/.mozilla/plugins/npBoomstickJavaScriptJoystickSupport.so [libOIS-1.4.0.so: wrong ELF class: ELFCLASS64]
How do I set up my cmake to automatically include the correct library depending on the architecture? Is there a way to build both x86 and x86_64 simultaneously on the same machine? How do I get the plugin to load correctly or is there a way to further debug this problem?
As far as I know the only way to do a build for 32 bit on a 64 bit machine is to use cross compiling: http://www.vtk.org/Wiki/CMake_Cross_Compiling
I've never actually tried this, but inside CMake you can probably use the CMAKE_SIZEOF_VOID_P which will be 4 in 32 bit mode, 8 in 64 bit. You could add an if to your cmake script to set the correct binaries depending on the size of that.