I am building tensorflow from source in order to use the GPU version with an older card with a compute capability of 3.0.
When building, I get an error:
ERROR: /home/[user]/.cache/bazel/_bazel_[user]/35191c369325bea6db75133a187a58d6/external/local_config_cc/BUILD:57:1: in cc_toolchain rule #local_config_cc//:cc-compiler-k8: Error while selecting cc_toolchain: Toolchain identifier 'local' was not found, valid identifiers are [local_linux, local_darwin, local_windows]
I worked around this by hand editing ~/.cache/bazel/_bazel_[user]/35191c369325bea6db75133a187a58d6/external/local_config_cc/BUILD
to change the toolchain_identifier from "local" to "local_linux" under cc_toolchain.
With that change, everything compiles. But, that seems unconventional to me.
Is there something should be specifying elsewhere so that bazel gets the identifier correct on its own?
open /home/[user]/.cache/bazel/_bazel_jeff/35191c369325bea6db75133a187a58d6/external/local_config_cc/BUILD with any text editor and change the line 57 as local_linux
Not sure this is related but ... I was having the same problem, tried a bunch of things that did not work, including alternating between clang and gcc, and then told configure I was using cudnn 7.2 instead of just 7 and it worked after that.
I got the same error in building tensorflow r1.9 for one older Nvidia GPU card. I downgraded the bazel from 0.19.1 to 0.18.1. The error was fixed in compiling.
Related
Here I want to use FinRL for crypto trading, while testing the FinRL's Crypto trading tutorial, bunch of error emerging. The environment I use is google colab, first problem is that the DRLAgent importing, finally I found the problem is version mismatch, so I keep testing, after days and nights, adjusting so many version, I face a error can't be solved. When the tutorial comes to training part
train(start_date=TRAIN_START_DATE,
end_date=TRAIN_END_DATE,
ticker_list=TICKER_LIST,
data_source='binance',
time_interval='5m',
technical_indicator_list=INDICATORS,
drl_lib='elegantrl',
env=env,
model_name='ppo',
current_working_dir='./test_ppo',
erl_params=ERL_PARAMS,
break_step=5e4,
if_vix=False
)
it indicate the line of if_vix error, assert error, so I try to modify the git clone version, but I can't adjust some of the package's version, so I gave up and asking for help
here is the colab I use: https://colab.research.google.com/drive/1Ro63lSqsH4IaLkVrHOH7XcNRM5tnY_Z-
sorry for my poor english and thanks for helping!!
package altering but
!pip install git+
can't change version
and the package inside the git also not anchored
also facing assert error, bunch of capability problem
I am trying to plot my model with the data types with the following the code:
plot_model(model, to_file='model/model.png', show_dtype=True, show_shapes=True, show_layer_names=True)
However, I get an error that show_dtype is not an acceptable parameter even though it appears on the TensorFlow documentation: https://www.tensorflow.org/api_docs/python/tf/keras/utils/plot_model
This is the first time that I have run into this issue. It seems that this may be due to having an earlier release if you downloaded it from Anaconda Forge rather than something else like Pip. It is a simple fix, however.
Basically, you need to go into the library source file and edit it to the current version that is shown on the TensorFlow documentation page.
The link to the GitHub page that you will copy the Python code from is here: https://github.com/tensorflow/tensorflow/blob/v2.5.0/tensorflow/python/keras/utils/vis_utils.py#L278-L348
Afterwards, head to your library path and paste that Python code there.
For example, my path is the following: C:/ProgramData/Anaconda3/envs/ml/Lib/site-packages/tensorflow/python/keras/utils/vis_utils.py. Yours should be something similar.
I'm porting my Windows Mono application to Linux, one step at a time, first to WSL Linux under Windows 10, then hopefully to Real Ubuntu. Everything described here behaves identically under both WSL and Ubuntu 20.04.
My application loads the /usr/lib/libmono-2.0.so shared library, but in doing so the loader throws an exception: undefined symbol: _ZTIPi. Some research showed that this symbol was defined in libstdc++.so, so I "pre-loaded" that as well. That had no effect.
Meanwhile, I found this code fragment perusing the mono code base. It would be in mono\mini\mini-llvm.c: (https://github.com/mono/mono/blob/main/mono/mini/mini-llvm.c)
/* Add a reference to the c++ exception we throw/catch */
{
LLVMTypeRef exc = LLVMPointerType (LLVMInt8Type (), 0);
module->sentinel_exception = LLVMAddGlobal (module->lmodule, exc, "_ZTIPi");
LLVMSetLinkage (module->sentinel_exception, LLVMExternalLinkage);
mono_llvm_set_is_constant (module->sentinel_exception);
}
What exactly is happening here? What do I need to know and understand to successfully load this library?
Solution so far was to build and install Mono outside of the default release.
See https://www.mono-project.com/docs/compiling-mono/linux/
then One Stop Shop Build Script (Debian)
If you follow the instructions, your alternate Mono installation would be in /usr/local
This would suggest that the Mono release was somehow incorrectly compiled.
So, having found this after having the same issue, thank you for the information in the question and answer, it helped me figure out how to solve it. However, your solution doesn't answer your "What exactly is happening here?", which I shall try to explain.
Let's start with the _ZTIPi symbol, which when run through c++filt comes out as: typeinfo for int*
Which is indeed a part of the C++ standard library. It is listed as undefined in the default install of libmono, but not listed at all in the one I compiled from source.
You can check this with something like:
$ readelf --all /usr/lib/libmono-2.0.so | grep _ZTIPi
However, libstdc++.so isn't listed as needed library in either case.
You can check this with something like:
$ readelf --all /usr/lib/libmono-2.0.so | grep NEEDED
This all means that when you try to load in libmono the dynamic linker will try to resolve the _ZTIPi symbol by looking in the libraries listed by libmono (where it can't find it), and in the global symbol table for the process, which may or may not have it.
If you link against libmono at compile-time the solution would be to also link against libstdc++ at that time. This way, your executable will list libstdc++ as needed library, causing the dynamic linker to load its symbols into the global symbol table. When loading libmono the dynamic linker can then find the symbol fine.
If you load libmono dynamically at runtime, you'll have to load in libstdc++ first, using something like this:
void * cxxlib = dlopen("libstdc++.so.6", RTLD_LAZY | RTLD_GLOBAL);
Key thing here is the RTLD_GLOBAL flag, which will add all symbols to the global table, so they can be found when you're trying to load libmono.
And alternative is of course to build mono yourself, which should end you up with a libmono that isn't subtly broken. In that case, make sure to throw in a call to mono_set_dirs, like this:
mono_set_dirs("/opt/mono/lib", "/opt/mono/etc");
I am trying to get OpenAI roboschool to run in Google Colab (have a virtual display setup that records the environment during training and displays video after). The roboschool library will import, but the environments don't show up properly (at all), when I run:
import roboschool, gym;
print("\n".join(['- ' + spec.id for spec in
gym.envs.registry.all() if spec.id.startswith('Roboschool')]))
the list is empty, and it should include the environments.
When cmake links dlls, does it do so with environment variables? Environment variables in Colab don't work as usual, and I think that may be the issue. I don't know enough to know for sure.
This output looks suspect to me, doesn't seem right that the runtime path would be removed. There are a number of these so I only grabbed two for example.
-- Set runtime path of "/content/roboschool/roboschool/cpp-
household/bullet_local_install/lib/libBulletDynamics.so.2.87" to ""
-- Set runtime path of "/content/roboschool/roboschool/cpp-
household/bullet_local_install/lib/libBullet3Geometry.so.2.87" to "
Here is the command sequence.
cmake -DBUILD_SHARED_LIBS=ON -DUSE_DOUBLE_PRECISION=1 -
DCMAKE_INSTALL_PREFIX:PATH=/content/roboschool/roboschool/cpp-
household/bullet_local_install -DBUILD_CPU_DEMOS=OFF -
DBUILD_BULLET2_DEMOS=OFF -DBUILD_EXTRAS=OFF -DBUILD_UNIT_TESTS=OFF -
DBUILD_CLSOCKET=OFF -DBUILD_ENET=OFF -DBUILD_OPENGL3_DEMOS=OFF ..
make -j4
make install
Is there a way I can override the way paths are determined for the linked libraries so they will link with the correct paths if that is correct? Seems like looking into RPATH may be a step in the right direction?
Thanks in advance. Please let me know if additional detail is necessary.
Hard to say what's going on without more details, but if you're building .so's to non-standard location that you want the python runtime to see, you have to somehow tell the runtime about the .so's location. Guessing based on the snippets you provided, maybe this (possibly after a runtime restart (ctrl-m-period)) will unblock you:
import os
os.environ['LD_LIBRARY_PATH'] = '/content/roboschool/roboschool/cpp-household/bullet_local_install/lib:' + os.environ['LD_LIBRARY_PATH']
If that doesn't do it for you, two other suggestions are:
Change your configuration to install to "standard" locations
Share a minimal notebook that reproduces the issue.
Has anyone successfully ported googleTest to a real time process in WindRiver 3.0 / VxWorks 6.6 ?
I am able to get gtest to build, but I get a few errors when linking. I can modify these specific sections of code, but that only produces run time errors.
here is what I'm seeing:
googleTest.so: undefined reference to isascii(int)'
googleTest.so: undefined reference togettimeofday'
googleTest.so: undefined reference to `strcasecmp'
I have 2 shared Libraries (.so): 1 for gtest and 1 for gtest_main. I have 1 RTP (real time process) where I have my test code.
Note:
To get googletest to compile in vxworks, I had to modify some of the Flags: Specifically:
GTEST_HAS_POSIX_RE - 0
GTEST_HAS_TR1_TUPLE - 0
GTEST_HAS_STREAM_REDIRECTION 0
Any insight or advice is much appreciated.
Turns out the way the Kernel was configured was incorrect.
To remedy the problem, I actually made a brand new kernel; keeping all of the default settings. This worked.
VxWorks is not yet supported by Google Test.
Also note that there may need to be certain changes made to the code to support the platform. For example, getClockTime may not exist and the code have to be altered to use a user defined method.
I think there is a unique solution based on your platform, target and sim; and your development environment. As well as versions of the tool (vxworks / wind-river etc).
Googletest does seem to be supported on vxworks7
https://github.com/Wind-River/vxworks7-google-test/blob/master/README.md
I have compiled it, and built a DKM, but at the moment it does not seem to be supporting any tests, so I am not sure what is going on there