I have a Win32 project which I compile with MinGW. I would like to enable visual styles in this program without requiring an external manifest.
With MSVC, this apparently can be done with the following pragma:
#pragma comment(linker,"\"/manifestdependency:type='win32' \
name='Microsoft.Windows.Common-Controls' version='6.0.0.0' \
processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
However, GCC (MinGW) does not support such a pragma. Is there a way for me to emulate the behavior of this pragma with MinGW?
Well, it seems as if writing a resource/manifest is the only way forward here, so I have to proceed that way.
Related
From Clang's documentation:
When Clang compiles C++ code for Windows, it attempts to be compatible with MSVC.
In particular, Clang defines _MSC_VER.
MSVC does not support #pragma STDC FENV_ACCESS ON:
cl t125.c /std:c11
t125.c(11): warning C4068: unknown pragma 'STDC'
Instead MSVC does support #pragma fenv_access (on). This leads to this code:
#if _MSC_VER
#pragma fenv_access (on)
#else
#pragma STDC FENV_ACCESS ON
#endif
Now try to compile this code using the latest Clang on Windows:
$ /cygdrive/d/SOFTWARE/LLVM/12.0.0/bin/clang t125.c -Wall -Wextra
t125.c:10:9: warning: unknown pragma ignored [-Wunknown-pragmas]
#pragma fenv_access (on)
Meaning that since #pragma fenv_access (on) is unknown pragma which is ignored, then the MSVC compatibility is underdone / unfinished? Confused.
Question: how to disable the default MSVC compatibility (so that Clang does not define _MSC_VER)?
P.S. This finally leads to this code:
#if _MSC_VER && ! __clang__ && ! __INTEL_COMPILER
#pragma fenv_access (on) /* true MSVC here?? */
#else
#pragma STDC FENV_ACCESS ON
#endif
UPD. Patch for supporting the MS spelling of the pragma: https://reviews.llvm.org/D111440.
how to disable the default MSVC compatibility (so that Clang does not define _MSC_VER)?
Adding either -fms-compatibility-version=0 or -fmsc-version=0 switch should prevent _MSC_VER from being defined. This and a few other related VC++ compatibility options are documented on the Clang command line argument reference page under Target-independent compilation options.
-fms-compatibility, -fno-ms-compatibility
Enable full Microsoft Visual C++ compatibility
-fms-compatibility-version=<arg>
Dot-separated value representing the Microsoft compiler version number to report in _MSC_VER (0 = don’t define it (default))
-fms-extensions, -fno-ms-extensions
Accept some non-standard constructs supported by the Microsoft compiler
-fms-memptr-rep=<arg>
-fms-volatile
-fmsc-version=<arg>
Microsoft compiler version number to report in _MSC_VER (0 = don’t define it (default))
I'm trying to use GTKMM with a project which makes use of C++11 features.
The problem is that apparently C++11 deprecated some parts of the language, which GTKMM seems to be using.
Is there any way to get rid of those messages while keeping the useful compiler warnings for my code?
The compiler is GCC 5.2 on Linux. These are the notices I'm talking about:
In file included from /usr/include/glibmm-2.4/glibmm/wrap.h:23:0,
from /usr/include/glibmm-2.4/glibmm/containerhandle_shared.h:26,
from /usr/include/glibmm-2.4/glibmm/arrayhandle.h:23,
from /usr/include/glibmm-2.4/glibmm.h:91,
from /usr/include/gtkmm-3.0/gtkmm.h:87,
from test.cpp:1:
/usr/include/glibmm-2.4/glibmm/objectbase.h:215:13: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations]
static std::auto_ptr<Threads::Mutex> extra_object_base_data_mutex;
^
In file included from /usr/include/c++/5.2.0/memory:81:0,
from /usr/include/glibmm-2.4/glibmm/objectbase.h:32,
from /usr/include/glibmm-2.4/glibmm/wrap.h:23,
from /usr/include/glibmm-2.4/glibmm/containerhandle_shared.h:26,
from /usr/include/glibmm-2.4/glibmm/arrayhandle.h:23,
from /usr/include/glibmm-2.4/glibmm.h:91,
from /usr/include/gtkmm-3.0/gtkmm.h:87,
from test.cpp:1:
/usr/include/c++/5.2.0/bits/unique_ptr.h:49:28: note: declared here template<typename> class auto_ptr;
In case its something wrong with the compiler parameters, here's the CMakeLists ( was reused from an OpenCV project, please tell in case there is something wrong in the file):
cmake_minimum_required(VERSION 3.3.0 FATAL_ERROR)
list( APPEND CMAKE_CXX_FLAGS "-std=c++0x ${CMAKE_CXX_FLAGS} -g -ftest-coverage -fprofile-arcs -libs")
project( interface )
find_package(PkgConfig REQUIRED)
pkg_check_modules(GTKMM REQUIRED gtkmm-3.0)
include_directories(${GTKMM_INCLUDE_DIRS})
link_directories(${GTKMM_LIBRARY_DIRS})
add_definitions(${GTKMM_CFLAGS_OTHER})
add_executable( interface test.cpp )
target_link_libraries(interface ${GTKMM_LIBRARIES})
We fixed this in glibmm fairly recently:
https://bugzilla.gnome.org/show_bug.cgi?id=748630#c11
So the best way to fix it for your build is to update your glibmm and gtkmm versions, when you can.
Just a dirty hack (because probably the usage of auto_ptr inside GTKMM is questionable so you want to report a bug to GTKMM); you might use some diagnostic pragmas and replace #include <gtkmm.h> with
//untested code
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
#include <gtkmm.h>
#pragma GCC diagnostic warning "-Wdeprecated-declarations"
But auto_ptr is indeed deprecated in C++11 and I am not sure it mixes well with your C++11 standard library.
(Perhaps using Qt5 instead of GtkMM might be reasonable, since GtkMM might not be maintained for long, however it seems to know the issue; otherwise hope and perhaps contribute to improving GtkMM).
You probably should also use valgrind in your tests
I am using codelite IDE on windows,
in that when I was trying to compile socket program,
it shows:
warning: ignoring #pragma comment [-Wunknown-pragmas]
for include "WinSock2.h"
#pragma comment(lib,"ws2_32.lib")
First, some clarifications: codelite is not a compiler but an IDE
It uses toolchains (GNU, VC etc)
So when you are saying that "winsock library is not identified by codelite IDE" you actually means: the compiler warns about #pragma
Since you do not provide additional information here (such as the build log, the compiler you are using, codelite version etc) I will take a guess here and would say that you are mixingg the GNU toolchain with VC headers - try to use the WinAPI that comes with MinGW instead.
Looking at the WinSock2.h that comes with GCC for Windows I see only this pragma:
#pragma GCC system_header
Also, .lib libraries are meant to be used by VC but not by GCC
Eran
Which of these should I use to ignore a warning?
#pragma clang diagnostic ignored "-W<warning>"
#pragma GCC diagnostic ignored "-W<warning>"
Both seems to work for me, however which one is the correct to use?
Should I always use the one matching the compiler I'm using?
Generally, you should prefer #pragma GCC in cases where the pragma is GCC-specific, or is equally applicable to GCC, Clang, and other compilers which try to be GCC-compatible (such as ICC). Use #pragma clang in cases where the pragma is in some way Clang-specific (such as a diagnostic option which doesn't exist in GCC).
I am using the Windows Driver Kit (WinDDK 6001.18001) to build my userspace application rather than Visual Studio 2005. I am taking this approach because we also have to build driver components, so I'd prefer to have a single build environment to build everything. Microsoft itself uses this approach for several products.
This was working fine until I started using Boost 1.38.0. I'm not using C++ in the kernel mode components, just the userspace applications. In C++ code, it's natural to use the boost libraries. Unfortunately, the WDK doesn't agree.
The first error I noticed is that "#include <cstddef>" doesn't put ptrdiff_t in the std namespace, as seems required by Annex D. Working around this left several errors in boost\lambda\detail\operator_return_type_traits.hpp about error C2976: 'std::basic_string' : too few template arguments. It appears redundant with iostream.
Has anyone successfully gotten the combination of Boost, iostream, and the WDK to work together?
My sources file:
TARGETNAME=foobar
TARGETTYPE=PROGRAM
USE_MSVCRT = 1
USE_STL = 1
USE_ATL = 1
ATL_VER = 30
STL_VER = 70
USE_NATIVE_EH = 1
USE_IOSTREAM = 1
SUBSYSTEM_VERSION = 5.02
C_DEFINES = \
-D_MT \
-DWIN_32 \
-DWIN32 \
-D_WINDOWS \
-DNT \
-D_WIN32_DCOM \
-DUNICODE \
-D_UNICODE \
-D_ATL_NO_DEBUG_CRT # because we are using USE_MSVCRT=1
SOURCES=service.cpp
INCLUDES=\
$(BOOST_INC_PATH)
TARGETLIBS=\
$(SDK_LIB_PATH)\ole32.lib \
$(SDK_LIB_PATH)\oleaut32.lib \
$(SDK_LIB_PATH)\uuid.lib \
UMTYPE=console
UMBASE=0x400000
service.cpp:
#include <iostream>
#include <cstddef>
namespace std {
typedef ::ptrdiff_t ptrdiff_t; // DDK C++ workaround
}
#include <boost/lambda/lambda.hpp>
int __cdecl main() {
return 0;
}
Interesting question. Using STL as-is was a challenge in itself with the WDK. I have not ventured beyond. I can give this a try. Remember, the WDK has it's own compiler which is not the same as your VS2005/VS2008 complier (check the version numbers). It is highly likely there are a few bugs here and there.
Note, that USE_MSVCRT=1 and USE_STL=1 didn't gel well (at least for WDK 6001).
Boost may already include a work-around for your issues, but isn't applying it because it doesn't recognise the compiler you're using (probably because drivers rarely use boost).
Try examining (and possibly editing) boost/config/select_compiler_config.hpp and boost/config/compiler/visualc.hpp to make sure the compiler workarounds for MSVC are enabled.
I would suggest going different way, i.e compiling driver from VS200.x using this (ddkbuild) nice tool.
Being myself a command line person and using makefiles everywhere possible, i find build utility not useful for complex project.There is tons of limitation within MS build utility and i would recommend using VS environment for compiling your project.
I'm not sure if there is a howto in the ddkbuild, but it's straight forward to integrate ddkbuild.bat into VS custom build option.