Mailman 3 July 2019 - Cplusplus-sig

"cannot open input file 'boost_python.lib'" when building
by Dylan Scott July 18, 2019

July 18, 2019

Hello I'm fairly new to boost, and I am attempting to follow the tutorial here: https://www.boost.org/doc/libs/1_58_0/libs/python/doc/building.html . I believe I have followed all of the steps exactly. and I think I have configured my jamfile, user-config.jam, and jamroot files all correctly. No matter what I try to build, I always get an error saying "cannot open input file 'boost_python.lib". I have been trying to figure this out for probably a week now with no luck. Any help would be greatly appreciated.

1 0

Problems on Boost:Python
by rongbao＠ipp.ac.cn July 8, 2019

July 8, 2019

Dear Boost Team, I am a beginner of Boost, and want to use Boost and Python for an open-source CAE software OOFEM installation on MS/Windows though Cmake 3.15. I use win7, Visual Studio 2017, python-3.7.3-amd64, and boost_1_70_0-msvc-14.1-64 (Prebuilt windows binaries from https://www.boost.org/users/download/). When I set my Cmake path, it needs Boost_PYTHON-PY37_LIBRARY_RELEASE and Boost_PYTHON-PY37_LIBRARY_DEBUG, but in the boost Folder there is only Boost_PYTHON-PY37_LIBRARY_DEBUG and Boost_PYTHON-PY37_LIBRARY_RELEASE. I want to know how to obtain the Boost_PYTHON-PY37_LIBRARY_RELEASE and Boost_PYTHON-PY37_LIBRARY_DEBUG. I run "Configure" without Boost_PYTHON-PY37_LIBRARY_DEBUG and Boost_PYTHON-PY37_LIBRARY_RELEASE, it shows: CMake Warning at C:/Program Files/CMake/share/cmake-3.15/Modules/FindBoost.cmake:1832 (message): No header defined for python-py37; skipping header check Call Stack (most recent call first): CMakeLists.txt:507 (find_package) CMake Error at C:/Program Files/CMake/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find Boost (missing: python-py37) (found version "1.70.0") Call Stack (most recent call first): C:/Program Files/CMake/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE) C:/Program Files/CMake/share/cmake-3.15/Modules/FindBoost.cmake:1990 (find_package_handle_standard_args) CMakeLists.txt:507 (find_package) I don't know how to solve these problems. Would you kindly please tell me the mistakes? Thank you very much for all your help. Best regards, Bao Rong **************************************************** Bao Rong, Ph.D. Hefei Institutes of Physical Science, Chinese Academy of Sciences ADD: Institute of Plasma Physics, 350 Shushanhu Road，Hefei，Anhui，230031 Email: rongbao(a)ipp.ac.cn; rongbao_nust(a)sina.com *****************************************************

1 0

Different behavior between local import and import from python-path
by Benedikt Tutzer July 4, 2019

July 4, 2019

Hello, A few months ago I published Python wrappers for Yosys (https://github.com/YosysHQ/yosys). These can be used in two ways: 1. Use Yosys in Python code by importing it and using it as a library 2. Start the Yosys shell (regular command-line interaction) and load python code by specifying a source file. In that source file, one can implement passes by inheriting from the Pass class and these passes are then available in the Yosys shell. This works well and was already merged into the main Yosys repo. However, there is an issue I cannot wrap my head around. When Yosys is installed, I copy the shared library .so file together with a minimal __init__.py to /usr/lib/python3.5/site-packages/pyosys. I can then use that by writing > from pyosys import libyosys as ys This works great for case 1. I also need that import for case 2, so that users can inherit from the Pass class and use Yosys data structures. The import seems to work, but as soon as a command is issued, an exception is thrown. This exception seems not to concern the interoperability with Python, but it does not appear when I copy the .so file to the current working directory and import it by saying > import libyosys as ys In that case, everything is well and the whole thing works. The Pass defined in Python shows up in the Pass-list, can be executed and successfully interacts with the data structures created by C++ passes. The obvious place to look would be the __init__.py file, since that is the only thing that is executed when importing from the path but not executed when importing from the local library, right? But all I do in the init file is: > import os > import sys > sys.setdlopenflags(os.RTLD_NOW | os.RTLD_GLOBAL) > > __all__ = ["libyosys"] And if I remove the first lines it doesn't work either, so they cannot (solely) be at fault. Any other reason why the two ways to import would differ? The exception thrown is a std::out_of_range exception where an empty vector is accessed at position 171. I introduced some debug-output and notice that the vector actually contains 179 elements. Is it somehow possible that Python and C++ see a different version of the vector? It is filled from C++ before calling any Python code and there is no place in the code where anything is removed from the vector, so I don't see why it should shrink in size. There is a Github issue about this where you can find a minimal example, but you need to build yosys and it is kind of big -> https://github.com/YosysHQ/yosys/issues/1094 The Python wrappers are defined in kernel/python_wrappers.cc, but it is auto-generated from a Python-script during the build, so I attached it for your convenience. Any thoughts and ideas are highly welcome! I am completely stuck and don't know where to start debugging. BR Benedikt

1 0