conda-forge / vc-feedstock Goto Github PK

View Code? Open in Web Editor NEW

4.0 4.0 21.0 239 KB

A conda-smithy repository for vc.

License: BSD 3-Clause "New" or "Revised" License

Batchfile 31.67% Python 68.33%

vc-feedstock's People

Contributors

Stargazers

Watchers

Forkers

pelson conda-forge-admin jakirkham-feedstocks regro-cf-autotick-bot isuruf xhochy nowster dhirschfeld conda-forge-linter h-vetinari gabm traversaro gamsystematic heavytony2 mariusvniekerk wolfv mjcarroll anaconda-community jdblischak

vc-feedstock's Issues

remove 19.16.27038 which has an incorrect version

I read the conda-forge documentation and could not find the solution for my problem there.

Issue:

Environment (conda list):

$ conda list

Details about conda and system ( conda info ):

$ conda info

BUG: builds for non-latest minor versions broken? use vsdownload.py utility?

While working on an unrelated change in #56, CI started failing with

C:\Program Files\Microsoft Visual Studio\2022\Enterprise>CALL "VC\Auxiliary\Build\vcvars64.bat" -vcvars_ver=14.28 10.0.22621.0 
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.5.4
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[ERROR:vcvars.bat] Toolset directory for version '14.28' was not found.
[ERROR:VsDevCmd.bat] *** VsDevCmd.bat encountered errors. Environment may be incomplete and/or incorrect. ***
[ERROR:VsDevCmd.bat] In an uninitialized command prompt, please 'set VSCMD_DEBUG=[value]' and then re-run
[ERROR:VsDevCmd.bat] vsdevcmd.bat [args] for additional details.
[ERROR:VsDevCmd.bat] Where [value] is:
[ERROR:VsDevCmd.bat]    1 : basic debug logging
[ERROR:VsDevCmd.bat]    2 : detailed debug logging
[ERROR:VsDevCmd.bat]    3 : trace level logging. Redirection of output to a file when using this level is recommended.
[ERROR:VsDevCmd.bat] Example: set VSCMD_DEBUG=3
[ERROR:VsDevCmd.bat]          vsdevcmd.bat > vsdevcmd.trace.txt 2>&1
Tests failed for vs2019_win-64-19.28.29325-hed2d97d_11.conda - moving package to D:\bld\broken

As it turns out, this was pre-existing (see e.g. CII of another PR, resp. also for the last merge to main), it just didn't fail the build.

At first I thought this had something to do with the new artefact naming as of vs2022, i.e.

Microsoft.VisualStudio.Component.VC.14.29.16.11.x86.x64     # as of vs2022
# equivalent to
Microsoft.VisualStudio.ComponentGroup.VC.Tools.142.x86.x64  # as of vs2022
# compared to
Microsoft.VisualStudio.Component.VC.v141.x86.x64            # until vs2019

However, vswhere.exe only searches for a given artefact, and returns nothing if it doesn't find it. In particular, we're trying to build for 14.28.16.8 & 14.32.17.2 here, but both fail in #56 as not being found. I tried to correct the vswhere component names, but the larger issue is that AFAICT our repack script points to unversioned vcRuntimeMinimum_amd64 artefacts, which will presumably come with the latest minor version (i.e. 16.11 instead of 16.8).

Having worked on exactly these components in conda-forge/clang-win-activation-feedstock#18 recently, I'm wondering why we don't use vsdownload.py from https://github.com/mstorsjo/msvc-wine - that way we could ensure that the right artefacts are installed with more control (the older artefacts still exist, they just have to be explicitly requested), and could ensure that everything is present as desired.

Since I don't know the history of vc_repack.py here, I wanted to open this issue first to find out if this is desirable. It took a while to get right for clang-win, so don't want to waste that effort for nothing.

New DLLs to copy for VS>=19.38; need to expand tests.

When we activated VS2022, I double-checked if there were no new satellite libraries to the vcruntime.

Based on a recent blogpost about C11 threading support in Visual Studio, it appears that there will be two new DLLs (vcruntime140_threads.dll / vcruntime140_threadsd.dll) as of VS 17.8 that we'll have to include.

Or rather, they should get included by the repack mechanism and we'll just have to add tests for it, compare:

vc-feedstock/recipe/meta.yaml

Lines 125 to 135 in 5cbd681

 'vccorlib140.dll', 

 'vcomp140.dll', 

 'vcruntime140.dll'] %} 

 - if not exist %LIBRARY_BIN%\{{ dllname }} exit 1 

 - if not exist %PREFIX%\{{ dllname }} exit 1 

 {% endfor %} 

 {% if vsyear == "2019" %} 

 - if not exist %LIBRARY_BIN%\vcruntime140_1.dll exit 1 

 - if not exist %LIBRARY_BIN%\msvcp140_atomic_wait.dll exit 1 

 - if not exist %LIBRARY_BIN%\msvcp140_codecvt_ids.dll exit 1 

 {% endif %}

where we could add something like:

        {% if vsyear == "2022" %}
        - if not exist %LIBRARY_BIN%\vcruntime140_threads.dll exit 1
        - if not exist %LIBRARY_BIN%\vcruntime140_threadsd.dll exit 1
        {% endif %}

Problems with VS2022 activation in Azure CI with version 14.37

Solution to issue cannot be found in the documentation.

I checked the documentation.

Issue

The MSVC version in Azure CI has been upgraded to 14.37. We get now errors when vs2022 tries to activate version 14.36 which does not exist anymore in de Azure CI image. See this build log.

**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.7.3
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[ERROR:vcvars.bat] Toolset directory for version '14.36' was not found.
[ERROR:VsDevCmd.bat] *** VsDevCmd.bat encountered errors. Environment may be incomplete and/or incorrect. ***
[ERROR:VsDevCmd.bat] In an uninitialized command prompt, please 'set VSCMD_DEBUG=[value]' and then re-run
[ERROR:VsDevCmd.bat] vsdevcmd.bat [args] for additional details.
[ERROR:VsDevCmd.bat] Where [value] is:
[ERROR:VsDevCmd.bat]    1 : basic debug logging
[ERROR:VsDevCmd.bat]    2 : detailed debug logging
[ERROR:VsDevCmd.bat]    3 : trace level logging. Redirection of output to a file when using this level is recommended.
[ERROR:VsDevCmd.bat] Example: set VSCMD_DEBUG=3
[ERROR:VsDevCmd.bat]          vsdevcmd.bat > vsdevcmd.trace.txt 2>&1

Similar problem has occurred in #63 and has been fixed in #64.

Installed packages

not applicable

Environment info

Windows Build in Azure CI using VS2022

VS2022 released

Probably will be some time before this becomes relevant, but here's the announcement. Looks like the build is already templated enough that this shouldn't be too hard to add.

Timeline for dropping vs2017

We bumped the default windows compilers across conda-forge to vs2019 over a year ago (conda-forge/conda-forge-pinning-feedstock#3167), and usage of the previous vs2017 toolchain has dwindled.

Based on the following searches (in conda_build_config.yaml resp. meta.yaml), the only remaining feedstocks using vs2017 are as follows (I'm noting in brackets where the pin is set):

In particular, everything that added pins on vs2017 before August 2022 was "just" selecting the default compilers.

Comatose / dead feedstocks

vs2019 compiler activation failure with Visual Studio 2019 16.10

I read the conda-forge documentation and could not find the solution for my problem there.

Issue:

I'm trying out a Windows build with vs2019 on one of my feedstocks, and it is failing in the activation script with

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise>CALL "VC\Auxiliary\Build\vcvars64.bat" -vcvars_ver=14.28 10.0.19041.0 
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.10.0
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************
[ERROR:vcvars.bat] Toolset directory for version '14.28' was not found.
[ERROR:VsDevCmd.bat] *** VsDevCmd.bat encountered errors. Environment may be incomplete and/or incorrect. ***
[ERROR:VsDevCmd.bat] In an uninitialized command prompt, please 'set VSCMD_DEBUG=[value]' and then re-run
[ERROR:VsDevCmd.bat] vsdevcmd.bat [args] for additional details.
[ERROR:VsDevCmd.bat] Where [value] is:
[ERROR:VsDevCmd.bat]    1 : basic debug logging
[ERROR:VsDevCmd.bat]    2 : detailed debug logging
[ERROR:VsDevCmd.bat]    3 : trace level logging. Redirection of output to a file when using this level is recommended.
[ERROR:VsDevCmd.bat] Example: set VSCMD_DEBUG=3
[ERROR:VsDevCmd.bat]          vsdevcmd.bat > vsdevcmd.trace.txt 2>&1
        1 file(s) copied.

The full log is here. I tested locally and can confirm that the activation works with VS 2019 version 16.9 but now fails with version 16.10. The latest Azure images have unfortunately upgraded to 16.10, so I expect all new builds with vs2019 will fail.

Set CXX version in activation script?

I was coming to this from the POV of how conda-forge/clang-compiler-activation-feedstock#17 applies to windows.

Should we be adding flags for C++17 (or lower?) here and/or in https://github.com/conda-forge/clang-win-activation-feedstock?

Obviously I'd value using the same version as linux/osx, as it makes it easier to do things uniformly like in conda-forge/abseil-cpp-feedstock#28, especially if a patch to upstream is needed.

Don't set target_platform

See

vc-feedstock/recipe/activate.bat

Line 67 in c57d76a

set "target_platform=amd64"

This should be removed as target_platform is a variable set by conda-build.

Update VS2019 to latest

https://aka.ms/vs/16/release/vc_redist.x64.exe has a newer version

Fix CMAKE_GENERATOR when Visual Studio 2019 is used for vc141

I read the conda-forge documentation and could not find the solution for my problem there.

Issue:

Environment (conda list):

$ conda list

Details about conda and system ( conda info ):

$ conda info

cc @henryiii

@conda-forge-admin, please re-render

@conda-forge-admin, please re-render.

Add powershell support

Maybe we could add powershell support by implementing a activate.psm1 similar to this:

https://www.powershellgallery.com/packages/EnterDeveloperPowerShell/1.0.12/Content/EnterDeveloperPowerShell.psm1

Enumerate the matrix

Currently this feedstock only builds with the default (single) matrix. It would be great if conda-smithy could be used to enumerate the matrix. (no, branches really aren't necessary here 😉 ).

@conda-forge-admin, rerender

I read the conda-forge documentation and could not find the solution for my problem there.

Issue:

Environment (conda list):

$ conda list

Details about conda and system ( conda info ):

$ conda info

MNT: The vc recipe has some lint :(

This is the friendly conda-forge-admin automated user.

I've ran the conda-smithy linter and found some lint in this feedstock 😢.

Here is what I have got:

The recipe must have some tests.

Thanks!

activate bat points to non-existent DLL

I believe this line:

set "PY_VCRUNTIME_REDIST=%PREFIX%\bin\vcruntime140.dll"

Should point to %PREFIX%\Library\bin\vcruntime140.dll

Switch to `vswhere.exe`?

Comment:

The configuration is currently hardcoding a bunch of Visual Studio version numbers and I think sometimes they might not even match up (anymore) with the CI.

I wonder if fully relying on vswhere would be better? We have a build of it in conda-forge, and it can produce easy to consume output. For example to ask for MSVC 2019 one could use (version syntax is [lower,upper] to find any version of the 16->17 range):

C:\Users\robostack>"C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe" -version [16,17]
Visual Studio Locator version 3.0.3+45247720e1 [query version 3.4.1128.26111]
Copyright (C) Microsoft Corporation. All rights reserved.

instanceId: a240d692
installDate: 10/10/2020 5:08:27 PM
installationName: VisualStudio/16.11.22+33130.400
installationPath: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
installationVersion: 16.11.33130.400
productId: Microsoft.VisualStudio.Product.Community
productPath: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\devenv.exe
state: 4294967295
isComplete: 1
isLaunchable: 1
isPrerelease: 0
isRebootRequired: 0
displayName: Visual Studio Community 2019
description: Powerful IDE, free for students, open-source contributors, and individuals
channelId: VisualStudio.16.Release
channelUri: https://aka.ms/vs/16/release/channel
enginePath: C:\Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service
releaseNotes: https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes-v16.11#16.11.22
thirdPartyNotices: https://go.microsoft.com/fwlink/?LinkId=660909
updateDate: 2023-01-02T15:46:47.5070005Z
catalog_buildBranch: d16.11
catalog_buildVersion: 16.11.33130.400
catalog_id: VisualStudio/16.11.22+33130.400
catalog_localBuild: build-lab
catalog_manifestName: VisualStudio
catalog_manifestType: installer
catalog_productDisplayVersion: 16.11.22
catalog_productLine: Dev16
catalog_productLineVersion: 2019
catalog_productMilestone: RTW
catalog_productMilestoneIsPreRelease: False
catalog_productName: Visual Studio
catalog_productPatchVersion: 22
catalog_productPreReleaseMilestoneSuffix: 1.0
catalog_productSemanticVersion: 16.11.22+33130.400
catalog_requiredEngineVersion: 2.11.69.53063
properties_campaignId: 98621768.1602356809
properties_channelManifestId: VisualStudio.16.Release/16.11.22+33130.400
properties_nickname:
properties_setupEngineFilePath: C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installershell.exe

mark 14.1 broken and push a new build of 14 instead

Per discussion with @isuruf we've decided to not bump to 14.1 and use a new build of 14 instead.

Mismatch between activation script an CMake expectation for VS2019

I'm trying the vs2019 images because [something, something, AVX2, FMA, etc.], and ran into an error that the CMAKE_GENERATOR set in the activation script of this feedstock isn't being found:

(base) C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise>CALL "VC\Auxiliary\Build\vcvars64.bat" -vcvars_ver=14.28 10.0.19041.0 
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.8.4
** Copyright (c) 2020 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

(D:\bld\faiss-split_1613075866363\_build_env) (base) D:\bld\faiss-split_1613075866363\work>cmake -B _build_generic     -DBUILD_SHARED_LIBS=ON     -DBUILD_TESTING=OFF     -DFAISS_ENABLE_GPU=OFF     -DFAISS_ENABLE_PYTHON=OFF     -DCMAKE_INSTALL_PREFIX="D:\bld\faiss-split_1613075866363\_h_env\Library"     -DCMAKE_INSTALL_BINDIR="D:\bld\faiss-split_1613075866363\_h_env\Library\bin"     -DCMAKE_INSTALL_LIBDIR="D:\bld\faiss-split_1613075866363\_h_env\Library\lib"     -DCMAKE_INSTALL_INCLUDEDIR="D:\bld\faiss-split_1613075866363\_h_env\Library\include"     --verbose     . 
CMake Error: CMAKE_GENERATOR was set but the specified generator doesn't exist. Using CMake default.
-- Building for: Visual Studio 16 2019
-- The CXX compiler identification is MSVC 19.28.29336.0

With nothing but a lucky guess I thought it might be the "Win64" part, and indeed, with set "CMAKE_GENERATOR=Visual Studio 16 2019", things work (or fail a few steps later 🙈 )

uploading of new builds fail

cc @beckermr

Problems with VS2022 activation

Seen in conda-forge/flang-feedstock#27:

C:\Program Files\Microsoft Visual Studio\2022\Enterprise>CALL "VC\Auxiliary\Build\vcvars64.bat" -vcvars_ver=14.34 10.0.22621.0 
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.6.2
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[ERROR:vcvars.bat] Toolset directory for version '14.34' was not found.
[ERROR:VsDevCmd.bat] *** VsDevCmd.bat encountered errors. Environment may be incomplete and/or incorrect. ***
[ERROR:VsDevCmd.bat] In an uninitialized command prompt, please 'set VSCMD_DEBUG=[value]' and then re-run
[ERROR:VsDevCmd.bat] vsdevcmd.bat [args] for additional details.
[ERROR:VsDevCmd.bat] Where [value] is:
[ERROR:VsDevCmd.bat]    1 : basic debug logging
[ERROR:VsDevCmd.bat]    2 : detailed debug logging
[ERROR:VsDevCmd.bat]    3 : trace level logging. Redirection of output to a file when using this level is recommended.
[ERROR:VsDevCmd.bat] Example: set VSCMD_DEBUG=3
[ERROR:VsDevCmd.bat]          vsdevcmd.bat > vsdevcmd.trace.txt 2>&1

Soon after, msvcrtd.lib is not found and compilation fails (the simplest example that CMake runs internally)

Fallout from new vc setup: openssl symbol not found

While I don't understand the mechanics of it, it seems that #55 caused some regressions. For example, conda-forge/arrow-cpp-feedstock#1044 passed in PR and then failed after merge (and after restart).

arrow build failure

[90/123] Linking CXX shared library release\arrow.dll
FAILED: release/arrow.dll release/arrow.lib 
cmd.exe /C "cd . && D:\bld\apache-arrow_1683178556486\_build_env\Library\bin\cmake.exe -E vs_link_dll --intdir=src\arrow\CMakeFiles\arrow_shared.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\mt.exe --manifests  -- C:\PROGRA~1\MICROS~2\2022\ENTERP~1\VC\Tools\MSVC\1429~1.301\bin\HostX64\x64\link.exe /nologo @CMakeFiles\arrow_shared.rsp  /out:release\arrow.dll /implib:release\arrow.lib /pdb:release\arrow.pdb /dll /version:1100.0 /machine:x64  /NODEFAULTLIB:LIBCMT /INCREMENTAL:NO -Wl,--version-script=D:/bld/apache-arrow_1683178556486/work/cpp/src/arrow/symbols.map  && cd ."
LINK: command "C:\PROGRA~1\MICROS~2\2022\ENTERP~1\VC\Tools\MSVC\1429~1.301\bin\HostX64\x64\link.exe /nologo @CMakeFiles\arrow_shared.rsp /out:release\arrow.dll /implib:release\arrow.lib /pdb:release\arrow.pdb /dll /version:1100.0 /machine:x64 /NODEFAULTLIB:LIBCMT /INCREMENTAL:NO -Wl,--version-script=D:/bld/apache-arrow_1683178556486/work/cpp/src/arrow/symbols.map /MANIFEST /MANIFESTFILE:release\arrow.dll.manifest" failed (exit code 1120) with the following output:
LINK : warning LNK4044: unrecognized option '/Wl,--version-script=D:/bld/apache-arrow_1683178556486/work/cpp/src/arrow/symbols.map'; ignored
   Creating library release\arrow.lib and object release\arrow.exp
google_cloud_cpp_storage.lib(openssl_util.cc.obj) : error LNK2019: unresolved external symbol EVP_DigestSignUpdate referenced in function "class google::cloud::v2_10_0::StatusOr<class std::vector<unsigned char,class std::allocator<unsigned char> > > __cdecl google::cloud::storage::v2_10_0::internal::SignStringWithPem(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,enum google::cloud::storage::v2_10_0::oauth2::JwtSigningAlgorithms)" (?SignStringWithPem@internal@v2_10_0@storage@cloud@google@@YA?AV?$StatusOr@V?$vector@EV?$allocator@E@std@@@std@@@245@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0W4JwtSigningAlgorithms@oauth2@2345@@Z)
google_cloud_cpp_rest_internal.lib(openssl_util.cc.obj) : error LNK2001: unresolved external symbol EVP_DigestSignUpdate
google_cloud_cpp_storage.lib(hash_function_impl.cc.obj) : error LNK2019: unresolved external symbol EVP_MD_get_size referenced in function "public: virtual struct google::cloud::storage::v2_10_0::internal::HashValues __cdecl google::cloud::storage::v2_10_0::internal::MD5HashFunction::Finish(void)" (?Finish@MD5HashFunction@internal@v2_10_0@storage@cloud@google@@UEAA?AUHashValues@23456@XZ)

release\arrow.dll : fatal error LNK1120: 2 unresolved externals

I diffed the host environment between the passing and failing run, and the only difference is from the new vc-setup:

     thrift-compiler:    0.18.1-h9ce19ad_1           conda-forge
     thrift-cpp:         0.18.1-h9c18f36_1           conda-forge
     ucrt:               10.0.22621.0-h57928b3_0     conda-forge
-    vc:                 14.3-h3d8a991_11            conda-forge
-    vs2015_runtime:     14.34.31931-h4c5c07a_11     conda-forge
+    vc:                 14.3-h9bf60a3_15            conda-forge
+    vc14_runtime:       14.34.31931-h5081d32_15     conda-forge
+    vs2015_runtime:     14.34.31931-hed1258a_15     conda-forge
     xsimd:              11.0.0-h91493d7_0           conda-forge
     zlib:               1.2.13-hcfcfb64_4           conda-forge
     zstd:               1.5.2-h12be248_6            conda-forge

A similar error appeared in conda-forge/cpp-opentelemetry-sdk-feedstock#46

libopentelemetry-cpp build failure

[81/109] Linking CXX shared library exporters\otlp\opentelemetry_exporter_otlp_grpc_client.dll
FAILED: exporters/otlp/opentelemetry_exporter_otlp_grpc_client.dll exporters/otlp/opentelemetry_exporter_otlp_grpc_client.lib 
cmd.exe /C "cmd.exe /C "%BUILD_PREFIX%\Library\bin\cmake.exe -E __create_def %SRC_DIR%\build-cpp\exporters\otlp\CMakeFiles\opentelemetry_exporter_otlp_grpc_client.dir\.\exports.def %SRC_DIR%\build-cpp\exporters\otlp\CMakeFiles\opentelemetry_exporter_otlp_grpc_client.dir\.\exports.def.objs && cd %SRC_DIR%\build-cpp" && %BUILD_PREFIX%\Library\bin\cmake.exe -E vs_link_dll --intdir=exporters\otlp\CMakeFiles\opentelemetry_exporter_otlp_grpc_client.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\mt.exe --manifests  -- C:\PROGRA~1\MICROS~2\2022\ENTERP~1\VC\Tools\MSVC\1429~1.301\bin\HostX64\x64\link.exe /nologo exporters\otlp\CMakeFiles\opentelemetry_exporter_otlp_grpc_client.dir\src\otlp_grpc_client.cc.obj exporters\otlp\CMakeFiles\opentelemetry_exporter_otlp_grpc_client.dir\src\otlp_grpc_utils.cc.obj  /out:exporters\otlp\opentelemetry_exporter_otlp_grpc_client.dll /implib:exporters\otlp\opentelemetry_exporter_otlp_grpc_client.lib /pdb:exporters\otlp\opentelemetry_exporter_otlp_grpc_client.pdb /dll /version:0.0 /machine:x64 /INCREMENTAL:NO  /DEF:exporters\otlp\CMakeFiles\opentelemetry_exporter_otlp_grpc_client.dir\.\exports.def  opentelemetry_proto.lib  sdk\src\common\opentelemetry_common.lib  %PREFIX%\Library\lib\grpc++.lib  %PREFIX%\Library\lib\libprotobuf.lib  %PREFIX%\Library\lib\grpc.lib  %PREFIX%\Library\lib\cares.lib  advapi32.lib  iphlpapi.lib  %PREFIX%\Library\lib\address_sorting.lib  %PREFIX%\Library\lib\re2.lib  %PREFIX%\Library\lib\upb.lib  %PREFIX%\Library\lib\gpr.lib  ws2_32.lib  crypt32.lib  %PREFIX%\Library\lib\z.lib  %PREFIX%\Library\lib\absl_flags.lib  %PREFIX%\Library\lib\absl_flags_internal.lib  %PREFIX%\Library\lib\absl_flags_reflection.lib  %PREFIX%\Library\lib\absl_flags_config.lib  %PREFIX%\Library\lib\absl_flags_program_name.lib  %PREFIX%\Library\lib\absl_flags_private_handle_accessor.lib  %PREFIX%\Library\lib\absl_flags_commandlineflag.lib  %PREFIX%\Library\lib\absl_flags_commandlineflag_internal.lib  %PREFIX%\Library\lib\absl_flags_marshalling.lib  %PREFIX%\Library\lib\abseil_dll.lib  "C:\Program Files\OpenSSL\lib\VC\libssl64MD.lib"  "C:\Program Files\OpenSSL\lib\VC\libcrypto64MD.lib"  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib  && cd ."
LINK: command "C:\PROGRA~1\MICROS~2\2022\ENTERP~1\VC\Tools\MSVC\1429~1.301\bin\HostX64\x64\link.exe /nologo exporters\otlp\CMakeFiles\opentelemetry_exporter_otlp_grpc_client.dir\src\otlp_grpc_client.cc.obj exporters\otlp\CMakeFiles\opentelemetry_exporter_otlp_grpc_client.dir\src\otlp_grpc_utils.cc.obj /out:exporters\otlp\opentelemetry_exporter_otlp_grpc_client.dll /implib:exporters\otlp\opentelemetry_exporter_otlp_grpc_client.lib /pdb:exporters\otlp\opentelemetry_exporter_otlp_grpc_client.pdb /dll /version:0.0 /machine:x64 /INCREMENTAL:NO /DEF:exporters\otlp\CMakeFiles\opentelemetry_exporter_otlp_grpc_client.dir\.\exports.def opentelemetry_proto.lib sdk\src\common\opentelemetry_common.lib %PREFIX%\Library\lib\grpc++.lib %PREFIX%\Library\lib\libprotobuf.lib %PREFIX%\Library\lib\grpc.lib %PREFIX%\Library\lib\cares.lib advapi32.lib iphlpapi.lib %PREFIX%\Library\lib\address_sorting.lib %PREFIX%\Library\lib\re2.lib %PREFIX%\Library\lib\upb.lib %PREFIX%\Library\lib\gpr.lib ws2_32.lib crypt32.lib %PREFIX%\Library\lib\z.lib %PREFIX%\Library\lib\absl_flags.lib %PREFIX%\Library\lib\absl_flags_internal.lib %PREFIX%\Library\lib\absl_flags_reflection.lib %PREFIX%\Library\lib\absl_flags_config.lib %PREFIX%\Library\lib\absl_flags_program_name.lib %PREFIX%\Library\lib\absl_flags_private_handle_accessor.lib %PREFIX%\Library\lib\absl_flags_commandlineflag.lib %PREFIX%\Library\lib\absl_flags_commandlineflag_internal.lib %PREFIX%\Library\lib\absl_flags_marshalling.lib %PREFIX%\Library\lib\abseil_dll.lib C:\Program Files\OpenSSL\lib\VC\libssl64MD.lib C:\Program Files\OpenSSL\lib\VC\libcrypto64MD.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:exporters\otlp\opentelemetry_exporter_otlp_grpc_client.dll.manifest" failed (exit code 1120) with the following output:
   Creating library exporters\otlp\opentelemetry_exporter_otlp_grpc_client.lib and object exporters\otlp\opentelemetry_exporter_otlp_grpc_client.exp
grpc.lib(json_token.cc.obj) : error LNK2019: unresolved external symbol EVP_DigestSignUpdate referenced in function "char * __cdecl compute_and_encode_signature(struct grpc_auth_json_key const *,char const *,char const *)" (?compute_and_encode_signature@@YAPEADPEBUgrpc_auth_json_key@@PEBD1@Z)
grpc.lib(ssl_transport_security.cc.obj) : error LNK2019: unresolved external symbol SSL_get1_peer_certificate referenced in function "enum tsi_result __cdecl ssl_handshaker_result_extract_peer(struct tsi_handshaker_result const *,struct tsi_peer *)" (?ssl_handshaker_result_extract_peer@@YA?AW4tsi_result@@PEBUtsi_handshaker_result@@PEAUtsi_peer@@@Z)

exporters\otlp\opentelemetry_exporter_otlp_grpc_client.dll : fatal error LNK1120: 2 unresolved externals

I've tried to roll back to previous versions, but even pinning the build deps (exactly as for the last passing run) doesn't work. Not sure how to "go back" for compiler-infra, other than perhaps mark the builds after _11 as broken for now, at least on win-64?

@conda-forge-admin rerender

I read the conda-forge documentation and could not find the solution for my problem there.

Issue:

Environment (conda list):

$ conda list

Details about conda and system ( conda info ):

$ conda info

activate.bat script defines non-existing Visual Studio 16 2019 Win64 CMake generator

I read the conda-forge documentation and could not find the solution for my problem there.

The PR #19 added support for using Visual Studio 16 2019 . In the activate.bat script, however, there was some code that set the CMAKE_GENERATOR env variable to the Visual Studio 16 2019 Win64 value (as in the past it set it to Visual Studio 15 2017 Win64). However, while Visual Studio 15 2017 Win64 is a valid generator (see https://cmake.org/cmake/help/v3.19/generator/Visual%20Studio%2015%202017.html#platform-selection), the Visual Studio 16 2019 Win64 generator does not exists (see https://cmake.org/cmake/help/v3.19/generator/Visual%20Studio%2016%202019.html#platform-selection).

The Win64 suffix in the generator was removed as now the same objective can be obtained in more scalable way by setting the CMAKE_GENERATOR_PLATFORM env variable to x64, and that should work with both VS2017 and VS2019.

Linter is failing

Appears the linter is failing on the vc recipe. Not remembering whether this was a known issue that still needs to be addressed or if this is a new problem just now surfacing. Any thoughts on how to fix this, @pelson?

Microsoft will break existing version scheme with upcoming VS 17.10 == vc 14.4

The minor version of vc will be increased without any other relevant changes.

From looking at the recipe and the global pinning, we should actually be fine...? AFAICT, at worst it should behave like a new compiler version, while actually staying VS2022. It also helps that we don't have that as our default compiler version on windows yet.

First steps towards vs2019 optional feedstock

A large package of mine (10k lines of code) fails when compiling with vs2017 with internal compiler errors, however it passes with vs2019. Other platforms pass as well. Following a discussion with @beckermr, he chaired a talking point at the conda-forge/core team meeting concerning making vs2019 a supported feedstock. The minutes recorded are as follow.

What do we need to do to get this done?

(@isuruf) Is this going to be global or just for a few feedstocks? If it's global, that's going to be a bit of a problem. you can link libs with 2017 and 2019 together, but you need 2019 to do the linking. This will require people building conda packages locally to update to vs2019. Uwe was cross-compiling but we only have vs2017.

Which feedstocks need to be updated? Just the vc one

new universal runtime which adds new DLLs

not on windows 10

can download it from windows update

make a new runtime package

@jjhelmus posted a note on the filename in gitter

try and use paul's PR for vc for 2019

do that PR for 2017 and try it on vc_dev channel

then do for 2019

keep track of where version numbers come from

	'vccorlib140.dll',
	'vcomp140.dll',
	'vcruntime140.dll'] %}
	- if not exist %LIBRARY_BIN%\{{ dllname }} exit 1
	- if not exist %PREFIX%\{{ dllname }} exit 1
	{% endfor %}
	{% if vsyear == "2019" %}
	- if not exist %LIBRARY_BIN%\vcruntime140_1.dll exit 1
	- if not exist %LIBRARY_BIN%\msvcp140_atomic_wait.dll exit 1
	- if not exist %LIBRARY_BIN%\msvcp140_codecvt_ids.dll exit 1
	{% endif %}

conda-forge / vc-feedstock Goto Github PK

vc-feedstock's People

Contributors

Stargazers

Watchers

Forkers

vc-feedstock's Issues

Solution to issue cannot be found in the documentation.

Issue

Installed packages

Environment info

Comatose / dead feedstocks

Comment:

Recommend Projects

Recommend Topics

Recommend Org