Re: Execute in a multiprocessing child dynamic code loaded by the parent process
Then, you must put the initialization (dynamically loading the modules) into the function executed in the foreign process. You could wrap the payload function into a class instances to achieve this. In the foreign process, you call the instance which first performs the initialization and then executes the payload. That's what I have in mind: loading the modules first, and then unpickle and call the real target function. -- https://mail.python.org/mailman/listinfo/python-list
Re: strange problem building non-pure wheel for apple M1 arm64
On Mon, 7 Mar 2022 16:22:10 +, Robin Becker wrote: [snip] > > gcc -bundle -undefined dynamic_lookup -g -arch arm64 [snip] > -L/usr/local/lib > -L/usr/lib > -L/Library/Frameworks/Python.framework/Versions/3.9/lib > -lfreetype [snip] > > ld: warning: ignoring file /usr/local/lib/libfreetype.dylib, building > for macOS-arm64 but attempting to link with file > built for macOS-x86_64 > > The above message seems bizarre; everything is compiled for arm64, but > gcc doesn't want to use an arm64 dylib. > > Can macos experts assist? I am not at all expert in MacOS or any of the specifics of this problem, but I think you want to try to prove that the libfreetype invoked by "-lfreetype" is built for macOS-arm64 rather than for macOS-x86-64. -- To email me, substitute nowhere->runbox, invalid->com. -- https://mail.python.org/mailman/listinfo/python-list
Re: strange problem building non-pure wheel for apple M1 arm64
Am 07.03.22 um 17:22 schrieb Robin Becker: I use brew to install freetype version 2.11.1. gcc -bundle -undefined dynamic_lookup -g -arch arm64 build/temp.macosx-11.0-arm64-3.9/src/rl_addons/renderPM/_renderPM.o build/temp.macosx-11.0-arm64-3.9/src/rl_addons/renderPM/gt1/gt1-dict.o build/temp.macosx-11.0-arm64-3.9/src/rl_addons/renderPM/gt1/gt1-namecontext.o '''other compiled code build/temp.macosx-11.0-arm64-3.9/src/rl_addons/renderPM/libart_lgpl/art_vpath_dash.o -L/usr/local/lib -L/usr/lib -L/Library/Frameworks/Python.framework/Versions/3.9/lib -lfreetype -o build/lib.macosx-11.0-arm64-3.9/reportlab/graphics/_renderPM.cpython-39-darwin.so ld: warning: ignoring file /usr/local/lib/libfreetype.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64 The above message seems bizarre; everything is compiled for arm64, but gcc doesn't want to use an arm64 dylib. I would interpret this as: the host is runnig in intel, by doing the "brew install" it installs the intel version of freetype into /usr/local/lib/ ; then you cross-compile the python extension for ARM, but -lfreetype picks up the host version. On macOS it is not mandatory that all symbols in a .dylib are resolved. I would guess that the resulting file will not work on M1 macs. YOu can check by otool -L /path/toyour.dylib which libraries are referenced. If you use freetype functions in your C code and do not see it referenced, then the lib will not work. Maybe you can install an ARM-version of freetype, or compile it from source during your build process? Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: strange problem building non-pure wheel for apple M1 arm64
On 08/03/2022 16:08, Christian Gollwitzer wrote: Am 07.03.22 um 17:22 schrieb Robin Becker: I use brew to install freetype version 2.11.1. I find via google that homebrew/apple have split the installation of intel and arm64 into /usr/local and /opt/homebrew so I must modify the include_dirs & library_dirs in setup.py -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Missing global # gdal DRIVER_NAME declaration in gdal_array.py
The following warning kept coming up when running ogr2ogr. Warning 1: Missing global # gdal: DRIVER_NAME declaration in C:\Users\AppData\Local\Programs\Python\Python36\Lib\site-packages\osgeo\gdal_array.py What steps to be take to resolve this issue? Regards, David -- https://mail.python.org/mailman/listinfo/python-list
PSA: Linux vulnerability
https://arstechnica.com/information-technology/2022/03/linux-has-been-bitten-by-its-most-high-severity-vulnerability-in-years/ -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
