I'm using Omnet++ and Veins for simulations and it was working fine until I upgraded from Ubuntu 15 to 16.04 LTS last night. Now, I get the following error when trying to run a simulation: error while loading shared libraries: libmpi.so.1: cannot open shared object file: No such file or directory
I searched for libmpi.so.1 and it seems it is missing. There is a file libmpi.so and libmpi.so.12 in /usr/lib/openmpi/lib but not libmpi.so.1. I tried uninstalling and reinstalling the packages openmpi-bin, libopenmpi-dev as well as OpenMPI which I downloaded from the website. I also set the variable in bashrc and profile (which was recommended online) with export LD_LIBRARY_PATH:=$PATH:/usr/lib/openmpi/lib/
None of these approaches worked and I still get the same error. Any suggestions on how to fix it and how to get the file libmpi.so.1?
I could fix the problem by adding a symbolic link libmpi.so.1 in /usr/lib that points to the existing libmpi.so.12 (which again points to the location of the actual file in openmpi/lib).
Apparently, it was a problem with the version of OpenMPI since on my other system, which I didn't update, there was a symbolic link libmpi.so.1 pointing to libmpi.so.1.0.8 (but no libmpi.so.12).
Related
I downloaded Crystal with brew I don't think the error is related to that
/usr/bin/ld: warning: libpcre.so.3, needed by /lib/x86_64-linux-gnu/libglib-2.0.so.0, may conflict with libpcre.so.1 /root/.cache/crystal/crystal-run-build_namespace.tmp: error while loading shared libraries: libgc.so.1: cannot open shared object file: No such file or directory
When I get this error. When I type ./setup_dependencies.sh
I have tried so many ways I still can't figure it out I tried deleting Crystal and reinstalling it again but it didn't work because most likely the error is not there and I'm new to linux
I'm not sure if you are the same person (BySylex) as the author of this issue https://github.com/phil294/AHK_X11/issues/20, but anyway, you will find the solution in there. This is not your fault, but at the same time, you probably do not need to run ./setup_dependencies. Instead, you can download AHK_X11 directly from the release section without having to build from source.
Since I installed according to the guide here on wsl2 ubuntu 20.04, I've been having errors related to libstc++.so.6, specifically GLIBCXX_3.4.26 not found (required by ...) where ... refers to different files within /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/ ending in .so, .so.1, .so.6 and so on (for instance, when running paraFoam the error would appear with respect to about 20 such files). I am able to successfully visualize the cavity tutorial (in paraview installation on windows).
I could get the errors to go away by doing what the user laborg suggested on Jan 4 for a similar problem with julia (see here), specifically copy libstdc++.so.6 from /usr/lib/x86_64-linux-gnu to /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/.
The questions is whether this copy-paste solution is recommended; will it come back and haunt me later? Is the libstdc++.so.6 from system installation going to be an issue if used in the lib64 folder of openfoam?
An additional info concerning openfoam installation, foamInstallationTest shows *not installed* errors against flex, wmake, gcc, g++, icoFoam and *critical error* for gcc, g++, icoFoam; but I as given here, foamInstallationTest is not meant for installation from the tar file. Openfoam installation seems to be alright based on the running of the cavity tutorial.
ok, please don't do copy past operation to solve this problem. The error means that you haven't installed the pre request libraries in your ubuntu. It seems that you have missed the first step in the tutorial.
It is not recommended but it will not hurt as long as the GLIBC versions returned from this command
strings /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6 | grep GLIBC
are a subset of the GLIBC versions from this command.
strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBC
which was no doubt the case for your Ubuntu setup.
A less risky route would be to redirect the soft link /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6 to point to your other libstdc++.so.6 (that way you retain both versions)
ln -sf /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /opt/OpenFOAM/ThirdParty-v2006/platforms/linux64/gcc-6.3.0/lib64/libstdc++.so.6
Then, if you hit an issue, you can always reset the link back to its original target. Of course /usr/lib/x86_64-linux-gnu/libstdc++.so.6 is itself a soft link, but you can point to it all the same or you can point to its target.
I believe the issue you are hitting is a derivative of the one mentioned here https://www.cfd-online.com/Forums/main/229027-persistence-glibcxx_3-4-26-not-found.html, which would point towards the fact that it is not an installation error on your part but an issue related to the packaging of the OpenFoam binaries. I agree it would screw up the wsl2 setup owing to the way OpenFoam prepends everything to paths. Of course the safest route is to compile from source using the Ubuntu system's gcc and thereby bypass the ThirdParty.
Seeing as you are using Ubuntu in the WSL instance, could also just install the Ubuntu package directly:
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian
This problem comes from this line in the tutorial:
echo "source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc" >> ~/.bashrc
This will point to OpenFOAM's libstdc++ everytime you open a terminal (or start a WSL2 session). If your workflow is not related to OpenFOAM, that can be an issue. If you remove or comment that line in your ~/.bashrc things should get back to normal. You can use nano in WSL2.
nano ~/.bashrc
Then comment:
#source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc
However, as OpenFOAM uses that bashrc, you will need to source the OpenFOAM bashrc in each terminal before using openFOAM.
source /opt/OpenFOAM/OpenFOAM-v2012/etc/bashrc
My personal choice is to keep that line commented and, if I have a long work session using OpenFOAM, I just use nano to uncomment it, so every shell that I open works without sourcing again.
There are more elegant or complex approaches, but I prefer this one.
This answer should be valid with the 2006 version too, the link you shared points to 2012, so I guess they just updated the tutorial. If you installed 2006, just make sure when you source comment/uncomment to use the correct name.
In the same manner, if you followed another tutorial with another tool and sourced another library, you may experience issues.
Just start by taking a look at your bashrc and cleaning it.
Before marking this as a duplicate, hear me out :)
I have some years experience working with PHP on windows, and have even created a portable (for Windows) distribution of an AMP stack: https://thejaka.com/tzwamp/ which I named "WAMP Zero" or TZWAMP. I've used this WAMP distro extensively, and people I know are using it as well. The last (previous) distribution works fine, but when I tried to update the distro to the latest builds of the applications/components from the vendor/distributor sites, I hit a snag. The PHP extensions aren't loading anymore on the new distro. It seems one or more dependencies are not locatable but I don't know what or where from. I tried viewing php_mbstring.dll in a dependency viewer, but couldn't figure out what was the matter. There were a few missing dependencies, but most seemed to be from CRT and I've installed the latest. I'm guessing the missing dependencies can be resolved from PATH environment variable. The following are not loading:
php_mbstring.dll php_mysqli.dll php_openssl.dll php_pdo_mysql.dll
php_mbstring.dll php_mysqli.dll php_openssl.dll php_pdo_mysql.dll
The error messages are like: PHP Warning: PHP Startup: Failed to load ......\php\ext\php_mbstring.dll, The system cannot find the file specified.
Before you start complaining about the relative path, note that on 7.3 it worked fine.
The path to the ext dir is specified relatively, but the path seems to be correct. The same path worked fine in the previous distro of TZWAMP, and when I change the path, the error messages also change leading me to believe the path is correct. Note also that I tried adding php path to PATH environment variable as well.
The successfully working PHP version is 7.3.10.
The problematic PHP version is 7.4.2.
Apache version is 2.4.41
Is anyone aware of any relevant change from 7.3.* to 7.4.*, or else can anyone help me debug the issue and resolve it?
EDIT: I've checked and an absolute path seems to work. However, in order to make this portable, a relative path is required. Relative paths worked with 7.3 and I believe prior major versions. Any ideas?
I've solved this for now to my requirements by using an Environment Variable substitution.
extension_dir = "${P}\php\ext"
However, a relative path solution would also be welcome.
I have switched from omnet++5.3 to omnet++4.6. I am using Castalia 3.3.
My installation for the first version of omnet++5.3 was ok with castalia. But when I install the second version and build castalia with it, I have got errors. When I type the command which opp_makemake to verify the path, I got /home/hana/omnet-5.3/bin/opp_makemake instead of /home/hana/omnet-6.4/bin/opp_makemake.
I have changed the path and follow the installation guide for both omnet++ and castalia but still castalia wouldn't run correctly.
Any idea or direction that can help me is appreciated !
Thank you
I have found the error:
when adding the new path of the new version of installed omnet++4.6 in the .bashrc file, I should delete the older path of the other version of omnet++5.3 (even if it is still installed)
.bashrc doesn't accept two paths for the same software. That works !
I have been trying to test a code to connect to MySQL using C++ on a MacBook Pro, but I always get an error about boost/filename.hpp not found. I fix that by adding a full path on e.g. /usr/local/boost_1_64_0/boost/filename.hpp.
This fixes an error for one #include, when I compile again I get the same error on another line.
It will take me forever to do that (correcting the path all the time). I then downloaded MySQL-Connector-C++ using brew - which is now located at /usr/local/Cellar/mysql-connector-c++/1.1.9/.
Within the Cellar folder there are boost, mysql, openssl directories.
Can anyone please tell me how I can use this to test my code, run a simple query, and where do I put my c++ file I've created and need to compile?
I have written the code but I can't test it, it's private and for an organization which gave me the task.
I have been trying to figure out how to avoid correcting paths for more than three days now, followed all the instructions from the manual from the MySQL website.