On 2014-04-08 17:28+0200 Thorsten Behrens wrote:
> Hi Alan!
>
>>> Thorsten (or anybody else here) if you do have access to a D compiler
>>> on Windows and want to look further into D language support on that
>>> platform, I would encourage you to experiment with Windows-only
>>> changes to our D language support files (using -DENABLE_d=ON), but
>>> otherwise I don't think it is possible to figure out what changes are
>>> needed in those files for the Windows case.
>>
>> I will give this a try today. According to the CMakeDInformation two
>> compilers seem of interest, DMD and GDC. Because the erroneous linker
>> flag is in the non-GDC branch, I will do my tests using DMD.
>
> I installed DMD 2.065.0 and did the following tests using the latest
> version of PLplot (Rev. 13100) with just one exception. This exception is
> a change in FindwxWdigets.cmake. I removed the obviously unused libraries
> winmm.lib and wsock32.lib
>
> 1) cmake -G "Visual Studio 10" <path-to-plplot-src>
> This was just to test that D will not be enabled (due to -DENABLE_d=OFF
> being the default setting) although it is installed on the system. This
> build was fine. No tests have been installed, wxWidgets has been found and
> all projects could be compiled with VS 10.
>
> 2) cmake -G "Visual Studio 10" -DENABLE_d=ON -DENABLE_wxwidgets=OFF
> <path-to-plplot-src>
> This was to test whether just D itself will be recognized. I disabled
> wxWidgets here to suppress any might-be interference between D and
> wxWidgets.
>
> I wasn't able to complete this test. All the day I fiddled around with
> CMake, but whatever I changed within
> \cmake\modules\language_support\cmake\CMakeD*.cmake CMake never recognized
> a working D compiler.
>
> I have no problems compiling, linking and running any D example programs
> from the net. Thus, D itself is correctly installed and working.
>
> Whenever using CMake, however, it fails in
> \cmake\modules\language_support.cmake when trying to compile a simple test
> program. This test program is defined inline in CMakeTestDCompiler.cmake
> (lines 24-25). Copying this into a file and compiling it directly from the
> D command shell works like a charm. So, the test program itself is also OK.
>
> CMake complains as follows:
> ---snip---
> -- The C compiler identification is MSVC 16.0.40219.1
> -- Check for working C compiler using: Visual Studio 10
> -- Check for working C compiler using: Visual Studio 10 -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- CMAKE_GENERATOR = Visual Studio 10
> -- D Compiler Install Prefix (use D_PATH env var to override):
> F:/D/dmd2/windows
> -- Check for working D compiler: F:/D/dmd2/windows/bin/dmd.exe
> -- Check for working D compiler: F:/D/dmd2/windows/bin/dmd.exe -- broken
>
> CMake Error at
> I:/PLplot/PLplot-5.10.0/cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:52
> (MESSAGE):
> The D compiler "F:/D/dmd2/windows/bin/dmd.exe" is not able to compile a
> simple test program.
>
> It fails with the following output:
>
> Change Dir: I:/PLplot/build/language_tests/D/CMakeFiles/CMakeTmp
>
> Run Build
> Command:C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
> cmTryCompileExec2509696440.vcxproj /p:Configuration=Debug
> /p:VisualStudioVersion=10.0
>
> Microsoft (R)-Buildmodul, Version 4.0.30319.18408
>
> [Microsoft .NET Framework, Version 4.0.30319.18444]
>
> Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.
>
> Der Buildvorgang wurde am 08.04.2014 16:51:37 gestartet.
>
> Projekt
>
> "I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj"
> auf Knoten "1" (Standardziele).
>
> PrepareForBuild:
>
> Das Verzeichnis "cmTryCompileExec2509696440.dir\Debug\" wird erstellt.
> Das Verzeichnis
> "I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\Debug\" wird
> erstellt.
>
> InitializeBuildStatus:
>
>
> "cmTryCompileExec2509696440.dir\Debug\cmTryCompileExec2509696440.unsuccessfulbuild"
> wird erstellt, da "AlwaysCreate" angegeben wurde.
>
> ManifestResourceCompile:
>
> C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\rc.exe /nologo
> /fo"cmTryCompileExec2509696440.dir\Debug\cmTryCompileExec2509696440.exe.embed.manifest.res"
> cmTryCompileExec2509696440.dir\Debug\cmTryCompileExec2509696440_manifest.rc
>
> Link:
>
> F:\Microsoft Visual Studio 10.0\VC\bin\link.exe /ERRORREPORT:QUEUE
> /OUT:"I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec2509696440.exe"
> /INCREMENTAL /NOLOGO /MANIFEST
> /ManifestFile:"cmTryCompileExec2509696440.dir\Debug\cmTryCompileExec2509696440.exe.intermediate.manifest"
> /MANIFESTUAC:"level='asInvoker' uiAccess='false'"
> /PDB:"I:/PLplot/build/language_tests/D/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec2509696440.pdb"
> /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT
> /IMPLIB:"I:/PLplot/build/language_tests/D/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec2509696440.lib"
> /MACHINE:X86
> cmTryCompileExec2509696440.dir\Debug\cmTryCompileExec2509696440.exe.embed.manifest.res
>
> LINK : error LNK2001: Nicht aufgelöstes externes Symbol
> "_mainCRTStartup".
>
> [I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj]
>
>
> I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec2509696440.exe
> : fatal error LNK1120: 1 nicht aufgelöste externe Verweise.
>
> [I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj]
>
> Die Erstellung des Projekts
>
> "I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj"
> ist abgeschlossen (Standardziele) -- FEHLER.
>
> Fehler beim Buildvorgang.
>
>
> "I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj"
> (Standardziel) (1) ->
> (Link Ziel) ->
>
> LINK : error LNK2001: Nicht aufgelöstes externes Symbol
> "_mainCRTStartup".
> [I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj]
>
>
> I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec2509696440.exe
> : fatal error LNK1120: 1 nicht aufgelöste externe Verweise.
> [I:\PLplot\build\language_tests\D\CMakeFiles\CMakeTmp\cmTryCompileExec2509696440.vcxproj]
>
> 0 Warnung(en)
> 2 Fehler
>
> Verstrichene Zeit 00:00:00.69
>
> CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
> CMakeLists.txt:33 (enable_language)
> ---snap---
>
> According to the CMake FAQ I should use the WIN32 argument to
> ADD_EXECUTABLE. This, however, is not possible, as enable_language
> generates its own CMake.txt file on the fly (that obviously contains some
> ADD_EXECUTABLE line). I then tried to set several CMake variables (all I
> found in CMake's online documentation that may have some influence on the
> linker) just before the TRY_COMPILE in line 29 of
> CMakeTestDCompiler.cmake, but all to no avail.
>
> I noticed a similar error when trying to enable Fortran and Ada (but
> normally I have these disabled - I wanted to try Ada at some later stage),
> so this may be points to a general problem using other languages under
> Windows and using Visual Studio generators.
>
> Has anyone any ideas on this topic?
Greatly simplify your test case to make it easier for others to test
the problem and to remove most of PLplot from the question. To do
that create a new source tree containing just the single file
CMakeLists.txt and the language support tree
cmake/modules/language_support/cmake (including all subdirectories) copied
from PLplot.
That CMakeLists.txt file should contain the following:
cmake_minimum_required(VERSION 2.8.12.2 FATAL_ERROR)
project(test_d D)
# Get access to D language support
set(CMAKE_MODULE_PATH
${PROJECT_SOURCE_DIR}/cmake/modules/language_support/cmake)
Since gdc is the debugged D compiler on the Linux side, I would first
try the above simple test case for that compiler rather than dmd.
I would also use the nmake generator since that is likely more free of
bugs than the complicated generator you are using.
Another important cmake debugging tip when try compiles are going
wrong (from the cmake man page):
--debug-trycompile
Do not delete the try_compile build tree. Only
useful on one try_compile at a time.
Do not delete the files and directories created for
try_compile calls. This is useful in debugging failed
try_compiles. It
may however change the results of the try-compiles as
old junk from a previous try-compile may cause a different test
to
either pass or fail incorrectly. This option is best
used for one try-compile at a time, and only when debugging.
This should help you figure out exactly what command-line command is
going wrong for the simple try compile case, and thus supply the
result for whatever change you make to the files in
cmake/modules/language_support/cmake.
If these tips help you to figure out bug fixes for the D language
support on Windows platforms, I would be very happy to apply your
patch.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
