The GMP configuration by MSYS2 remains incomplete - configuration

I'm using Windows 7 and the latest version of MSYS2.
For my work I needed to install GMP with MSYS2.
After installing and decompressing, I had to configure the GMP folder with the ./configure command.
But the problem is that the process starts and always stops at this point.
This line is actually one of the configuration preparations where the program stops.
What is the problem and how can it be fixed?
I think I provided enough information. If more information is needed, I can provide it.
Thanks

Related

Octave gets stuck on Busy... inside TeXmacs in Windows OS

I have TeXmacs and Octave installed, both working properly otherwise. I have also added the path to octave executable (i.e. C:\Octave\Octave-5.1.0.0\mingw64\bin) to the Windows environment variables and octave runs in cmd/PowerShell terminals and Jupyter with no hassle. However, when running Octave inside TeXmacs through Toolbar > insert > session > octave it gets stuck on Busy..., the same reaction for any other commands as well:
Octave gets stuk on Busy... inside TeXmacs.
This is my environment:
TeXmacs 1.99.9
Octave 5.1.0 (installed through Chocolatey)
Windows 10 version 1809
I would appreciate if you could help me know what is the problem and how I can solve it.
P.S. I have reported this issue in the TeXmacs repo.
#Foad. I wrote an updated Octave plugin for Texmacs. I tried it on Windows, OSX and Linux, works on the systems I have access to. If you are interested to test it, you can download the zipped archive from here https://lists.gnu.org/archive/html/texmacs-dev/2019-12/msg00005.html.
To install it, unzip the archive and copy the octaveX directory in the application plugins folder, alongside all the plugins that come with the standard Texmacs installation. Won’t work if installed in ~/.Texmacs/plugins. If everything goes fine, you should find a new Insert/Session/OctaveX menu (note: I changed the session name). If not, try to refresh the plugin system with the menu Tools/Update/Plugins. If you try it, please let me know, especially if you find troubles. In case I will do my best to fix them.
A fundamental prerequisite is a working octave-cli command in a operating system shell. Should be standard on Linux, may require some additional setup on Windows (environmental variables) or OSX (.bash_profile). You can find some help and more details under the menu Help/Plug-ins/OctaveX.
Concerning the error you found, as far I understand there are some issues with the standard distributed plugin: first, a .octaverc file is missing, so several variables are not initialized, in addition the Windows version calls a not existent file. Moreover the plotting functions are quite old and are not compatibile with Octave newer than version 2 (or maybe 3, anyway a quite old version).
You could try to run the command in
%TEXMACS_PATH%/plugins/octave/bin/tm_octave.bat
from the terminal to see what happens. There is a problem with this plugin and it does not work also on Mac but I do not know enough Octave to fix it. Somehow it does not manage to find the files which are in
%TEXMACS_PATH%/plugins/octave/octave
Please try to modify tm-start.m to look like
d=getenv("TEXMACS_PATH");
if (length(d) > 0)
addpath("tm:polynomial:plot")
tmrepl
endif
In windows, octave should be run using the scripts octave.bat (in the mingw64\bin directory of the octave install) or octave.vbs (in the install directory) for the GUI
You should not run octave.exe directly.

Octave 4.2.1 octave-gui : cannot find libgfortran.so.3

I am currently having an issue with Octave install in Archlinux. I am not able to load the current version of Octave 4.2.1 in Arch. It shows the following message -
/usr/lib/octave/4.2.1/exec/x86_64-pc-linux-gnu/octave-gui: error while loading shared libraries: libgfortran.so.3: cannot open shared object file: No such file or directory
This problem with libgfortran.so.3 is not rare. Here are two similar problems happening in R 1 and 2. If somebody using Octave on Archlinux came across this issue, can you share how to resolve it. Thanks.
From the comments it became apparent that the solution from the referenced question R v3.4.0-2 unable to find libgfortran.so.3 on Arch needs to be appended, because the way the older GCC versions will be typically installed in Arch Linux is in a different path.
So, one must find, where the older version is installed, like
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libgfortran.so.3
(depending on the exact GCC version)
and then add the version to LD_LIBRARY_PATH or make a symlik of the library from the above path to /usr/lib64/.
I got this issue because I installed earlier additionally openblas-lapack from AUR for better octave matrix multiplication performance. Updating openblas-lapack to newest version in AUR did the trick for me.

Octave - How to install packages on Windows

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.

Using synce-install-cab in fedora to install cab file

I have Fedora 20 and want to install a .cab file. I found the proper way to do this is with synce (http://linuxmanpages.net/manpages/fedora21/man1/synce-install-cab.1.html). However when I type:
synce-install-cab - install .cab data.cab
or
synce-install-cab - install data.cab
I get the following message:
Enter .cab file as parameter
How can I install my cab file properly?
Thanks in advance.
Okay, so, two things.
First, are you sure this is the command you want? This command is for installing software in .cab files to Windows CE devices. If you don't have that, maybe you want cabextract (although that won't, of course, make Windows software actually run on Fedora).
Second... I don't know this actual command (as I don't have a a Windows CE device), but, from the man page you linked, there's no reason to run synce-install-cab - install .cab data.cab — that's not instructions, it's just the summary at the top of the file. The actual command seems simply to be
synce-install-cab data.cab

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.