The ordinal 968 issue - dll

I am using openssl in a project. It works fine on one machine. However, on an xp pro machine I get:
The ordinal 968 could not be located in hte dynamic link library LIBEAY32.dll
Does anyone know how to fix this issue, is it a dependency issue on some other dll?

A Google search leads to a forum thread where someone solved this problem. This might help you to do so, too.

This Page:
http://www.slproweb.com/products/Win32OpenSSL.html
Pointed me to this:
Install the c++ 2008 redistributable and that solved the problem.

I had the similar problem, just with a different number (3906).
When I searched for all libeay32.dll files in my %PATH%, I noticed that there are quite a few installed on my system. The first in the path happened to be an older version (OpenSSL 0.9.8h 28 May 2008), installed with Gnuwin32. I renamed this file to libeay32.dll.xxx, effectively disabling this dll, and this fixed the issue for me! The next libeay32.dll on my path is a much more recent version (OpenSSL 1.0.1h 5 Jun 2014).
I wrote this little python script to find the libeay32.dll files on my system, and to determine the OpenSSL version:
import os, re
for dir in os.getenv("PATH").split(";"):
filename = os.path.join(dir, "libeay32.dll")
if os.path.exists(filename):
print("== " + dir)
with open(filename, "rb") as fh:
for line in fh:
m = re.search("OpenSSL [0-9][0-9. a-zA-Z]+", line)
if m:
print(m.group(0))
break

Related

Library not loaded: #rpath/libtbb.dylib in Prophet / Python

I'm on a Mac X1, Monterey.
I've installed prophet and run into this issue when trying to fit a model.
RuntimeError: Error during optimization: console log output:
dyld[90668]: Library not loaded: #rpath/libtbb.dylib
Referenced from: /Users/{username}/opt/anaconda3/lib/python3.9/site-packages/prophet/stan_model/prophet_model.bin
Reason: tried: '/private/var/folders/cd/dfrqgp4s4ll55cwb7rtgccbw0000gq/T/pip-install-rjpuj450/prophet_d7e4cce10e414c89a572fe3605ae9269/build/lib.macosx-11.1-arm64-cpython-39/prophet/stan_model/cmdstan-2.26.1/stan/lib/stan_math/lib/tbb/libtbb.dylib' (no such file), '/private/var/folders/cd/dfrqgp4s4ll55cwb7rtgccbw0000gq/T/pip-install-rjpuj450/prophet_d7e4cce10e414c89a572fe3605ae9269/build/lib.macosx-11.1-arm64-cpython-39/prophet/stan_model/cmdstan-2.26.1/stan/lib/stan_math/lib/tbb/libtbb.dylib' (no such file), '/usr/local/lib/libtbb.dylib' (no such file), '/usr/lib/libtbb.dylib' (no such file)
I know this has to do with the wrong paths being searched. I can find the dylib in
/Users/{user}/opt/anaconda3/lib/python3.9/site-packages/prophet/stan_model/cmdstan-2.26.1/stan/lib/stan_math/lib/tbb/
But, it seems prophet doesn't know to look there. I'm curious how I can update/fix either the rpath variable or find another solution?
I tried to create a symbolic link with sudo ln -s, but don't have permissions on the laptop.
TIA!
I got it to work on Apple Silicon (M1 Max in my case) by installing older versions of both pystan and prophet:
pip install pystan==2.19.1.1
pip install prophet==1.0
The other important piece of the puzzle is that you should use Python 3.8 to get it working.
Installing older versions of the libraries and using Python 3.8 are both talked about in issue #2002 on Github, but there's not really an explanation of the libtbb.dylib error message.

"invalid version 0 on git_proxy_options" from libgit2: cause? fix? walk-around?

I'm getting this error "invalid version 0 on git_proxy_options" from libgit2. This did not happen until very recently (I have recompiled my code so it may be a version issue). I'm not using a proxy. Does anyone know anything about this? What causes this message? Is there anything I can do to stop the failure? Either a fix or or a work-around will do.
Specifically, I am using the Rust crate git2 version 0.13.23. I am doing a fetch that triggers the error. This is on Fedora 34 on x86_64. I have searched on this but there does not seem to be any matches that help.
git2 = {version="0.13.22", features = ["vendored-libgit2"]}
in Cargo.toml fixed the issue.
Interesting...
I had upgraded libgit2 to 1.3.0 from 1.1.1. That broke my existing cargo install, so I unpacked the previous libgit2.so.1.1 with a symlink to libgit2.so.1. That's when this error condition showed up. After thinking a bit I decided to symlink libgit2.so.1.3 to libgit2.so.1.1 and it built my new cargo version which linked to the new libgit2.so.1.3. Then I deleted my libgit2.so.1.1 stuff. Kinda weird, and usually you expect things not to work when it has been linked to a previous .so version.

Unable to load dynamic library php_sqlsrv_7_nts.dll is not a valid Win32 application

Thought I'd see if there were any sql server drivers for php 7. Another question on Stack Overflow pointed me to these drivers here
So I install php_sqlsrv_7_nts.dll into my ext folder and add the following line to my php.ini:
extension=php_sqlsrv_7_nts.dll
I get this warning on every php script I run:
Warning: PHP Startup: Unable to load dynamic library 'C:\php7\ext\php_sqlsrv_7_nts.dll' - %1 is not a valid Win32 application
I realise this is just a pre-release version and there are many things to iron out still, but I was hoping to at least do some basic things.
What am I doing wrong, or do I need to wait a bit more for a better release.
Some info that might be useful:
PHP Version => 7.0.5
System => Windows NT GB275L-I-T-5654 6.3 build 9600 (Windows 8.1 Professional Edition) i586
Build Date => Mar 30 2016 09:57:56
Compiler => MSVC14 (Visual C++ 2015)
Architecture => x86
Configure Command => cscript /nologo configure.js "--enable-snapshot-build" "--enable-debug-pack" "--disable-zts" "--with-pdo-oci=c:\php-sdk\oracle\x86\instantclient_12_1\sdk,shared" "--with-oci8-12c=c:\php-sdk\oracle\x86\instantclient_12_1\sdk,shared" "--enable-object-out-dir=../obj/" "--enable-com-dotnet=shared" "--with-mcrypt=static" "--without-analyzer" "--with-pgo"
Finally got this solved. Needed to install some more things before it would work, namely:
Microsoft Visual C++ 2015 Redistributable (x86) which you can get from here
The ODBC drivers which you can get from here
It works for me.
1.Download the extension windows 7.0
https://github.com/Microsoft/msphpsql/releases
2.And then according to the system requirement paste it in ext folder.
Note: Paste only the thread safe version (php_pdo_sqlsrv_7_ts.dll , php_sqlsrv_7_ts.dll)
3.And edit the php.ini file add this extension to your php.ini file and restart and check
The extension file from Github MSPHPSQL releases did not work for me and gave me the same predicament with the OP. I went to this Microsoft article which gave me the driver (extension) for MSSQL Server, go ahead and install it on a directory you can easily find, in my case I saved it in my c:\mssql-driver then inside get the extension (DLL) file that fits your OS and PHP version, in my case since I am using PHP 7.2.x and x64 Windows I picked the following file and put it in my PHP extension directory c:\xampp\php\ext:
php_pdo_sqlsrv_72_ts_x64.dll
php_sqlsrv_72_ts_x64.dll
and in my php.ini located in c:\xampp\php\php.ini defined it under the Dynamic Extensions section:
;;;;;;;;;;;;;;;;;;;;;;
; Dynamic Extensions ;
;;;;;;;;;;;;;;;;;;;;;;
...
extension=curl
extension=php_pdo_sqlsrv_72_ts_x64.dll
extension=php_sqlsrv_72_ts_x64.dll
...
delete the "php_" on "php_sqlsrv_7_nts". just write "sqlsrv_7_nts"

Couchapp - default template not found when running `couchapp generate ...` on Windows

After thorough browsing I decided to post here as I could not find a working prompt on the problem.
I installed CouchDB and Couchapp (in version 1.0.0, freshest one on Github) on Win8 machine and when I try to run couchapp generate app contacts I get:
2014-11-21 22:01:00 [ERROR] couchapp error: Can't create a CouchApp in C:\Users\
Michal\Desktop\contacts: default template not found.
I have not so far dug deeper into the Couchapp code to see if I can fix it. Fixes applied by Couchapp creator, Benoit, don't work for me.
All advice/constructive criticism much appreciated.
OK, I got it working - all that was needed was to include an environment variable for couchapp.exe. So, if you are installing a standalone version of Couchapp from the downloads section ( https://github.com/downloads/couchapp/couchapp/couchapp-1.0.0-win.zip, e.g. ) you NEED TO MAKE SURE that you first of all execute the installer and then point you environment variables Path to it, that's all. Hope it helps.

Understanding a Bugfix for building Valgrind from source

I am trying to build Valgrind from source and ran into the same problem other's have before me. The proposed solutions where all quite hacky, though, which is not the way I like to do things.
I also found something in the Ubuntu bugtracker for the Valgrind package:
Proposed fix:
valgrind (1:3.7.0-0ubuntu2) precise; urgency=low
* Allow glibc 2.15 in the configure checks. (LP: #934127)
- Add 0009-glibc-215.patch, cherry-picked from upstream.
- Add 0010-automake-1.11.2.patch by Gregorio Guidi.
- Use dh-autoreconf instead of autotools-dev.
-- Felix Geyer <email address hidden> Fri, 17 Feb 2012 12:14:44 +0100
This was accepted as fix for the bug, so I figured it might be the real solution.
Yet I can't apply it just like that.
what means cherry-picked from upstream?
Neither searching in google nor in the downloaded source package found these patch files.
Also the last point Use dh-autoreconf instead of autotools-dev is not clear to me.
Can someone translate the solution into a more applicable form?
The easiest way would be to see if you can install the corresponding version through your package manager. If you really need to build it yourself, you will find the mentioned patches e.g. in the [..].debian.tar.gz archive.
If you look into the Ubuntu tracker, you will find:
diff -Nru valgrind-3.7.0/debian/patches/0009-glibc-215.patch valgrind-3.7.0/debian/patches/0009-glibc-215.patch
--- valgrind-3.7.0/debian/patches/0009-glibc-215.patch 1970-01-01 01:00:00.000000000 +0100
+++ valgrind-3.7.0/debian/patches/0009-glibc-215.patch 2012-02-17 12:14:29.000000000 +0100
## -0,0 +1,30 ##
+Description: add support for glibc 2.15
+Origin: upstream, http://sourceforge.net/mailarchive/forum.php?thread_name=20111229082456.D5FE6108870%40jail0086.vps.exonetric.net&forum_name=valgrind-developers
+
+Modified: trunk/configure.in
...
The SourceForge URL above tells you that this patch was committed in r.12323 to the Valgrind repo.
(The last remark about the autotools is specific to the Debian package building process, and has most likely nothing to do with your problem.)