I installed and used Theano 0.7 and everything was working perfectly. But now for the purpose of my future works, I need the bleeding edge version, and the installation went fine.
But when I run this little test (found into the Theano documentation), it generates many errors (see here for the full list).
We can observe that the GPU is detected and used, but cuDNN is not found anymore:
Using gpu device 0: GeForce GT 650M (CNMeM is enabled with initial size: 65.0% of memory, CuDNN not available)
And then I have an import error, I think it is also about cuDNN:
ImportError: ('The following error happened while compiling the node', <theano.sandbox.cuda.DnnVersion object at 0x114d32710>(), '\n', 'dlopen(/Users/FiReTiTi/.theano/compiledir_Darwin-13.4.0-x86_64-i386-64bit-i386-2.7.11-64/tmpwmA_hw/265abc51f7c376c224983485238ff1a5.so, 2): Library not loaded: #rpath/libcudnn.4.dylib\n Referenced from: /Users/FiReTiTi/.theano/compiledir_Darwin-13.4.0-x86_64-i386-64bit-i386-2.7.11-64/tmpwmA_hw/265abc51f7c376c224983485238ff1a5.so\n Reason: image not found', '[<theano.sandbox.cuda.DnnVersion object at 0x114d32710>()]')
I've checked and cudnn.h is still in /Developer/NVIDIA/CUDA-7.5/include/, in /Developer/NVIDIA/CUDA-7.5/lib/ we still find libcudnn.dylib which is a symbolic link to libcudnn.4.dylib, and everything in /usr/local/cuda points to /Developer/NVIDIA/CUDA-7.5/
Any idea?
[EDIT] In my .profile we find:
export DYLD_LIBRARY_PATH=/Developer/NVIDIA/CUDA-7.5/lib:$DYLD_LIBRARY_PATH
export DYLD_LIBRARY_PATH=/usr/local/cuda/lib:$DYLD_LIBRARY_PATH
In /usr/local/cuda/lib there is a symbolic link to the cudnn library that is actually in /Developer/NVIDIA/CUDA-7.5/lib.
Here is the result from the command tool -L libcudnn.4.dylib:
libcudnn.4.dylib:
#rpath/libcudnn.4.dylib (compatibility version 0.0.0, current version 4.0.7)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.14.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
And here is the link between: /usr/local/cuda/lib/libcudnn.dylib -> /Developer/NVIDIA/CUDA-7.5/lib/libcudnn.dylib, and in /Developer/NVIDIA/CUDA-7.5/lib I have libcudnn.dylib -> libcudnn.4.dylib
[EDIT 2]
$ echo $DYLD_LIBRARY_PATH
/usr/local/xuggler/lib:/usr/local/cuda/lib:/Applications/IMOD/lib:
$ echo $LD_LIBRARY_PATH
/usr/local/cuda/lib:
[EDIT 3] Here is the last error displayed. At least one part, because this error appears at each epoch.
With ls -la /usr/local/cuda/lib:
lrwxr-xr-x 1 root wheel 45B 22 fév 11:42 libcudnn.dylib -> /Developer/NVIDIA/CUDA-7.5/lib/libcudnn.dylib
lrwxr-xr-x 1 root wheel 48B 26 fév 01:01 libcudnn_static.a -> /Developer/NVIDIA/CUDA-7.5/lib/libcudnn_static.a
This looks like a bug in Theano. It probably would work if they added ["-Wl,-rpath,%s" % l for l in c_lib_dirs()] to the compile args. You should report that upstream here.
It might work as a workaround if you add the path of libcudnn.4.dylib to your LD_LIBRARY_PATH (or maybe DYLD_LIBRARY_PATH) environment variable, because that is where #rpath will also look at, so that the path #rpath/libcudnn.4.dylib can be resolved.
Related
I'm trying to get into the VUnit stuff and have been playing around with some tutorials which worked nicely so far. So, I became curious and found the example array_axis_vcs inside the VUnit GitHub repo. First things first, I cloned the VUnit nightly (02/13/23) and tested the example without any changes to it, using GHDL V1.0.0 which is the Ubuntu 22.04 default version. The result is that the example fails on execution of run.py *.test with the following output:
Starting lib.tb_axis_loop.test Output file: /home/me/vunit/examples/vhdl/array_axis_vcs/vunit_out/test_output/lib.tb_axis_loop.test_260bb5c8c675e898eca5dc9024a4420ede12c0bc/output.txt
******************** GHDL Bug occurred ***************************
Please report this bug on https://github.com/ghdl/ghdl/issues
GHDL release: 1.0.0 (Ubuntu 1.0.0+dfsg-6) [Dunoon edition]
Compiled with GNAT Version: 10.3.1 20211117
Target: x86_64-linux-gnu
/home/me/vunit/examples/vhdl/array_axis_vcs/
Command line: /usr/bin/ghdl-mcode --elab-run --std=08 --work=lib
--workdir=/home/me/vunit/examples/vhdl/array_axis_vcs/vunit_out/ghdl/libraries/lib
-P/home/me/vunit/examples/vhdl/array_axis_vcs/vunit_out/ghdl/libraries/vunit_lib
-P/home/me/vunit/examples/vhdl/array_axis_vcs/vunit_out/ghdl/libraries/osvvm
-P/home/me/vunit/examples/vhdl/array_axis_vcs/vunit_out/ghdl/libraries/lib tb_axis_loop tb
-gtb_path=/home/me/vunit/examples/vhdl/array_axis_vcs/src/test/
-grunner_cfg=active python runner : true,enabled_test_cases : test,output path : /home/me/vunit/examples/vhdl/array_axis_vcs/vunit_out/test_output/lib.tb_axis_loop.test_260bb5c8c675e898eca5dc9024a4420ede12c0bc/,tb path : home/me/vunit/examples/vhdl/array_axis_vcs/src/test/,use_color : true --assert-level=error Exception SYSTEM.ASSERTIONS.ASSERT_FAILURE raised Exception information: raised SYSTEM.ASSERTIONS.ASSERT_FAILURE :
ortho_code-x86-emits.adb:1724 Call stack traceback locations:
0x7f1b6d0c1542 0x5605bde1ce35 0x5605bde1ede4 0x5605bde1ff55 0x5605bde15a9f 0x5605bde15c4f 0x5605bde08ef8 0x5605bde214df 0x5605be0d0c82 0x5605be0e3957 0x5605be078bd5 0x5605be0e39b2 0x5605be0d1bef 0x5605be0bc882 0x5605be0cddbe 0x5605be0c80a0 0x5605be10db55 0x5605be04c250 0x5605bdf8469e 0x5605be1114b3 0x5605bdd3cb07 0x7f1b6cc43d8e 0x7f1b6cc43e3e 0x5605bdd3b243 0xfffffffffffffffe
******************************************************************
Ok, maybe the pretty outdated GHDL Version is a problem here? Let's try the latest GHDL nightly. Perhaps it's already solved there. That's what I thought and downloaded the latest GHDL nightly to a clean testVM and also downloaded the latest VUnit there.
Different setup, different (more interesting) issues.
VUnit appears to be unable to identify the LLVM backend of ghdl:
me#testVM:~\testprj$ python run.py *test
ERROR - Could not detect known LLVM backend by parsing 'ghdl --version' Expected to find one of dict_keys(['mcode code generator', 'llvm code generator', 'GCC back-end code generator'])
== Output of 'ghdl --version'============================================================
GHDL 3.0.0-dev (2.0.0.r1367.g803edb716) [Dunoon edition]
Compiled with GNAT Version: 10.4.0
llvm 14.0.0 code generator
Written by Tristan Gingold.
Copyright (C) 2003 - 2022 Tristan Gingold.
GHDL is free software, covered by the GNU General Public License.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. =========================================================================================
For my current work, I'll go and try a prebuild docker container now, but I'm still interested in solving this issue. Any ideas? Anybody tried the actual VUnit build against the actual ghdl build? I would be interested if it is a concern on my machine or a more general difficulty.
Greets Stefan
I'm playing with a couple of projects that explicitly require pytorch == 1.0.0, but I have an old graphics card that only supports cuda 3.0 so I'm using the cpu, which is very slow, being the graphics card a dual gpu I decided to give a try and build pytorch from the sources with support for 3.0 (I have planned to update the pc but is not gonna happen anytime soon).
I am using docker to do the build, in particular I tried to modify an existing Dockerfile from build-pytorch, on the host system I am using debian/sid and there is cuda 10.2 cudnn 7.6 installed, I'm not sure if I can downgrade cuda, and I don't know if the versions in the container must be exactly the same as the host (like for nvidia drivers).
Gist of the modified Dockerfile
The first thing I noticed when updating the versions is that package cuda-cublas-dev-10-2 was not found, the latest version was 10-0,
CUBLAS packaging changed in CUDA 10.1 to be outside of the toolkit installation path
If I install cublas version 10-0 or if I don't install it obviously no header files are found (error below), if I install the recommended libcublas-dev version the build continues for a while, with some warnings (below) , but then it stops with the error below.
I searched for the error online but I did not find anything specific, if I understand correctly there is a function declared more than once and when it is called the choice is ambiguous, but I have not yet investigated looking at the sources.
I would like to know if anyone has run into this error before and knows how to fix it.
libcublas-dev installed error:
[ 67%] Building NVCC (Device) object caffe2/CMakeFiles/caffe2_gpu.dir/__/aten/src/ATen/native/sparse/cuda/caffe2_gpu_generated_SparseCUDABlas.cu.o
/pytorch/aten/src/ATen/native/sparse/cuda/SparseCUDABlas.cu(58): error: more than one instance of function "at::native::sparse::cuda::cusparseGetErrorString" matches the argument list:
function "cusparseGetErrorString(cusparseStatus_t)"
function "at::native::sparse::cuda::cusparseGetErrorString(cusparseStatus_t)"
argument types are: (cusparseStatus_t)
1 error detected in the compilation of "/tmp/tmpxft_00004ccc_00000000-6_SparseCUDABlas.cpp1.ii".
CMake Error at caffe2_gpu_generated_SparseCUDABlas.cu.o.Release.cmake:279 (message):
Error generating file
/pytorch/build/caffe2/CMakeFiles/caffe2_gpu.dir/__/aten/src/ATen/native/sparse/cuda/./caffe2_gpu_generated_SparseCUDABlas.cu.o
caffe2/CMakeFiles/caffe2_gpu.dir/build.make:1260: recipe for target 'caffe2/CMakeFiles/caffe2_gpu.dir/__/aten/src/ATen/native/sparse/cuda/caffe2_gpu_generated_SparseCUDABlas.cu.o' failed
warnings:
ptxas warning : Too big maxrregcount value specified 96, will be ignored
missing header error:
Scanning dependencies of target caffe2_pybind11_state
[ 59%] Building CXX object caffe2/CMakeFiles/caffe2_pybind11_state.dir/python/pybind_state.cc.o
In file included from /pytorch/aten/src/THC/THC.h:4:0,
from /pytorch/torch/lib/THD/../THD/base/TensorDescriptor.h:6,
from /pytorch/torch/lib/THD/../THD/base/TensorDescriptor.hpp:6,
from /pytorch/torch/lib/THD/../THD/THD.h:14,
from /pytorch/torch/lib/THD/base/DataChannelRequest.h:3,
from /pytorch/torch/lib/THD/base/DataChannelRequest.hpp:6,
from /pytorch/torch/lib/THD/base/DataChannelRequest.cpp:1:
/pytorch/build/caffe2/aten/src/THC/THCGeneral.h:17:23: fatal error: cublas_v2.h: No such file or directory
compilation terminated.
make[2]: *** [caffe2/torch/lib/THD/CMakeFiles/THD.dir/base/DataChannelRequest.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
Apparently the problem was that both libcusparse and aten/src/ATen/native/sparse/cuda/SparseCUDABlas.cu implement cusparseGetErrorString() and for version >= 10.2 the one in the library should be used.
--- aten/src/ATen/native/sparse/cuda/SparseCUDABlas.cu.orig 2020-11-16 12:13:17.680023134 +0000
+++ aten/src/ATen/native/sparse/cuda/SparseCUDABlas.cu 2020-11-16 12:13:45.158407583 +0000
## -9,7 +9,7 ##
namespace at { namespace native { namespace sparse { namespace cuda {
-
+#if 0
std::string cusparseGetErrorString(cusparseStatus_t status) {
switch(status)
{
## -51,6 +51,7 ##
}
}
}
+#endif
inline void CUSPARSE_CHECK(cusparseStatus_t status)
{
I haven't tried yet if it works at runtime but the build is successful.
I want to create/subscribe a new (simulated) device with my local machine in azure IoT Hub.
I am using python 3.6.4 (64bit) on windows7 (64bit) machine and run the code with spyder.
Installed, relevant packages:
azure-iothub-device-client (1.3.1)
azure-iothub-service-client (1.3.1)
spyder (3.2.8)
I followed the steps from here: CreateDeviceIdentity.py
The code snipped:
import sys
import iothub_service_client
CONNECTION_STRING = "myConnectionString"
DEVICE_ID = "pythonDevice_1"
def print_device_info(title, iothub_device):
print ( title + ":" )
print ( "iothubDevice.deviceId = {0}".format(iothub_device.deviceId) )
print ( "iothubDevice.primaryKey = {0}".format(iothub_device.primaryKey) )
print ( "iothubDevice.secondaryKey = {0}".format(iothub_device.secondaryKey) )
print ( "iothubDevice.connectionState = {0}".format(iothub_device.connectionState) )
print ( "iothubDevice.status = {0}".format(iothub_device.status) )
print ( "iothubDevice.lastActivityTime = {0}".format(iothub_device.lastActivityTime) )
print ( "iothubDevice.cloudToDeviceMessageCount = {0}".format(iothub_device.cloudToDeviceMessageCount) )
print ( "iothubDevice.isManaged = {0}".format(iothub_device.isManaged) )
print ( "iothubDevice.authMethod = {0}".format(iothub_device.authMethod) )
print ( "" )
#def iothub_createdevice():
try:
iothub_registry_manager = iothub_service_client.IoTHubRegistryManager(CONNECTION_STRING)
primary_key = ""
secondary_key = ""
auth_method = iothub_service_client.IoTHubRegistryManagerAuthMethod.SHARED_PRIVATE_KEY
new_device = iothub_registry_manager.create_device(DEVICE_ID, primary_key, secondary_key, auth_method)
print_device_info("CreateDevice", new_device)
except iothub_service_client.IoTHubError as iothub_error:
print ( "Unexpected error {0}".format(iothub_error) )
#return
except KeyboardInterrupt:
print ( "iothub_createdevice stopped" )
'''
if __name__ == '__main__':
print ( "" )
print ( "Python {0}".format(sys.version) )
print ( "Creating device using the Azure IoT Hub Service SDK for Python" )
print ( "" )
print ( " Connection string = {0}".format(CONNECTION_STRING) )
print ( " Device ID = {0}".format(DEVICE_ID) )
iothub_createdevice()
'''
If I run this code I always get the error:
Unexpected error IoTHubRegistryManager.create_device, IoTHubRegistryManagerResult.HTTPAPI_ERROR
I found the (or a similar) error on several pages in the inet but never got a working solution for it. The other code example from the microsoft documentation 1 (SimulatedDevice.py) works fine.
addon:
the error can also be reproduced when running the script by command line. The complete error log:
Error: Time:Thu Apr 5 08:59:55 2018
File:C:\release\iot-sdks-internals\release\python\automation\az
iotsdk_pytools\src\c\c-utility\adapters\httpapi_winhttp.c
Func:HTTPAPI_Init Line:142 WinHttpOpen failed.
Error: Time:Thu Apr 5 08:59:55 2018
File:C:\release\iot-sdks-internals\release\python\automation\aziotsdk_pytools\src\c\c-utility\adapters\httpapi_winhttp.c
Func:HTTPAPI_Init Line:142 GetLastError: Falscher Parameter.
Error: Time:Thu Apr 5 08:59:55 2018
File:C:\release\iot-sdks-internals\release\python\automation\aziotsdk_pytools\src\c\c-utility\src\httpapiex.c
Func:HTTPAPIEX_ExecuteRequest Line:475 unable to recover sending to a
working state
Error: Time:Thu Apr 5 08:59:55 2018
File:C:\release\iot-sdks-internals\release\python\automation\az
iotsdk_pytools\src\c\iothub_service_client\src\iothub_registrymanager.c
Func:sendHttpRequestCRUD Line:982 HTTPAPIEX_SAS_ExecuteRequest failed
Unexpected error IoTHubRegistryManager.create_device,
IoTHubRegistryManagerResult.HTTPAPI_ERROR
This is old by now, but I keep running into similar stuff and wanted to share some solutions I've found.
I had this same problem with the newest pip installs (1.4.5) and python3.7 and diagnosed it to incorrect openssl / curl libraries. I resolved it by compiling the Azure IOTHub Python SDK myself, which creates .so files for the device and service clients that you can just drop in your code directory next to your python files.
Here's how I tracked it down:
Use pip to find the directory for the module:
pip3 show azure-iothub-service-client
This pointed me to /usr/local/lib/python3.7/site-packages. Underneath that was the folder the import uses - /iothub_service_client. I used Apple's 'otool' utility to list the libraries that the service client calls (this can be done on linux using 'ldd'):
otool -L /usr/local/lib/python3.7/site-packages/iothub_service_client/iothub_service_client.so
That showed me that the library was using the libcurl that comes with MacOSX:
/usr/local/lib/python3.7/site-packages/iothub_service_client/iothub_service_client.so:
#rpath/iothub_service_client.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/opt/boost-python3/lib/libboost_python37-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/opt/python/Frameworks/Python.framework/Versions/3.7/Python (compatibility version 3.7.0, current version 3.7.0)
/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1452.23.0)
/System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork (compatibility version 1.0.0, current version 897.15.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1452.23.0)
I remembered something about the new MacOS LibreSSL-based curl not working for the MSFT clients, and even though I had my brew-installed curl library directory set in a DYLD_LIBRARY_PATH env variable, I decided to compile the iothub service & device clients myself to see if it fixed the problem. I largely followed the suggestions at https://github.com/Azure/azure-iot-sdk-python/blob/master/doc/python-devbox-setup.md.
Some additional things I did to ensure a successful compile:
First, get brew info for curl & openssl using brew info <package>
The brew versions of curl and openssl were already in my path. They shouldn't be required for a compile, but I've had other setup scripts fail because of version checks against curl and openssl, so they may be needed for the staging scripts. brew info gives you the commands you need to put them into your path. It'll be something like:
echo 'export PATH="/usr/local/opt/openssl/bin:$PATH"' >> ~/.bash_profile
echo 'export PATH="/usr/local/opt/curl/bin:$PATH"' >> ~/.bash_profile
Make sure the build will use your libs and includes for curl and openssl:
export LDFLAGS="-L/usr/local/opt/curl/lib -L/usr/local/opt/openssl/lib"
export CPPFLAGS="-I/usr/local/opt/curl/include -I/usr/local/opt/openssl/include"
Since these SDKs use Boost, you need to get that installed properly. I finally found the right command to install boost and boost-python for python3 without it installing python2 and dragging in a ton of extra stuff:
brew install boost-python3 --with-python3 --without-python
Once all that is good, you should be able to compile the clients with no problems. The latest version of the SDK has support for Python 3.7, and for the first time in a year, I had an error-free compile on first go. :D
Initially, I also got the same error that you got. The solution is uninstall both of the pip packages and install the updated version. If you run the sample code, it is supposed to work fine.
I was able to run this code without a problem. Can you confirm if your IoT Hub is working properly? Did you copy the IoT Hub connection string instead of a device connection string?
I've followed all the steps in the official guide. Except I built it using:
$ bazel build -c opt --copt=-mavx --copt=-mavx2 --copt=-mfma --copt=- msse4.1 --copt=-msse4.2 --config=opt -k //tensorflow/tools/pip_package:build_pip_package
And during ./config I've set the right paths and disabled Google Cloud Platform, Hadoop, XLA, VERBS, OpenCL, CUDA, MPI support.
Hardware:
Macbook Pro 13 inch (mid 2014)
CPU: Intel Core i5 (4278U)
RAM: 8GB
Software:
High Sierra (10.13.2)
Clang Version: clang-900.0.39.2
Bazel Version: 0.9.0
Conda Version: 4.4.3
Python: 3.6.3
All the packages are upto date. This worked perfectly fine 2 months ago on this machine. For some strange reasons it doesn't build anymore now. I'm just posting a part of the error list here:
WARNING: Config values are not defined in any .rc file: opt
ERROR: Skipping 'msse4.1': no such target '//:msse4.1': target 'msse4.1' not declared in package '' defined by /Users/rakshithgb/Documents/Tensorflow/tensorflow/BUILD
WARNING: Target pattern parsing failed.
ERROR: /private/var/tmp/_bazel_rakshithgb/fde7bc60972656b0c2db4fd0b79e24fb/external/com_googlesource_code_re2/BUILD:96:1: First argument of 'load' must be a label and start with either '//', ':', or '#'. Use --incompatible_load_argument_is_label=false to temporarily disable this check.
ERROR: /private/var/tmp/_bazel_rakshithgb/fde7bc60972656b0c2db4fd0b79e24fb/external/com_googlesource_code_re2/BUILD:98:1: name 're2_test' is not defined (did you mean 'ios_test'?)
ERROR: /private/var/tmp/_bazel_rakshithgb/fde7bc60972656b0c2db4fd0b79e24fb/external/com_googlesource_code_re2/BUILD:100:1: name 're2_test' is not defined (did you mean 'ios_test'?)
And it ends like this:
ERROR: /Users/rakshithgb/Documents/Tensorflow/tensorflow/tensorflow/core/kernels/BUILD:550:1: Target '#local_config_sycl//sycl:using_sycl' contains an error and its package is in error and referenced by '//tensorflow/core/kernels:debug_ops'
WARNING: errors encountered while analyzing target '//tensorflow/tools/pip_package:build_pip_package': it will not be built
INFO: Analysed target //tensorflow/tools/pip_package:build_pip_package (203 packages loaded).
INFO: Found 0 targets...
ERROR: command succeeded, but there were errors parsing the target pattern
INFO: Elapsed time: 12.763s, Critical Path: 0.02s
FAILED: Build did NOT complete successfully
Has anyone else had this issue? How do I fix it? I've uploaded the entire error log on GitHub Tensorflow issue page. #15622
Ok it looks like the new bazel version isn't compatible with the current Tensorflow release. It looks like the fix will be issued in the next release. According to this thread on GitHub - #15492
The temporary fix that worked for me was to build it using --incompatible_load_argument_is_label=false in the bazel command. So my build command now looks like this:
$ bazel build --config=opt --incompatible_load_argument_is_label=false //tensorflow/tools/pip_package:build_pip_package
I run ./myprogram and it gives me a warning:
Warning: Your program was compiled with SimGrid version 3.13.90, and then linked against SimGrid 3.13.0. Proceeding anyway.
Tryldd myprogram and it gives following:
libsimgrid.so.3.13.90 => /usr/lib/libsimgrid.so.3.13.90 (0x00007f338ef47000)
Then I go to usr/lib and type ll *sim* in terminal:
lrwxrwxrwx 1 ken ken 21 июл 28 19:29 libsimgrid.so -> libsimgrid.so.3.13.90*
-rwxrwxr-x 1 ken ken 12307480 июл 28 19:29 libsimgrid.so.3.13.90*
In CMakeLists.txt I link library simgrid in such way:
target_link_libraries(CSim2Sim simgrid)
Why myprogram still links against SimGrid 3.13.0 (it doesn't exist in /usr/lib while SimGrid 3.13.90 does)?
UPDATE:
Command locate libsimgrid.so in ternimal gives:
/home/ken/Downloads/simgrid-master/lib/libsimgrid.so
/home/ken/Downloads/simgrid-master/lib/libsimgrid.so.3.13.90
/home/ken/SimGrid/lib/libsimgrid.so
/home/ken/SimGrid/lib/libsimgrid.so.3.13.90
/usr/lib/libsimgrid.so
/usr/lib/libsimgrid.so.3.13.90
The message seems buggy, it looks like your application was actually compiled with 3.13.0, and linked to libsimgrid 3.13.90. The order was inverted in the message, I will fix that.
It could be a problem with your includes when you compile your code, I think. Please check that you don't use old versions of msg.h/simgrid_config.h files when you compile your app (maybe there are still one in /usr/include ?).
To check, you can look for SIMGRID_VERSION_PATCH in simgrid_config.h. it should be 90 in a recent one, not 0.