I have attempted to install Psychtoolbox for Octave on Windows 10, per the installation instructions. Before the installation completes, I get this warning:
Screen() failed to work for some reason:
Check the troubleshooting instructions on our Wiki (Download section
and FAQ section, maybe also the Bugs section).
You may need to delete (or rename) the following DLL files in your Octave-4.4.1 installations
bin folder to make this work, then restart Octave:
C:\Octave\4.4.1\bin\libglib-2.0.0.dll
C:\Octave\4.4.1\bin\libgmodule-2.0.0.dll
C:\Octave\4.4.1\bin\opengl32.dll
Once you manage to fix the problem (simply type 'AssertOpenGL' to verify
that stuff works now), you do not need to run the installation routine again,
but can start working immediately.
I had already deleted the named DLL files, which I confirmed. I then ran AssertOpenGL and received this error:
Last Error: could not find library or dependencies: D:\Coding\PTB\Psychtoolbox\PsychBasic\Octave4WindowsFiles64\Screen.mex
Simply calling Screen directly gives this error:
error: library open failed: D:\Coding\PTB\Psychtoolbox\PsychBasic\Octave4WindowsFiles64\Screen.mex
However, the directory containing Screen.mex is at the very top of my path:
Octave's search path contains the following directories:
.
D:\Coding\PTB\Psychtoolbox\PsychBasic\Octave4WindowsFiles64
D:\Coding\PTB\Psychtoolbox
<etc>
As such, the solution to this similar question is of no use. What might I be able to do to correctly configure PTB on Octave?
What version of gstreamer are you using? I had a similar problem recently and fixed it by installing gstreamer 1.14.4. The latest version of gstreamer will not work, nor will versions earlier than 1.14.4.
Related
Please forgive my naivete, this is my first attempt to compile any piece of software from source. I'm a long time user of the Handlersocket Plugin for Percona (MySQL) but they stopped including it after 5.6. I'm moving up to MySQL 8 and I'm trying to compile the Handlersocket plugin from source but I'm stumbling.
First off, I've downloaded the source for handlersocket (https://github.com/DeNA/HandlerSocket-Plugin-for-MySQL), and the source for MySQL Server 8.0.17 (https://github.com/mysql/mysql-server). I've unpacked handlersocket into the /source-downloads/ folder within the MySQL source, run the included ./autoconf.sh and then ./configure, but the latter is spouting errors...
checking mysql source... configure: error: --with-mysql-source=PATH is required for standalone build
I was able to adjust the call to ./configure --with-mysql-source=../.. but now it's returning an error regarding the binaray...
checking mysql binary... configure: error: mysql_config not found! You have to specify the directory where mysql_config resides to --with-mysql-bindir=PATH.
I tried searching for the mysql_config file anywhere in the source files (find ../.. -name "mysql_config") but it's not found anywhere, what am I missing? Is the file called something else? Is there something else I'm supposed to have downloaded? I do have MySQL installed already (via YUM/DNF), can I point this at something from the existing install?
Question
Due to the issue in Fix for Octave urlread causing Peer certificate cannot be authenticated with given CA certificates, I cannot install Octave packages on Windows.
Please suggest other ways to install. Particularly I would like to go through Gradients, Gradient Plots and Tangent Planes which requires Symbolic package.
EDIT: this bug is no longer present in Octave v4.2.1, and the issue described in the Question should no longer occur.
Yes, there appears to be a known issue logged on the bug tracker with the current release version of Octave (4.2.0) on windows being unable to connect to https due to the curl issue you identified in the linked discussions/questions. That bug report and the original help list discussion summarize the certificate issue and problem verification. It should be fixed in the next Octave release.
This, however, does not prevent you from installing packages. It only prevents you from using the program to go fetch packages to be installed. You are still able to go to the Octave Forge package site, manually download a package file, and then as described in the Octave manual and help for pkg run the install command.
E.g., you could download symbolic-2.4.0.tar.gz and save it to your current working directory. Then within octave, issue the following from the command line:
pkg install symbolic-2.4.0.tar.gz
NOTE: symbolic currently requires Python and Sympy installed. If you don't already have this on your Windows machine, the package maintainer has a separate self-contained package for Windows that can be obtained from the author's github repository. In this case you would download the package and run the command:
pkg install symbolic-win-py-bundle-2.4.0.zip
Another more tedious option would be for you to compile your own copy from development sources, as the fix has supposedly been pushed to the mxe-octave repository.
I try to upgrade to the newest alpha due some testing of extensions. But I get this error, and after Googling some time, I haven't been able to find it.
Fatal error: Class 'Wikimedia\Assert\Assert' not found in /var/www/MediaWiki/includes/libs/ProcessCacheLRU.php on line 132
Since WikiMedia 1.25, some modules were extracted out of the core to vendor directory, including the assert module. To plug these, add the following line:
require_once "vendor/autoload.php";
When installing from Git, you may need to clone another repository.
I had forgot to run
composer update
I can extend this answer by saying you are running this in the prompt in the root directory of your installation. Read more on https://getcomposer.org/
I tried building recutils version 1.7 downloaded from the home page, using the standard configure, make, sudo make install sequence, but when trying to run the resulting binaries. like recinf, I get the error:
recinf: error while loading shared libraries: librec.so.1: cannot open shared object file: No such file or directory
Does this mean I made a mistake during the build or is the package itself in error?
As Etan Reisner said the problem was that the shared object libraries were installed but not loaded into the cache, hence the need to run ldconfig. After running
sudo ldconfig
the binaries ran properly. If I had looked in /usr/local/lib, I would have seen the libs there.
I compiled MySQL++ with no issues. When I launched some of the executables (resetdb.exe and simple1.exe) they suggest to run to test if the installation has been successful, the first error I got was that libmysql.dll was missing.
Adding its path to the PATH environment variable did not fix the problem, even after launching a new command prompt; I had to copy the DLL in the directory where MySQL++ executables are.
Now the DLL is found, but I get this error:
simple1.exe - Application error
The application was unable to start correctly (0xc000007b).
Click OK to close the application.
even launching from the command line, I get no more information than these.
Thank you for any help!
MySQL 5.5 -
MySQL++ 3.0.9 -
Windows 7 64 bits -
MINGW32 -
GCC 4.4.0
0xC000007B is a Windows error that means the executable is corrupted. It could refer either to simple1.exe or to one of the DLLs it's linking against.
Some reasons this could happen:
You're mixing toolchains in an incompatible way. In your case, you may have built simple1.exe using pieces built by MinGW GCC and pieces built by Visual C++. MinGW should be compatible with any pure C DLL built by Visual C++, including the MySQL C API DLL. However, you may have other pieces interfering. MinGW isn't compatible with VC++ at the C++ level, but then, it shouldn't have linked at all if this were your problem.
You didn't follow the MySQL C API import library build steps in README-MinGW.txt. You either missed a step, or skipped it entirely and are trying to use the import library that shipped with MySQL.
In your previous gyrations, you ended up with a corrupt object file, which got linked in. Try saying make clean all at the top level of MySQL++ to force a complete rebuild.
You're mixing versions of MySQL or MySQL++. If you have more than one version of each on the system, make sure you're consistent in their use. That is, build the C API import library from the same DLL you run the programs against, use exrun.bat to run the examples to ensure you're using the just-built version of the MySQL++ DLL instead of another you have in your PATH, etc.
Additionally, I note that you're using an older version of MySQL++. If you were on Linux, I could understand that as some distributions still ship with 3.0.9. But since you have to build MySQL++ from source with MinGW, I don't see why you're not using 3.1.0. Did you get a binary build from somewhere?
As for your PATH problem, did you restart the MinGW shell after doing this? PATH updates don't affect running programs; they keep the value they saw when they started.