View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0013791CMakeCMakepublic2012-12-13 15:552015-03-02 08:57
Reporterjujjyl 
Assigned ToBrad King 
PrioritynoneSeverityfeatureReproducibilityalways
StatusclosedResolutionfixed 
PlatformMicrosoftOSWindowsOS Version8
Product VersionCMake 2.8.10.1 
Target VersionCMake 3.1Fixed in VersionCMake 3.1 
Summary0013791: CMake does not support generating projects for Windows Phone 8.
DescriptionI have not found an option to generate solution/project files for "Visual Studio 2012 Express for Windows Phone 8". The project files to target Windows Phone 8 differ somewhat of those from Windows Desktop 8 and Windows RT 8. I assume that since Windows RT 8 option doesn't yet exist, Windows Phone 8 targeting does not exist either?

Marking down this issue to discuss required additions towards supporting this.
Additional InformationI went through and compared .vcxproj files for Windows Phone 8 and Windows RT 8. The project file generated for "Visual Studio 11" requires at least the following modifications to allow Windows Phone 8 deployment:

 - Must add elements <RootNamespace>project name?</RootNamespace> <DefaultLanguage>en-US</DefaultLanguage> <MinimumVisualStudioVersion>11.0</MinimumVisualStudioVersion> <XapOutputs>true</XapOutputs> <XapFilename>Project_Name_$(Configuration)_$(Platform).xap</XapFilename> <WinMDAssembly>true</WinMDAssembly> to the <PropertyGroup Label="Globals"> section of the generated .vcxproj file.

 - Must replace <PlatformToolset>v110</PlatformToolset> with <PlatformToolset>v110_wp80</PlatformToolset>

 - Must remove default-added linking to the following libraries: kernel32.lib;user32.lib;gdi32.lib;winspool.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;comdlg32.lib;advapi32.lib;
 
 - Must add a line <Import Project="$(MSBuildExtensionsPath)\Microsoft\WindowsPhone\v$(TargetPlatformVersion)\Microsoft.Cpp.WindowsPhone.$(TargetPlatformVersion).targets" /> before the section <ImportGroup Label="ExtensionTargets"> in the .vcxproj file.

 - Must add a reference to assembly 'Platform.winmd' to the compiler options. The command line for this is "/FU Platform.winmd"

Note that the <AppContainerApplication>true</AppContainerApplication> element that exists for Win8RT project files is not present for Win8 Phone project files.

I hope this list is useful for someone that might be capable in implementing support for this in cmake. A good way to compare is to open VS2012 and create a new project from the native C++ Direct3D application template, which exists for both VS2012 Express for Windows 8 and V2012 Express for Windows Phone 8. Comparing the .vcxproj files gives a good diff of the changes.
TagsNo tags attached.
Attached Filespatch file icon a5c3f059+0001-VS-Do-not-link-Windows-runtime-libraries-for-ARM-137.patch [^] (1,345 bytes) 2013-12-04 09:19 [Show Content]
patch file icon a5c3f059+0001-VS-Do-not-link-Windows-runtime-libraries-for-ARM-13791-v2.patch [^] (1,469 bytes) 2013-12-05 09:46 [Show Content]
patch file icon a5c3f059+0001-VS-Do-not-link-Windows-runtime-libs-for-VS-ARM-gener.patch [^] (1,401 bytes) 2013-12-19 14:14 [Show Content]

 Relationships
related to 0013749closed Cannot target Windows 8 RT from CMake without workarounds. 
related to 0013511closedBrad King Add support for WinRT platforms and "metro" apps 
has duplicate 0014598closedPatrick R. Gansterer CMake 2.8.12 with "Visual Studio 11 ARM" generator fails to compile simple test program, 2.8.11 works 

  Notes
(0031917)
Brad King (manager)
2012-12-18 08:03

Resolving as duplicate of 0013511.
(0031918)
jujjyl (reporter)
2012-12-18 08:20

Hi, sorry for reopening, but apparently it is the only way to comment on an issue (or I did not find the proper button).

I don't think supporting Windows Phone 8 is a duplicate of supporting Windows 8 RT or Windows 8 RT for ARM. They have separate installable Visual Studio executables, separate project files (that differ by quite a lot) and separate compilers, so the support won't come automatically by implementing just support for one.

In summary, supporting WinPhone8, Win8RT for X86 and Win8RT for ARM can/could be done orthogonally as separate tasks, since they're separate toolchains.
(0031920)
Brad King (manager)
2012-12-18 09:43

Re 0013791:0031918: Okay, thanks for the clarification.
(0033543)
Paul Annetts (reporter)
2013-07-15 18:38

I'm working on a patch for initial WP8 support (starting with static libraries).
(0034613)
Moshe Rubin (reporter)
2013-11-30 13:53

Considering Brad King's comments in bug 0014598, I would like to propose the following fix. I have made the fix on my system and can now generate a VS solution file for cross-compiling a Windows Phone ARM binary target on a Windows 8 host.

The fix is in the "Modules\Platform\Windows-MSVC.cmake" file, starting on line 160:

<snippet>
if(MSVC_VERSION GREATER 1310)
  set(_RTC1 "/RTC1")
  set(_FLAGS_CXX " /GR /EHsc")
  # (30 Nov 2013): The following "if" added to prevent including windows system libraries if using an ARM generator
  if(NOT "${CMAKE_GENERATOR}" MATCHES "ARM")
      set(CMAKE_C_STANDARD_LIBRARIES_INIT "kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib")
  endif()
else()
  set(_RTC1 "/GZ")
  set(_FLAGS_CXX " /GR /GX")
  # (30 Nov 2013): The following "if" added to prevent including windows system libraries if using an ARM generator
  if(NOT "${CMAKE_GENERATOR}" MATCHES "ARM")
      set(CMAKE_C_STANDARD_LIBRARIES_INIT "kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib")
  endif()
endif()
</snippet>

The fix consists of adding an "if" statement to prevent adding the windows system libraries when using an ARM-related generator under Windows. The rational is that under Windows, compiling for ARM automatically precludes any Win32-related anything, rendering kernel32.lib etc. irrelevant.

Running my test emits the following CMake output:

<snippet>
--------------------------------------------
Using CMake 2.8.12-FIXED
--------------------------------------------
-- The C compiler identification is MSVC 17.0.50727.1
-- The CXX compiler identification is MSVC 17.0.50727.1
-- Check for working C compiler using: Visual Studio 11 ARM
-- Check for working C compiler using: Visual Studio 11 ARM -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 11 ARM
-- Check for working CXX compiler using: Visual Studio 11 ARM -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/junk/TestProjects/CMakeArmRegression/Generated-2.8.12-FIXED
</snippet>

Would this fix be acceptable to the CMake team?
(0034675)
Brad King (manager)
2013-12-02 10:35

Re 0013791:0034613: The proposed solution is along the right lines and may be correct. However I'd like to determine if there is a better way to detect the ARM case which can work when using other generators. In the WinCE code path above the code in question we check the MSVC_${lang}_ARCHITECTURE_ID detected when determining the compiler id to look for ARM platforms. Would something similar work here?
(0034687)
Moshe Rubin (reporter)
2013-12-03 03:43

Brad, I would like to test your idea, but am encountering what seems to be an undesired caching issue.

My version of CMake 2.8.12 is installed in the directory "C:\Program Files (x86)\CMake 2.8.12".

I attempted to modify the file "C:\Program Files (x86)\CMake 2.8.12\share\cmake-2.8\Modules\Platform\Windows-MSVC.cmake" by inserting some debugging statements at line 126:

<snippet>
[123] # default to Debug builds
[124] set(CMAKE_BUILD_TYPE_INIT Debug)
[125]
[126] #DEBUG-START
[127] message (STATUS "${lang}")
[128] message (STATUS "${MSVC_${lang}_ARCHITECTURE_ID}")
[129] #DEBUG-END
[130]
[131] if(WINCE)
[132] foreach(lang C CXX)
</snippet>

After deleting the previous Cmake-generated output folder, I reran my test case:

"C:\Program Files (x86)\CMake 2.8.12\bin\cmake.exe" ..\ -G "Visual Studio 11 ARM" -T "v110_wp80" --trace >..\foo 2>&1

Here are the relevant traced lines:

<snippet>
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(119): if(${MSVC_VERSION} GREATER 1599 )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(120): set(MSVC_INCREMENTAL_DEFAULT ON )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(124): set(CMAKE_BUILD_TYPE_INIT Debug )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(126): if(WINCE )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(157): else()
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(158): if(MSVC_VERSION GREATER 1310 )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(159): set(_RTC1 /RTC1 )
C:/Program Files (x86)/CMake 2.8.12/share/cmake-2.8/Modules/Platform/Windows-MSVC.cmake(160): set(_FLAGS_CXX /GR /EHsc )
</snippet>

There are two strange things here:

(a) I expected to see the two message(...) outputs from lines 127-128 in the above trace, but did not.

(b) The statement "if(WINCE)", which used to be on line 126, was bumped to line 131 in the altered Windows-MSVC.cmake file. In the trace, however, it is still being read from line 126! It is as if CMake is opening the modified file (as evidenced by the path in the trace line and by checking with MS's ProcMon utility) but is reading the previous contents from some cache file.

Can you please tell me how I can make a change to the Windows-MSVC.cmake file that is picked up correctly and immediately by CMake? Can you also verify that I do not need to recompile the entire cmake.exe project for the *.cmake changes to be recognized?
(0034690)
Brad King (manager)
2013-12-03 09:03
edited on: 2013-12-03 09:04

Re 0013791:0034687: You are probably getting tripped up by the Windows Virtual Store feature:

http://blogs.msdn.com/b/chinmay_palei/archive/2011/01/16/windows-7-application-compatibility-issues-fix-centre.aspx [^]

Editing the file as an administrator should work. No you don't need to recompile for *.cmake changes.

(0034704)
Moshe Rubin (reporter)
2013-12-04 04:54

Brad,

First, you were spot on about being tripped up by the Windows VirtualStore feature. I can now modify the Windows-MSVC.cmake file and see the changes immediately -- thanks! <g>

Second, I inserted message() statements in Windows-MSVC.cmake to print the values of ${MSVC_${lang}_ARCHITECTURE_ID} and other variables with the aim of using it to determine whether we should include Win32 system libraries or not:

<code>
#DEBUG-START
message (STATUS "\${lang} = \"${lang}\"")
message (STATUS "\${MSVC_\${lang}_ARCHITECTURE_ID} => " "\${MSVC_${lang}_ARCHITECTURE_ID}")
message (STATUS "\${MSVC_${lang}_ARCHITECTURE_ID} = \"${MSVC_${lang}_ARCHITECTURE_ID}\"")
message (STATUS "\${MSVC_C_ARCHITECTURE_ID} = \"${MSVC_C_ARCHITECTURE_ID}\"")
message (STATUS "\${MSVC_CXX_ARCHITECTURE_ID} = \"${MSVC_CXX_ARCHITECTURE_ID}\"")
#DEBUG-END

if(WINCE)
  foreach(lang C CXX)
    set(_MSVC_${lang}_ARCHITECTURE_FAMILY "${MSVC_${lang}_ARCHITECTURE_ID}")
    if(_MSVC_${lang}_ARCHITECTURE_FAMILY STREQUAL "THUMB")
      set(_MSVC_${lang}_ARCHITECTURE_FAMILY "ARM")
    elseif(_MSVC_${lang}_ARCHITECTURE_FAMILY MATCHES "^SH")
      set(_MSVC_${lang}_ARCHITECTURE_FAMILY "SHx")
    endif()
    string(TOUPPER "${_MSVC_${lang}_ARCHITECTURE_FAMILY}" _MSVC_${lang}_ARCHITECTURE_FAMILY_UPPER)
  endforeach()
  . . .
</code>

Here's the build output:

<build-output>
-- The C compiler identification is MSVC 17.0.50727.1
-- The CXX compiler identification is MSVC 17.0.50727.1
-- ${lang} = ""
-- ${MSVC_${lang}_ARCHITECTURE_ID} => ${MSVC__ARCHITECTURE_ID}
-- ${MSVC__ARCHITECTURE_ID} = ""
-- ${MSVC_C_ARCHITECTURE_ID} = "ARM"
-- ${MSVC_CXX_ARCHITECTURE_ID} = "ARM"
-- Check for working C compiler using: Visual Studio 11 ARM
-- Check for working C compiler using: Visual Studio 11 ARM -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 11 ARM
-- Check for working CXX compiler using: Visual Studio 11 ARM -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/junk/TestProjects/CMakeArmRegression/Generated-2.8.12
</build-output>

This shows that ${lang} is the empty string (""), thereby preventing accessing ${MSVC_${lang}_ARCHITECTURE_ID} correctly. The variables ${MSVC_C_ARCHITECTURE_ID} and ${MSVC_CXX_ARCHITECTURE_ID}, however, are alive and kicking and can be used for our fix.

So the question is why is ${lang} not set. The only two places where <lang> is set is in:

<snippet>
Searching for: set(lang
CMake 2.8.12\share\cmake-2.8\Modules\FortranCInterface.cmake(227): set(lang C)
CMake 2.8.12\share\cmake-2.8\Modules\FortranCInterface.cmake(234): set(lang CXX)
Found 2 occurrence(s) in 1 file(s)
</snippet>

My test program has a single main.c file, so I would expect ${lang} to be set to "C". Here is my CMakeLists.txt file:

<code>
cmake_minimum_required(VERSION 2.6.0)
project(MyTest)
add_library(foo STATIC main.c)
</code>

Where then is ${lang} being set? Can we check either the C or the CXX form of variable for a value of "ARM"? Could the source file be in a different language (e.g., C#)? How would you like to implement the fix?
(0034705)
Brad King (manager)
2013-12-04 07:59

Re 0013791:0034704: The ${lang} is not a widely-visible variable. It is internal to Windows-MSVC.cmake. It is the loop parameter in the WINCE block and later the argument name of the __windows_compiler_msvc macro. The latter is invoked from Windows-MSVC-(C|CXX).cmake with the corresponding language name.
(0034708)
Moshe Rubin (reporter)
2013-12-04 08:53

Duh <g>.

In this case we can certainly check ${MSVC_${lang}_ARCHITECTURE_ID} for "ARM". I'd like to suggest the following code (modify it any way you see fit):

<code>
if(WINCE)
  . . .
else()
  set(isARM "FALSE")
  foreach(lang C CXX)
    if(${MSVC_${lang}_ARCHITECTURE_ID} MATCHES "ARM")
      set(isARM "TRUE")
      break()
    endif()
  endforeach()
  
  if(NOT ${isArm})
      set(_PLATFORM_DEFINES "/DWIN32")
  endif()
  
  if(MSVC_VERSION GREATER 1310)
    set(_RTC1 "/RTC1")
    set(_FLAGS_CXX " /GR /EHsc")
    if(NOT ${isArm})
        set(CMAKE_C_STANDARD_LIBRARIES_INIT "kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib")
    endif()
  else()
    set(_RTC1 "/GZ")
    set(_FLAGS_CXX " /GR /GX")
    if(NOT ${isArm})
        set(CMAKE_C_STANDARD_LIBRARIES_INIT "kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib")
    endif()
  endif()

  if(MSVC_VERSION LESS 1310)
    set(_FLAGS_C " /Zm1000${_FLAGS_C}")
    set(_FLAGS_CXX " /Zm1000${_FLAGS_CXX}")
  endif()
endif()
</code>

Many thanks for holding my hand while investigating this problem <g>. It's been an honor contributing something back to the CMake project.
(0034709)
Brad King (manager)
2013-12-04 09:24

Re 0013791:0034708: Thanks. Try attached "a5c3f059+0001-VS-Do-not-link-Windows-runtime-libraries-for-ARM-137.patch" which does something similar to your change. Note I also check for the THUMB and SH architectures (is that correct?).

Note that this commit:

 VS: Detect MSVC compiler id on ARM toolchain
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4c04652 [^]

between 2.8.11 and 2.8.12 was likely the reason CMake started to detect the compiler id and load this file, as discussed in 0014598.

I'm not familiar with ARM development myself. I wonder why the author of that commit did not hit problems with linking of the Windows runtime libraries too. Is it only for specific platform toolsets (cmake -T option) that the Windows libraries should be excluded? Is it only for specific architectures?
(0034719)
Moshe Rubin (reporter)
2013-12-05 09:31
edited on: 2013-12-05 09:38

Re 0013791:0034709: As far as I can ascertain, the THUMB and SHx processors are not relevant for Windows Phone, only for Windows CE.

Regarding the commit ("VS: Detect MSVC compiler id on ARM toolchain"), I checked the head version of CMakeDetermineCompilerId.cmake (http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineCompilerId.cmake;hb=HEAD [^]) but could not see the lines committed. The head version shows:

<code>
136 if("${id_platform}" STREQUAL "Itanium")
137 set(id_platform ia64)
138 endif()
</code>

The commit shows the lines (http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineCompilerId.cmake;hb=e4c046521f1da9cee44833d88320d7551719059b [^]):

<code>
129 if("${id_arch}" STREQUAL "x64")
130 set(id_machine_10 MachineX64)
131 elseif("${id_arch}" STREQUAL "Itanium")
132 set(id_machine_10 MachineIA64)
133 set(id_arch ia64)
134 elseif("${id_arch}" STREQUAL "ARM")
135 set(id_machine_10 MachineARM)
136 else()
137 set(id_machine_6 x86)
138 set(id_machine_10 MachineX86)
139 endif()
</code>

Why are they so different?

I cannot explain why the committer did not experience the problems I'm experiencing. Removing the -T platform toolset from the command line causes the build to fail. I believe that using an ARM generator implicitly implies that no Win32 system DLLs will be used at all.

(0034720)
Brad King (manager)
2013-12-05 09:48

Re 0013791:0034719: Later another commit dropped use of the target machine from compiler id detection altogether:

 VS10: Do not set the TargetMachine when detecting the compiler
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=60e568cf [^]

IIUC this also would have fixed compiler id detection under ARM by itself.

If THUMB and SHx are only for WinCE then we need only to check for "ARM" as you originally suggested.
Please try "a5c3f059+0001-VS-Do-not-link-Windows-runtime-libraries-for-ARM-13791-v2.patch".
(0034722)
Patrick R. Gansterer (developer)
2013-12-05 11:11

Do Windows Phone 8 support X86 architecture? If yes: How do you ensure that the system libraries do not get linked for x86 phones?
At the moment this seams to get into an direction which makes the MSVC stuff even harder to understand if we mix CPU architecture with system API. :-(
What about detecting the system API from the target platform (?) and introduce a new variable like WINRT, we can check then instead of abusing the CPU architecture for that?
(0034723)
Brad King (manager)
2013-12-05 11:17

Re 0013791:0034722: Thanks Patrick. That makes sense to me but I'm not familiar with any embedded target platforms with MSVC tools so I'm fully dependent on contributors to work this out. What do others think?
(0034725)
Patrick R. Gansterer (developer)
2013-12-05 11:23

Re 0013791:0034723: I'm familiar with WinCE as you might know, but haven't done anything with the other "embedded" platforms of MSVC for now. I'd like to dive into it and maybe implement it, but I'm short of time at the moment. :-(
(0034828)
Brad King (manager)
2013-12-19 14:15

Since none of us seems to understand the relationship among WinCE, WinRT, Windows Phone 8, ARM, etc. the simplest patch to solve the immediate issue is something like "a5c3f059+0001-VS-Do-not-link-Windows-runtime-libs-for-VS-ARM-gener.patch" that just drops the system libs for the VS ARM generator. Please try it out.
(0036786)
Brad King (manager)
2014-09-12 09:41

The development version of CMake now supports running with

 cmake .. -G "Visual Studio 11 2012" -DCMAKE_SYSTEM_NAME=WindowsPhone -DCMAKE_SYSTEM_VERSION=8.0

or

 cmake .. -G "Visual Studio 12 2013" -DCMAKE_SYSTEM_NAME=WindowsPhone -DCMAKE_SYSTEM_VERSION=8.1

to generate project files for Windows Phone. Nightly binaries are available here:

 http://www.cmake.org/files/dev/?C=M;O=D [^]

If you try it, please bring feedback to the cmake-developers mailing list:

 http://www.cmake.org/mailman/listinfo/cmake-developers [^]
(0038117)
Robert Maynard (manager)
2015-03-02 08:57

Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2012-12-13 15:55 jujjyl New Issue
2012-12-13 16:15 Brad King Relationship added related to 0013749
2012-12-18 08:02 Brad King Relationship added duplicate of 0013511
2012-12-18 08:03 Brad King Note Added: 0031917
2012-12-18 08:03 Brad King Status new => resolved
2012-12-18 08:03 Brad King Resolution open => duplicate
2012-12-18 08:20 jujjyl Note Added: 0031918
2012-12-18 08:20 jujjyl Status resolved => feedback
2012-12-18 08:20 jujjyl Resolution duplicate => reopened
2012-12-18 09:43 Brad King Relationship replaced related to 0013511
2012-12-18 09:43 Brad King Note Added: 0031920
2012-12-18 09:43 Brad King Priority normal => none
2012-12-18 09:43 Brad King Status feedback => backlog
2012-12-18 09:43 Brad King Resolution reopened => open
2013-07-15 18:38 Paul Annetts Note Added: 0033543
2013-11-28 06:33 Patrick R. Gansterer Relationship added has duplicate 0014598
2013-11-30 13:53 Moshe Rubin Note Added: 0034613
2013-12-02 10:35 Brad King Note Added: 0034675
2013-12-03 03:43 Moshe Rubin Note Added: 0034687
2013-12-03 09:03 Brad King Note Added: 0034690
2013-12-03 09:04 Brad King Note Edited: 0034690
2013-12-04 04:54 Moshe Rubin Note Added: 0034704
2013-12-04 07:59 Brad King Note Added: 0034705
2013-12-04 08:53 Moshe Rubin Note Added: 0034708
2013-12-04 09:19 Brad King File Added: a5c3f059+0001-VS-Do-not-link-Windows-runtime-libraries-for-ARM-137.patch
2013-12-04 09:24 Brad King Note Added: 0034709
2013-12-05 09:31 Moshe Rubin Note Added: 0034719
2013-12-05 09:34 Moshe Rubin Note Edited: 0034719
2013-12-05 09:36 Moshe Rubin Note Edited: 0034719
2013-12-05 09:38 Moshe Rubin Note Edited: 0034719
2013-12-05 09:46 Brad King File Added: a5c3f059+0001-VS-Do-not-link-Windows-runtime-libraries-for-ARM-13791-v2.patch
2013-12-05 09:48 Brad King Note Added: 0034720
2013-12-05 11:11 Patrick R. Gansterer Note Added: 0034722
2013-12-05 11:17 Brad King Note Added: 0034723
2013-12-05 11:23 Patrick R. Gansterer Note Added: 0034725
2013-12-19 14:14 Brad King File Added: a5c3f059+0001-VS-Do-not-link-Windows-runtime-libs-for-VS-ARM-gener.patch
2013-12-19 14:15 Brad King Note Added: 0034828
2014-09-12 09:41 Brad King Note Added: 0036786
2014-09-12 09:41 Brad King Assigned To => Brad King
2014-09-12 09:41 Brad King Status backlog => resolved
2014-09-12 09:41 Brad King Resolution open => fixed
2014-09-12 09:41 Brad King Fixed in Version => CMake 3.1
2014-09-12 09:41 Brad King Target Version => CMake 3.1
2015-03-02 08:57 Robert Maynard Note Added: 0038117
2015-03-02 08:57 Robert Maynard Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team