Skip to content

lld-link error: could not open 'python37.lib' #2171

@jamiebk

Description

@jamiebk

Issue description

On windows, using CMake+clang to compile for windows. This means linking using lld-link.exe rather than link.exe. The argument for the python lib is being passed to lld-link as 'Python37.lib' though the file is actually 'python37.lib' (different capitalization). This wouldn't normally be a problem on windows, of course, but in this case lld-link is complaining "error : could not open 'python37.lib': no such file or directory". Confusingly, it uses the correct case in the error message.

The capitalization in question comes from FindPythonLibsNew.cmake:

if(CMAKE_HOST_WIN32 AND NOT (MSYS OR MINGW))
    set(PYTHON_LIBRARY
        "${PYTHON_PREFIX}/libs/Python${PYTHON_LIBRARY_SUFFIX}.lib")

    # when run in a venv, PYTHON_PREFIX points to it. But the libraries remain in the
    # original python installation. They may be found relative to PYTHON_INCLUDE_DIR.
    if(NOT EXISTS "${PYTHON_LIBRARY}")
        get_filename_component(_PYTHON_ROOT ${PYTHON_INCLUDE_DIR} DIRECTORY)
        set(PYTHON_LIBRARY
            "${_PYTHON_ROOT}/libs/Python${PYTHON_LIBRARY_SUFFIX}.lib")
    endif()
...

Changing the section above to use lowercase 'python' rather than 'Python' fixes the problem, i.e.:

if(CMAKE_HOST_WIN32 AND NOT (MSYS OR MINGW))
    set(PYTHON_LIBRARY
        "${PYTHON_PREFIX}/libs/python${PYTHON_LIBRARY_SUFFIX}.lib")

    # when run in a venv, PYTHON_PREFIX points to it. But the libraries remain in the
    # original python installation. They may be found relative to PYTHON_INCLUDE_DIR.
    if(NOT EXISTS "${PYTHON_LIBRARY}")
        get_filename_component(_PYTHON_ROOT ${PYTHON_INCLUDE_DIR} DIRECTORY)
        set(PYTHON_LIBRARY
            "${_PYTHON_ROOT}/libs/python${PYTHON_LIBRARY_SUFFIX}.lib")
    endif()
...

Reproducible example code

  • Visual studio 2019, with the current VS-installer versions of Python (3.7.3) and (Clang 9.0.0)
  • Config in CMakeSettings.json is just the x64-Clang-Debug default from visual studio.
  • pybind11 installed through vcpkg, though I've also checked the issue still occurs with the current pybind11 master as a subrepo.

repro.zip

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions