I am porting the GCS python client lib. and suffering some problems about dependency.
Because I want to use gcs on the NAS without glibc, I got the error at the code:
from oauth2client.client import SignedJwtAssertionCredentials
the error shows the reason due to lack of gcc
I trace the code and it seems to generate cryptography relative files (like _Cryptography_cffi_36a40ff0x2bad1bae.so) at run-time from the crypto.verify.
Since the machine I used with gcc, is there any way to replace the cryptography library or I could pre-compile and generate the files at my build machine ?
Thanks!
Cause the compile errors occurred and could not solve easily, I finally use the previous pyOpenssl to solve this problem.
Related
I started getting the following warning repeatedly when running my PyTorch Lightning deep learning scripts, at execution start and then all through the training:
"OMP: Info #276: omp_set_nested routine deprecated, please use omp_set_max_active_levels instead."
I get them when executing the main.py script; my scripts are publicly available here.
Symptoms:
I don't think it has anything to do with PyTorch Lightning, maybe even PyTorch.
It appeared overnight, so I don't know what could cause it.
It runs fine without those warnings on my PC.
I get the warnings when I run from my M1 Mac.
I use VSCode for both, each up to date.
I use separate miniconda environments.
Thanks for taking the time to reply!
I managed to sort myself out in the end.
I spotted the numba package in my miniconda env, which is a Python compiler and that seemed to be the root of the problem.
It was version 0.55.2 but the last version to date is 0.56.0. Trying to upgrade it via conda or pip didn't work for some reason (the 0.55.2 version couldn't be replaced).
I recreated my env step by step, and noticed this package comes with torch-audiomentations, a package for audio data augmentation for deep learning, under torch, that I use.
Re-installing it had numba version 0.56.0 installed properly, and the warnings disappeared.
That routine is deprecated, meaning that newer standards want you to use another routine. If you can not edit the code, just ignore. For now it's only an info message. You got that message when you switched to a newer OS / compiler version / OpenMP version.
I have been trying to compile a script that was written in perl by someone other than myself into an executable format that can be used without having perl installed. There seems to be some sort of issue with Crypt::SSLeay packaging but I'm not sure what the error means. Here is a screenshot of the error message.
I've tried using PAR pp and cava to package, both will create executables that run just fine on the machine I'm using that has perl, but whenever I transfer it to a different computer I get the error seen in the screenshot. It's been the same error each time after changing compiler settings, and I'm not sure what to do at this point. If I have left anything out that may assist in answer please let me know and I will be happy to provide, coding is not my field so I am still learning and this is my first encounter with Perl.
First off, you probably do not need and should not use Crypt::SSLeay. However, both the modern Net::SSLeay and Crypt::SSLeay require OpenSSL binaries to be installed on the machine to run.
both will create executables that run just fine on the machine I'm using that has perl, but whenever I transfer it to a different computer I get the error ...
That's because the target machine does not have OpenSSL installed in the same location on which compiled the modules you are bundling.
I am trying to set up a stack project that uses the postgresql-simple package among others. When trying to stack build, all of the dependencies for postgresql-simple installed without issue, but stack is having trouble installing postgresql-simple itself. I get the following error:
C:project> stack build --extra-include-dirs="C:\PostgreSQL\8.4\include" --extra-lib-dirs="C:\PostgreSQL\8.4\lib"
... omitted ...
*****************
--extra-include-dirs=C:\PostgreSQL\8.4\include
*****************
--extra-include-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw32\include
--extra-include-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include
*****************
--extra-lib-dirs=C:\PostgreSQL\8.4\lib
*****************************
--extra-lib-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw32\lib
--extra-lib-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib
Process exited with code: ExitFailure 1
Logs have been written to: C:\Users\User\Desktop\draftkings\NFAccuracy\.stack-work\logs\postgresql-libpq-0.9.1.1.log
Configuring postgresql-libpq-0.9.1.1...
Setup.hs: Missing dependency on a foreign library:
* Missing C library: pq
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
I've tried also specifying the paths in my stack.yaml file, same error.
I've tried manually copying the library and include files from my postgres installation to the mentioned ...\mingw64\lib and ...\mingw64\include folders. Same error.
I have the files libpq.dll and libpq.lib in my C:\PostgreSQL\8.4\lib folder.
I feel like I'm missing something obvious but I can't get this to work and I'm not sure what I'm doing wrong. Any help is appreciated.
Update
I forgot to mention two important details.
First, I have added C:\PostgreSQL\8.4\bin to my PATH. As far as I know, this works as expected, because I got past an error about pg_config missing, to the error I currently have.
Second, I also tried adding the lib and include directories to my PATH, but this did not change the error.
I should also mention my Postgres installation works fine on its own.
I know that the Snowdrift project uses PostgreSQL and builds with Stack on Windows. They have a build guide on their site. It looks like one difference is that they mention:
Add the PostgreSQL bin directory to the path C:\Program Files (x86)\PostgreSQL\9.4\bin
Can you try adding that to the PATH and see if that fixes it?
There was some kind of version mismatch.
Installing Postgres 9.4 instead of 8.4 allowed the postgresql-simple package to be built in the manner I was attempting.
My stack project, without intervention by me, defaulted to using resolver: 'lts-3.7' This provided version 0.4.10.0 of the postgresql-simple package to my project. I wish I had a more detailed answer, but all I can tell is that this version of postgresql-simple (which is fairly recent) works fine with PostgreSQL 9.4 (which is also recent).
And thankfully, using haskell and postgresql-simple built against Postgres 9.4 libraries is having no issue communicating with my 'remote' (virtualbox) database which is Postgres 8.4.
I'm tempted to flag my question as not constructive unless others find this useful info.
I want to use the export_fig package for Matlab. At one point this worked, but now it's broken. The error occurs here:
>> system('pdftops -h')
dyld: Library not loaded: /opt/local/lib/libtiff.5.dylib
Referenced from: /opt/local/bin/pdftops
Reason: Incompatible library version: pdftops requires version 8.0.0 or later, but libtiff.5.dylib provides version 6.0.0
pdftops -h: Trace/breakpoint trap
But when I call pdftops from my own bash terminal everything works fine. I suppose it must be because Matlab has some bad library paths or something, but I don't know where to go from here?
Some relevant environmental vars used by matlab:
>> system('env')
SHELL=/bin/bash
OSG_LD_LIBRARY_PATH=/Applications/MATLAB_R2013b.app/sys/openscenegraph/lib/maci64
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/texbin
__CHECKFIX1436934=1
XFILESEARCHPATH=/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/locale/%L/%T/%N%S:
DYLD_FRAMEWORK_PATH=/Applications/MATLAB_R2013b.app/sys/os/maci64:/Applications/MATLAB_R2013b.app/bin/maci64/../../Contents/MacOS:/Applications/MATLAB_R2013b.app/bin/maci64:/Applications/MATLAB_R2013b.app/extern/lib/maci64:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./native_threads:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./server:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./lib/jli
SHLVL=1
__KMP_REGISTERED_LIB_33586=0x124404710-cafeb339-libiomp5.dylib
DYLD_LIBRARY_PATH=/Applications/MATLAB_R2013b.app/sys/os/maci64:/Applications/MATLAB_R2013b.app/bin/maci64/../../Contents/MacOS:/Applications/MATLAB_R2013b.app/bin/maci64:/Applications/MATLAB_R2013b.app/extern/lib/maci64:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./native_threads:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./server:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./lib/jli
If you take a look at the error message, MATLAB uses libtiff to call pdftops, but only has version 6.0.0. It says it needs version 8.0.0 or later. There has been a case where this happened before here on StackOverflow. Someone was trying to install mexopencv and has encountered the same error that you're talking about: Compiling mexopencv in OS X 10.9 with Xcode 5 and Matlab R2013b
Though this is unrelated to what you're doing, they encountered the libtiff error that you speak of. They provide two solutions how to fix this error:
Go into MATLAB's root directory, then go bin/os directory where os is the directory of the operating system you are using (in my case, it's maci64). To get into the root directory, in the command prompt do this: cd/(matlabroot). Once you're here, locate the libtiff.5.dylib file and rename it to something like libtiff.5.dylib.bak so that the libtiff libraries that are used are the ones that are default to your system rather than what MATLAB is using internally in the program.
Force MATLAB to point to the library that is part of the system rather than using the one built into MATLAB. As such, in MATLAB's command prompt, run this command:
setenv('DYLD_INSERT_LIBRARIES','/opt/local/lib/libtiff.5.dylib');
Once you do this, you may get further errors that are similar but are with other libraries. As such, you need to keep appending these libraries in the second parameter of setenv and colon-delimiting them until you resolve the issues. You need to make sure that you're pointing to the ones on your system rather than the ones installed with MATLAB. In your case, you have to do:
setenv('DYLD_INSERT_LIBRARIES', ...
'/opt/local/lib/libtiff.5.dylib:/opt/local/lib/libcurl.4.dylib');
Glad this helped!
Hi I've cross compiled Perl for my MIPS based router using Perl-cross.
Basic tests work, however the IO module is failing for some tests, notably io_sel.t, io_sock.t.
Using the debugger, I can see that the problem occurs (freezing) during a call to IO::Select::can_write(). The debugger freezes at line 122, the call to select(..).
My understanding of Perl's internals is limited, so am looking for advice on how to diagnose what the issue is. I'm assuming the issue is with the linking/wrapping against the c functions during the build?
In my experience, MIPS arch. has a lot of difficult issues for porting. So, I recommend pre-compiled perl binary and modules instead of manual build work.
Now Debian provides the Wheezy package that is minimum size( and stable) perl package file.
Debian's deb package file is just archived file. so, you can extract perl executable files/libraries from .deb packages and can install those to your router box.