[CMake] Unexpected use of "ld" on Windows

Andreas Pakulat apaku at gmx.de
Wed Feb 11 10:30:21 EST 2015


Hi,

On Wed, Feb 11, 2015 at 3:16 PM, Arjen Markus <Arjen.Markus at deltares.nl>
wrote:

> Hello,
>
> I am trying to build the Fortran interface to NetCDF4 on Windows, using
> the Intel Fortran compiler and "Nmake Makefiles" as the generator (see
> http://www.unidata.ucar.edu/downloads/netcdf/index.jsp).
>
> I had some trouble getting the first part to build, but that is solved
> (small issues with the code). The second part, which is supposed to build a
> C library that can be called from Fortran, presents a more serious problem:
> for some reason CMake picks parts of another toolchain to build this:
>
> The Makefile contains these lines to compile the sources:
>         cd D:\netcdf\netcdf-build-fortran\libsrc
>         C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe  @<<
>  /nologo $(C_FLAGS) $(C_DEFINES)
> /FoCMakeFiles\ncfortran.dir\fort-attio.c.obj
> /FdD:\netcdf\netcdf-build-fortran\libsrc\ncfortran.pdb -c
> D:\netcdf\netcdf-fortran-4.4.1\libsrc\fort-attio.c
>
> But to build the library it contains:
>
> libsrc\ncfortran.dll: d:\netcdf\netcdf-build\liblib\netcdf.lib
> libsrc\ncfortran.dll: libsrc\CMakeFiles\ncfortran.dir\objects1.rsp
>         @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --red
> --bold "Linking C shared library ncfortran.dll"
>         cd D:\netcdf\netcdf-build-fortran\libsrc
>         d:\CMake2.8.10.2\bin\cmake.exe -E vs_link_dll
> C:\PROGRA~2\HASKEL~1\201320~1.0\mingw\bin\ld.exe /nologo
> @CMakeFiles\ncfortran.dir\objects1.rsp @<<
>  /out:ncfortran.dll /implib:ncfortran.lib
> /pdb:D:\netcdf\netcdf-build-fortran\libsrc\ncfortran.pdb /dll /version:0.0
> /STACK:10000000 /INCREMENTAL:YES /machine:x64  /debug
> d:\netcdf\netcdf-build\liblib\netcdf.lib kernel32.lib user32.lib gdi32.lib
> winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib
> advapi32.lib
> <<
>
> As you can see, it has picked up a linker (ld.exe) belonging to a
> completely different compiler/package for this step.
>
> I have no idea where this is coming from and how to fix this. Does anyone
> have any suggestions?


Seeing the path to that ld.exe I'm reminded of a problem a colleague
recently had. He has Haskell installed on his system and either haskell
itself or some haskell library came with mingw and his PATH ended up
including the bin dir of that mingw installation. Even if that entry is
after the VS compiler CMake apparently chooses to pick up the mingw
toolchain (or parts of it), so one has to make sure that there's no MinGW
compiler or linker or other part of the toolchain in any of the directories
in PATH. At least thats how he resolved the issue.

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150211/b264547f/attachment.html>


More information about the CMake mailing list