DReyeVR icon indicating copy to clipboard operation
DReyeVR copied to clipboard

Problems with make PythonAPI

Open edugh02 opened this issue 1 year ago • 2 comments

Hi, i have problems trying to do the make PythonAPI comand in my x64 Native Tools Command Prompt for VS2019 I'm using:

  • Windows 11
  • Carla 0.9.13
  • Visual Studio 16 2019
  • Python 3.7.0
  • Pip & Pip3 24.0
  • GNU Make 3.81
  • Cmake 3.29.0

And I also have changed install_xercesc.bat changing the xerces version from 3.2.3 to 3.2.5, and also the same with install_zlib.bat changing to zlib version 1.3.1

I get the following error:

`-[BuildOSM2ODR]: [Batch params]: --build --all Cloning into 'C:\TFG\carla\Build\om2odr-source'... remote: Enumerating objects: 1438389, done. remote: Counting objects: 100% (13086/13086), done. remote: Compressing objects: 100% (1773/1773), done. Receiving objects: 100% (1438389/1438389), 993.69 MiB | 7.85 MiB/s, done.sed 1425303Receiving objects: 100% (1438389/1438389), 991.69 MiB | 9.68 MiB/s

Resolving deltas: 100% (1224119/1224119), done. Updating files: 100% (108359/108359), done. Updating files: 100% (103225/103225), done. Note: switching to 'ee0c2b9241fef5365a6bc044ac82e6580b8ce936'.

You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example:

git switch -c

Or undo this operation with:

git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at ee0c2b9241f Removed debug warnings -- Setting build type to 'Release' as none was specified. CMake Warning (dev) at CMakeLists.txt:23 (project): cmake_minimum_required() should be called prior to this top-level project() call. Please see the cmake-commands(7) manual for usage documentation of both commands. This warning is for project developers. Use -Wno-dev to suppress it.

-- Selecting Windows SDK version 10.0.22000.0 to target Windows 10.0.22631. -- The C compiler identification is MSVC 19.29.30154.0 -- The CXX compiler identification is MSVC 19.29.30154.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done CMake Deprecation Warning at CMakeLists.txt:25 (cmake_minimum_required): Compatibility with CMake < 3.5 will be removed from a future version of CMake.

Update the VERSION argument value or use a ... suffix to tell CMake that the project does not need compatibility with older versions.

-- CMAKE_BINARY_DIR: C:/TFG/carla/Build/osm2odr-visualstudio -- CMAKE_SOURCE_DIR: C:/TFG/carla/Build/om2odr-source

-- Platform: -- Host: Windows-10.0.22631 AMD64 -- Target: Windows-10.0.22631 AMD64 -- CMake: 3.29.0 -- CMake generator: Visual Studio 16 2019 -- CMake build tool: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin/MSBuild.exe -- Compiler: MSVC 19.29.30154.0

CMake Error at C:/Program Files/CMake/share/cmake-3.29/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Failed to find XercesC (missing: XercesC_VERSION) Call Stack (most recent call first): C:/Program Files/CMake/share/cmake-3.29/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE) C:/Program Files/CMake/share/cmake-3.29/Modules/FindXercesC.cmake:112 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:71 (find_package)

-- Configuring incomplete, errors occurred! Microsoft (R) Build Engine versión 16.11.2+f32259642 para .NET Framework Copyright (C) Microsoft Corporation. Todos los derechos reservados.

MSBUILD : error MSB1009: El archivo de proyecto no existe. Modificador: install.vcxproj -[BuildOSM2ODR]: OSM2ODR has been successfully installed in "C:\TFG\carla\PythonAPI\carla\dependencies" -[BuildPythonAPI]: [Batch params]: --py3 Building Python API for Python 3. compiling:

  • source/libcarla/libcarla.cpp C:\Program Files\Python37\lib\distutils\dist.py:274: UserWarning: Unknown distribution option: 'long_description_content_type' warnings.warn(msg) running bdist_egg running egg_info writing source\carla.egg-info\PKG-INFO writing dependency_links to source\carla.egg-info\dependency_links.txt writing top-level names to source\carla.egg-info\top_level.txt reading manifest file 'source\carla.egg-info\SOURCES.txt' writing manifest file 'source\carla.egg-info\SOURCES.txt' installing library code to build\bdist.win-amd64\egg running install_lib running build_py running build_ext building 'carla.libcarla' extension C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX86\x64\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MT -Idependencies/include "-IC:\Program Files\Python37\include" "-IC:\Program Files\Python37\include" "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\ATLMFC\include" "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include" "-IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\winrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\cppwinrt" "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\ATLMFC\include" "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include" "-IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\winrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\cppwinrt" /EHsc /Tpsource/libcarla/libcarla.cpp /Fobuild\temp.win-amd64-3.7\Release\source/libcarla/libcarla.obj /experimental:external /external:W0 /external:I dependencies/include/system /DBOOST_ALL_NO_LIB /DBOOST_PYTHON_STATIC_LIB /DBOOST_ERROR_CODE_HEADER_ONLY /D_WIN32_WINNT=0x0600 /DHAVE_SNPRINTF /DLIBCARLA_WITH_PYTHON_SUPPORT -DLIBCARLA_IMAGE_WITH_PNG_SUPPORT=true /MD cl : Línea de comandos warning D9025 : invalidando '/MT' con '/MD' libcarla.cpp C:\TFG\carla\PythonAPI\carla\source\libcarla\OSM2ODR.cpp(7): fatal error C1083: No se puede abrir el archivo incluir: 'OSM2ODR.h': No such file or directory error: command 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX86\x64\cl.exe' failed with exit status 2

-[BuildPythonAPI]: Carla lib for python has been successfully installed in "C:\TFG\carla\PythonAPI\carla\dist"!`

edugh02 avatar Mar 31 '24 12:03 edugh02

This is a carla build issue. See here for possible solutions: https://github.com/carla-simulator/carla/issues/3320

ajdroid avatar Apr 01 '24 17:04 ajdroid

I've upgraded from carla 0.9.13 to 0.9.15 and python 3.7.0 to Python 3.12.2 and i fixed it. But now i have the following error: Once i have launched carla with make launch, i try to generete traffic but i have this problem:

C:\TFG\carla\PythonAPI\examples>pip3 install -r requirements.txt Defaulting to user installation because normal site-packages is not writeable Ignoring numpy: markers 'python_version < "3.0"' don't match your environment Collecting future (from -r requirements.txt (line 1)) Using cached future-1.0.0-py3-none-any.whl.metadata (4.0 kB) Collecting numpy==1.18.4 (from -r requirements.txt (line 3)) Using cached numpy-1.18.4.zip (5.4 MB) Installing build dependencies ... done Getting requirements to build wheel ... done Preparing metadata (pyproject.toml) ... error error: subprocess-exited-with-error

× Preparing metadata (pyproject.toml) did not run successfully. │ exit code: 1 ╰─> [92 lines of output] Running from numpy source directory. :461: UserWarning: Unrecognized setuptools command, proceeding with generating Cython sources and expanding templates C:\Users\Admin\AppData\Local\Temp\pip-install-njerfvbr\numpy_6baaa279996548228e9198dfbab85a14\tools\cythonize.py:75: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead. required_version = LooseVersion('0.29.14') C:\Users\Admin\AppData\Local\Temp\pip-install-njerfvbr\numpy_6baaa279996548228e9198dfbab85a14\tools\cythonize.py:77: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead. if LooseVersion(cython_version) < required_version: performance hint: _common.pyx:261:19: Exception check after calling 'random_func' will always require the GIL to be acquired. Declare 'random_func' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:285:19: Exception check after calling 'random_func' will always require the GIL to be acquired. Declare 'random_func' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:308:50: Exception check after calling 'random_func' will always require the GIL to be acquired. Declare 'random_func' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:411:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:448:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:490:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:573:36: Exception check after calling 'f0' will always require the GIL to be acquired. Declare 'f0' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:577:36: Exception check after calling 'f1' will always require the GIL to be acquired. Declare 'f1' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:581:36: Exception check after calling 'f2' will always require the GIL to be acquired. Declare 'f2' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:585:36: Exception check after calling 'f3' will always require the GIL to be acquired. Declare 'f3' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:617:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:652:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:687:63: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:727:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:756:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:874:40: Exception check after calling 'f0' will always require the GIL to be acquired. Declare 'f0' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:878:40: Exception check after calling 'fd' will always require the GIL to be acquired. Declare 'fd' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:882:41: Exception check after calling 'fdd' will always require the GIL to be acquired. Declare 'fdd' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:887:40: Exception check after calling 'fi' will always require the GIL to be acquired. Declare 'fi' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:891:41: Exception check after calling 'fdi' will always require the GIL to be acquired. Declare 'fdi' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:895:38: Exception check after calling 'fiii' will always require the GIL to be acquired. Declare 'fiii' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:930:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:972:32: Exception check after calling 'f1' will always require the GIL to be acquired. Declare 'f1' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _generator.pyx:811:41: Exception check after calling '_shuffle_int' will always require the GIL to be acquired. Possible solutions: 1. Declare '_shuffle_int' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. 2. Use an 'int' return type on '_shuffle_int' to allow an error code to be returned. performance hint: _generator.pyx:840:45: Exception check after calling '_shuffle_int' will always require the GIL to be acquired. Possible solutions: 1. Declare '_shuffle_int' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. 2. Use an 'int' return type on '_shuffle_int' to allow an error code to be returned.

  Error compiling Cython file:
  ------------------------------------------------------------
  ...
          for i in range(1, RK_STATE_LEN):
              self.rng_state.key[i] = val[i]
          self.rng_state.pos = i

          self._bitgen.state = &self.rng_state
          self._bitgen.next_uint64 = &mt19937_uint64
                                     ^
  ------------------------------------------------------------

  _mt19937.pyx:138:35: Cannot assign type 'uint64_t (*)(void *) except? -1 nogil' to 'uint64_t (*)(void *) noexcept nogil'. Exception values are incompatible. Suggest adding 'noexcept' to the type of the value being assigned.
  Processing numpy/random\_bounded_integers.pxd.in
  Processing numpy/random\mtrand.pyx
  Processing numpy/random\_bit_generator.pyx
  Processing numpy/random\_bounded_integers.pyx.in
  Processing numpy/random\_common.pyx
  Processing numpy/random\_generator.pyx
  Processing numpy/random\_mt19937.pyx
  Traceback (most recent call last):
    File "C:\Users\Admin\AppData\Local\Temp\pip-install-njerfvbr\numpy_6baaa279996548228e9198dfbab85a14\tools\cythonize.py", line 238, in <module>
      main()
    File "C:\Users\Admin\AppData\Local\Temp\pip-install-njerfvbr\numpy_6baaa279996548228e9198dfbab85a14\tools\cythonize.py", line 234, in main
      find_process_files(root_dir)
    File "C:\Users\Admin\AppData\Local\Temp\pip-install-njerfvbr\numpy_6baaa279996548228e9198dfbab85a14\tools\cythonize.py", line 225, in find_process_files
      process(root_dir, fromfile, tofile, function, hash_db)
    File "C:\Users\Admin\AppData\Local\Temp\pip-install-njerfvbr\numpy_6baaa279996548228e9198dfbab85a14\tools\cythonize.py", line 191, in process
      processor_function(fromfile, tofile)
    File "C:\Users\Admin\AppData\Local\Temp\pip-install-njerfvbr\numpy_6baaa279996548228e9198dfbab85a14\tools\cythonize.py", line 80, in process_pyx
      subprocess.check_call(
    File "C:\Program Files\Python312\Lib\subprocess.py", line 413, in check_call
      raise CalledProcessError(retcode, cmd)
  subprocess.CalledProcessError: Command '['C:\\Program Files\\Python312\\python.exe', '-m', 'cython', '-3', '--fast-fail', '-o', '_mt19937.c', '_mt19937.pyx']' returned non-zero exit status 1.
  Cythonizing sources
  Traceback (most recent call last):
    File "C:\Program Files\Python312\Lib\site-packages\pip\_vendor\pyproject_hooks\_in_process\_in_process.py", line 353, in <module>
      main()
    File "C:\Program Files\Python312\Lib\site-packages\pip\_vendor\pyproject_hooks\_in_process\_in_process.py", line 335, in main
      json_out['return_val'] = hook(**hook_input['kwargs'])
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    File "C:\Program Files\Python312\Lib\site-packages\pip\_vendor\pyproject_hooks\_in_process\_in_process.py", line 149, in prepare_metadata_for_build_wheel
      return hook(metadata_directory, config_settings)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    File "C:\Users\Admin\AppData\Local\Temp\pip-build-env-7zqc9j08\overlay\Lib\site-packages\setuptools\build_meta.py", line 366, in prepare_metadata_for_build_wheel
      self.run_setup()
    File "C:\Users\Admin\AppData\Local\Temp\pip-build-env-7zqc9j08\overlay\Lib\site-packages\setuptools\build_meta.py", line 487, in run_setup
      super().run_setup(setup_script=setup_script)
    File "C:\Users\Admin\AppData\Local\Temp\pip-build-env-7zqc9j08\overlay\Lib\site-packages\setuptools\build_meta.py", line 311, in run_setup
      exec(code, locals())
    File "<string>", line 488, in <module>
    File "<string>", line 469, in setup_package
    File "<string>", line 275, in generate_cython
  RuntimeError: Running cythonize failed!
  [end of output]

note: This error originates from a subprocess, and is likely not a problem with pip. error: metadata-generation-failed

× Encountered error while generating package metadata. ╰─> See above for output.

note: This is an issue with the package mentioned above, not pip. hint: See above for details.

edugh02 avatar Apr 01 '24 19:04 edugh02