Binary file refuses to run due to a missing shared library - configuration

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.

Related

Octave Psychtoolbox can't find Screen.mex despite being first directory in path

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.

LibGDX creating (desktop) platform runnable

I want to export may project (game) to different desktop platforms. I exported it from eclipse (on Windows) and I get JAR file. On my machine I can start it, but on other it won't work. I guess JRE is missing there.
So, I followed LibGDX instructions how to deploy on different platforms:
https://github.com/libgdx/libgdx/wiki/Deploying-your-application
But when I run that packr.jar app I get following output:
D:\packing>java -jar packr.jar windows.json
Output directory 'D:\packing\windows' exists, deleting
Unpacking JRE
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
copying resources
minimizing JRE
unpacking rt.jar
packing rt.jar
Done!
After that I really get my exe file, all together with jre dir, my original game jar file and some config.json file, but that exe file just won't run. No failure message, just won't run. Any idea what's going on here? Or maybe there is some other tool for packing jar files?
All I need is to make my game runnable on desktop platforms: Windows, Mac & Linux.
For windows OS you could use something like launch4j which simply puts a wrapper around your jar file.
It also has the capability to provide a given jre. So your users do not need to have one installed.
Ok, solved this.
So I've found out that if I run exe file from console (cmd) and redirect output to file I can have some error report regarding the run attempt. So I did that:
myapp.exe > log.txt
and get log this log file:
Loading JVM runtime library ...
Passing VM options ...
# -Xmx1G
Creating Java VM ...
Error occurred during initialization of VM
Unable to load ZIP library: D:\packing\windows\jre\bin\zip.dll
Zip file was there, but something was wrong with it so I replaced it with one I had in my Java installation (my was larger). After that I was able to run exe file well.

MySQL++ Application error at launch

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.

binary files in wix install package

I can't figure it out: do the files which are referenced in the Binary element of .wxs file get copied to the target machine, or are they resources of the install package?
They are definitely the resources of the install package. This means that they don't get installed to your application folder, but Windows Installer is supposed to extract it internally to some temporary location to address the functionality in it. And it is supposed to clean after itself. But this is definitely not visible to the end users of your installation.
At least, this is how I understand it.

APE Install Missing File

After installing from the RPM and then trying the Binary versions of APE (AJAX Push Engine) I am getting this error (on both versions) when I try to run the APE server:
[Module] Failed to load ../modules/libmod_spidermonkey.so [Invalid library] (libmysqlclient_r.so.15: cannot open shared object file: No such file or directory)
I am using Fedora Linux, with MySql and apache installed. How can I get this libmysqlclient file? I have found this RPM: http://rpm.pbone.net/index.php3/stat/4/idpl/12471829/dir/fedora_4/com/mysqlclient15-5.0.67-1.fc4.remi.i386.rpm.html
And it says it includes this file, so I downloaded it to the box, attempted to install and tells me that it's already installed.
Any advice would help thanks!
Inside the ape.conf there's a module working directory which must be altered.