I try to cross-compile libplist (https://github.com/libimobiledevice/libplist) for 64-bit Windows and create a DLL from it. I downloaded mingw-w64 for Linux subsystem on Windows 10 (Ubuntu 14.04 bash) and set the environment variables (CC, CXX, CPP, RANLIB). I use ./autogen.sh --host=x86_64-w64-mingw32 to configure package. However it exits with the error:
configure:16825: error:
Could not link test program to Python. Maybe the main Python library has been
installed in some non-standard library path. If so, pass it to configure,
via the LDFLAGS environment variable.
Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib"
============================================================================
ERROR!
You probably have to install the development version of the Python package
for your distribution. The exact name of this package varies among them.
============================================================================
In config.log it says:
configure:16813: x86_64-w64-mingw32-gcc -o conftest.exe -g -O2 -I/usr/include/python2.7 -I/usr/include/x86_64-linux-g$
In file included from /usr/include/python2.7/Python.h:8:0,
from conftest.c:33:
/usr/include/python2.7/pyconfig.h:78:3: error: #error unknown multiarch location for pyconfig.h
# error unknown multiarch location for pyconfig.h
^
In file included from /usr/include/python2.7/pyport.h:4:0,
from /usr/include/python2.7/Python.h:58,
from conftest.c:33:
/usr/include/python2.7/pyconfig.h:78:3: error: #error unknown multiarch location for pyconfig.h
# error unknown multiarch location for pyconfig.h
^
In file included from /usr/include/python2.7/pymath.h:4:0,
from /usr/include/python2.7/Python.h:77,
from conftest.c:33:
/usr/include/python2.7/pyconfig.h:78:3: error: #error unknown multiarch location for pyconfig.h
# error unknown multiarch location for pyconfig.h
^
configure:16813: $? = 1
It doesn't return this error when I try to compile it for Linux, so I thought that it's because it needs python libraries compiled for Windows x86_64. I copied the appropriate files from Windows from C:/Python27/include and tried to set environment variable for configuration LDFLAGS="-L/path/to/python/include" and PKG_CONFIG_PATH=/path/to/python/include separately. Neither of them worked. I also noticed, that in C:/Python27/include there was also a file called pyconfig.h.Why does the script uses the one installed on Linux? Is there a way I could force it to use the other one?
My main objective would be to make a 64-bit Windows DLL from libusbmuxd (https://github.com/libimobiledevice/libusbmuxd), but it needs libplist to be compiled too. How could I solve this issue? Thanks for the answers in advance.
You can try libimobiledevice-win32. Although the name is a bit confusing, it builds 32-bit and 64-bit Windows versions of libimobiledevice.
You can compile libplist, libusbmuxd, libimobildevice and the various utilities for Windows using Visual Studio, avoiding the need to cross compile.
The company I work for, Quamotion, maintains libimobiledevice-win32 and we try to stay on track with the latest upstream changes.
You can download precompiled versions from the CI build, see e.g. https://ci.appveyor.com/project/qmfrederik/imobiledevice-net/build/artifacts for zip files which contain the latest bits.
Related
Essentially, trying to write the following code results in the error below:
Code
from matplotlib import pyplot as plt
plt.plot([1,2,3,2,1])
plt.show()
Error
libGL error: MESA-LOADER: failed to open iris: /home/xxx/.conda/envs/stat/lib/python3.8/site-packages/pandas/_libs/window/../../../../../libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /usr/lib64/dri/iris_dri.so) (search paths /usr/lib64/dri, suffix _dri)
libGL error: failed to load driver: iris
libGL error: MESA-LOADER: failed to open swrast: /home/xxx/.conda/envs/stat/lib/python3.8/site-packages/pandas/_libs/window/../../../../../libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /usr/lib64/dri/swrast_dri.so) (search paths /usr/lib64/dri, suffix _dri)
libGL error: failed to load driver: swrast
I found similar errors on StackOverflow but none were what is needed here.
The solution proposed by Mahyar Mirrashed is working for me.
On my system (Ubuntu 22.04) the libstdc++.so.6 file is located in /usr/lib/x86_64-linux-gnu/libstdc++.so.6
To know where to find this file I suggest to run the following command :
find / -name libstdc++.so.6 2>/dev/null
which resulted with files from miniconda, snap and /usr/lib/...
I added the export LD_PRELOAD to my .bashrc file and it's working fine.
export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libstdc++.so.6
Installing libstdcxx-ng from conda-forge should solve this problem.
Command:
conda install -c conda-forge libstdcxx-ng
Short answer: export LD_PRELOAD=/usr/lib64/libstdc++.so.6
Long answer:
The underlying problem is that we have a piece of software that was built with an older C++ compiler. Part of the compiler is its implementation of libstdc++ which becomes part of the runtime requirements for anything built by the compiler. The software in question has, evidently, brought its own, older implementation of libstdc++ along for the ride, and given its libstdc++ precedence over the system's libstdc++. Typically, this is done via the $LD_LIBRARY_PATH environment variable. Unfortunately, /usr/lib64/dri/swrast_dri.so is a piece of system software built by the native compiler for that system, and it's more recent than the compiler that built the other software in question. The result of this is that the older compiler's libstdc++ gets loaded first, with its older, more limited symbol set. When it then wants to load swrast, this fails because swrast insists on having the level of compiler/runtime with which it was built. The solution to this whole mess is the force the system's (newer) libstdc++ into use and prevent the older libstdc++ from being brought into play. This is achieved via the code snippet export LD_PRELOAD=/usr/lib64/libstdc++.so.6 where we set the preload environment variable.
I have been struggling with this problem for several days. Basically, what I would like to do is to call a shared dll library using python. I created the dll using mingw32-make and the makefile is as follows:
CC=gcc
CFLAGS=-shared -fopenmp -L./
LIBS=-lpthread libopenblas.a
OPTIM=-O3
CURRENT_PATH=$(shell cd)
INITMODEL=$(CURRENT_PATH)/c_call/init_model.c
SRC=$(INITMODEL)
DEST=offline.dll
$(DEST): $(SRC)
$(CC) $(CFLAGS) $(OPTIM) -o $(DEST) $(SRC) $(LIBS)
The compilation worked through but when I called the dll using python, I got an error:
FileNotFoundError: Could not find module 'C:\Users\zhenh\Desktop\RTLoc\client\src\offline.dll' (or one of its dependencies). Try using the full path with constructor syntax.
Then, I found python CDLL managed to load the dll when I remove linking "libopenblas.a" from the compilation. So I guess the problem may be due to that I did not compile openblas right. So I went to msys2 MinGW 32bit and compiled the openblas with mingw32-make, which it is for native windows. But when I put the newly compiled libopenblas.a in the makefile, CDLL gave the error again.
I also tried to link libopenblas.dll and failed. And openblas is the library I need to use so there are no ways to get rid of it.
The Python version is 3.8.7 and I have used os.add_dll_directory to include the folder having the dll I generated. Thanks everyone for giving me some idea how to fix this?
It worked when I switched to Anaconda Powershell Prompt.
I am trying to install the openWSN platform on my MAC OS X, to be able to run tests in a simulated (or real) sensors network. For that, is necessary the Python development headers and libraries. In fact, I think the headers are already installed, as I have already downloaded XCode, Command Line Tools, Homebrew, and I already downloaded the Python.
I am using SCons to construct the software application.
The big problem is that when I type this command on the terminal:
$ scons board=python toolchain=gcc oos_openwsn
The processing seems to be going well, when I receive the following warning and error:
File "/Users/stage/Desktop/openwsn/openwsn-fw/SConscript", line 578, in sconscript_scanner
scons: done reading SConscript files.
scons: Building targets ...
Linking (shared) firmware/openos/projects/common/oos_openwsn.so
**ld: warning: directory not found for option '-L/Library/Frameworks/Python.framework/Versions/2.7/libs'**
ld: unknown option: -Bsymbolic-functions
clang: error: linker command failed with exit code 1 (use -v to see invocation)
scons: *** [firmware/openos/projects/common/oos_openwsn.so] Error 1
scons: building terminated because of errors.
The problem to me seems to be in the libs folder, as if the scons could not find this folder, and cannot proceed.
I checked the SCons files for the project https://github.com/openwsn-berkeley/openwsn-fw that you seem to be using. I don't see any hints that the compilation and installation of sources is supported for MacOS. Are you sure that the project supports your OS? If you are, you should consider asking the project's maintainers for help, e.g. via ML or IRC.
The main error in your output above is the "ld: unknown option: -Bsymbolic-functions". Since you specified "toolchain=gcc" in your call, this is what the build expects...but you don't seem to have a proper gcc installed. The clang compiler that is found instead doesn't know the provided command-line option, and stops with an error.
I'd like to use graph-tool on windows 7, but I'm having trouble installing it.
All the requirements listed here are successfully installed. Python 2.7 is installed in C:\python27. Boost 1.49.0 was successfully compiled with mingw, installed in C:\boost and the BOOST_ROOT environment variable is pointing to it. Boost is compiled in debug and release mode and both static and dynamic.
Invoking configure from within MSyS leads to the following error.
configure: error:
Could not link test program to Python. Maybe the main Python library has been
installed in some non-standard library path. If so, pass it to configure,
via the LDFLAGS environment variable.
Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib"
============================================================================
ERROR!
You probably have to install the development version of the Python package
for your distribution. The exact name of this package varies among them.
============================================================================
Calling configure LDFLAGS="-LC:/python27/libs" fixed this error, but lead to the following error
checking for boostlib >= 1.38.0... configure: error: We could not detect the boo
st libraries (version 1.38 or higher). If you have a staged boost library (still
not installed) please specify $BOOST_ROOT in your environment and do not give a
PATH to --with-boost option. If you are sure you have boost installed, then ch
eck your version number looking in <boost/version.hpp>. See http://randspringer.
de/boost for more documentation.
This is weird, since BOOST_ROOT is clearly defined (checked it with printenv command).
The next command I tried was configure --with-boost="C:/boost" LDFLAGS="-LC:/python27/libs"
checking for boostlib >= 1.38.0... yes
checking whether the Boost::Python library is available... no
configure: error: No usable boost::python found
Alright it detects boost, but It can't find boost::python. Due to its size I'm unable to post the config.log on stackoverflow but you can find it here.
I'm really confused right now and would appreciate any help.
I have zero experience with compiling graph-tool (or anything else) for windows, but the following part of your config.log stands out:
configure:17224: checking whether the Boost::Python library is available
configure:17254: g++ -c -Wall -ftemplate-depth-150 -Wno-deprecated -Wno-unknown-pragmas -O99 -fvisibility=default -fvisibility-inlines-hidden -Wno-unknown-pragmas -Ic:\python27\include conftest.cpp >&5
conftest.cpp:32:36: fatal error: boost/python/module.hpp: No such file or directory
compilation terminated.
Note how the boost path you passed is not being used! Try to pass CXXFLAGS="-IC:\boost\include" to configure as well.
May be something like this would help:
./configure --prefix=/usr/
for windows path is different, try it yourself.
I have been having a terrible time trying to compile a python extension - hopefully someone can help.
I initially tried executing 'python.exe setup.py build' but received the error: 'Python was built Visual Studio 2003; extensions must be built with a compiler that can generate compatible binaries...".
So I then downloaded Cygwin, and have tried sending the switch '-c mingw32'. A few lines were written into the console - then I get the error message: command 'gcc' failed: Permission denied.
I was initially using the Visual Studio 2010 Command Line to do this, but tried with bash and got the same result.
I have spent a considerable amount of time researching the issue, and it appears Cygwin uses symlinks for gcc and g++, and windows doesn't understand how to handle this.
How exactly can I force setup.py to use gcc-3.exe instead of the gcc.exe symlink?
I know it's inelegant, but you can rename the symlink and copy gcc-3.exe to gcc.exe. That worked for me when I used Cygwin's gcc. You might want to switch to the mingw64-i686 (or mingw64-x86_64) package to get gcc 4.5.3, or just install MinGW-w64 separately for compiling under Windows.
Also, you can permanently configure distuilts in PythonXX\Lib\distutils\distutils.cfg:
[build]
compiler = mingw32
[build_ext]
compiler = mingw32
[build_clib]
compiler = mingw32