How to install tclsh on windows 10 ?
I am not well versed on Linux/Unix packages but there is a check list I am having to follow for a tutorial on how to do ATAK plug-in development on the Android Development Studio.
The prerequisite stepms include installing and/or downloading tclsh.
I understand that tclsh is a shell program. I think it runs Tcl commands. I found this on stack overflow:
How to install packages in Tcl? which is responses to the question, “How to install packages in Tcl?”. Is this the same thing? Is tclsh part of Tcl?
I don't think so because one of the answers to this post is:
“Yes, there are some directories. To list them, execute tclsh ...”
So this post implies that telsh is already on the system.
There are other posts on stackoverflow which mention tclsh but they all in the context of the anser and mentioned in a way that it is part of a soluton such that it is already installed.
How to install tclsh on windows 10 ?
The github repo for the Spyder IDE Unittest Plugin lists only 2 options for installing the plugin: using the conda spyder-ide channel, as well as pip.
I have been able to install the plugin using the conda forge channel, as indicated in here.
Does it make a difference which channel is used to install the plugin ?
Short answer: no it shouldn't make a difference.
Longer answer: before pressing y at the Proceed ([y]/n? prompt you may want to check which versions of any dependencies are going to be installed, and which channels they will be installed from - especially if you are installing into an existing environment where you may want to upgrade other packages later. If you're happy for your environment to become dependent on packages from conda-forge, there's no issue with using the conda-forge package; otherwise (unless someone more knowledgeable can correct me) I would try and stick to the spyder-ide channel package.
This article on the conda-forge website says
The conda-forge and defaults are not 100% compatible. (...) that
mismatch can lead to errors when the install environment is mixing
packages from multiple channels.
For a longer discussion see the answers to this question.
As always, this advice from the conda-forge page is worth following:
we recommend always installing your packages inside a new environment
instead of the base environment from anaconda/miniconda. Using envs
make it easier to debug problems with packages and ensure the
stability of your root env.
Introduction:
I have to create a pip wheel of Tensorflow 2.2.0 with cuda libraries dynamically linked(specifically cudart.so). To accomplish this i am currently using the tensorflow-dev docker image.
I am able to build the tf wheel file, an able to install and use it while inside the build container.
Issue:
The issue is that importing the generated wheel file in a CentOS server, i get the following error:
ImportError: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /home1/private/mavridis/Vineyard/tensorflowshared/test/lib64/python3.6/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so)
Having looked around, the issue is caused by the build container using a newer libc:
ldd --version
ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
Compared to CentOS older version:
ldd --version
ldd (GNU libc) 2.17
Expected behavior:
Having already tried the 'vanilla' tenorflow 2.2.0 version with no issues, installed using pip:
pip install tensorflow==2.2.0
I expected my own build to also work.
So i assume there is some configuration option or docker configuration to allow me to use the docker built wheel file, in a CentOS setup, just like the pip installed version. As this wheel file is intended to be deployed to setups beyond my control, solutions involving alternate OSes and/or libc replacement are not applicable.
Build configuration:
During build i use the following configuration/ command line:
export TF_NEED_CUDA=1
export TF_USE_XLA=0
export TF_SET_ANDROID_WORKSPACE=0
export TF_NEED_OPENCL_SYCL=0
export TF_NEED_ROCM=0
bazel build --config=opt --config=cuda --output_filter=DONT_MATCH_ANYTHING --linkopt=-L/usr/local/cuda/lib64 --linkopt=-lcudart --linkopt=-static-libstdc++ //tensorflow/tools/pip_package:build_pip_package
Regarding options used:
--output_filter=DONT_MATCH_ANYTHING : Silence warnings
--linkopt=-L/usr/local/cuda/lib64 --linkopt=-lcudart : Dynamic linking of cudart.so
--linkopt=-static-libstdc++ : Static link libstc++ as libstc++ also caused the libc error, this however is not possible for libm
I expected my own build to also work.
That expectation is (obviously) incorrect. The symbols your program or library requires from GLIBC depend on exactly which functions you call.
Consider the following program:
int main() { exit(0); }
When compiled/linked on a GLIBC-2.30 system, this program only depends on GLIBC_2.2.5 (because it doesn't call any newer symbols).
Now change the program slightly:
int main() { gettid(); exit(0); }
Compile/link it again, and all of a sudden this program now requires GLIBC_2.30 (because that's where gettid() was added to GLIBC), and will not work on any system which has older GLIBC.
So i assume there is some configuration option or docker configuration
Sure: your Docker image must have GLIBC that is not newer than what your target system have, i.e. GLIBC-2.17. Your current image contains GLIBC-2.27 (or newer).
You need a different Docker image, and you'll likely have to build it yourself, since GLIBC-2.17 is over 7 years old, and predates TensorFlow by many years.
Update:
What i don't understand is how come the pip tensorflow package (which i assumed was build with the docker image i am using) works with CentOS?
It works by accident, just like my first program would work on CentOS, but the second one wouldn't.
In short i wanted to generate a pip package that would work on 'any' linux/libc version
That is an impossible goal: Linux predates GLIBC, and it is impossible to build a single package that will work on a Linux distribution which didn't include GLIBC and on a distribution that did.
You have to draw a line somewhere. The developers of tensorflow-dev docker image drew a line at GLIBC-2.27. Packages built on this image should work on any system with 2.27 or later, and might (but are not at all guaranteed to) work on older systems.
just like the pip installed version.
You claim that the pip installed version has no "only GLIBC-xx or later" requirement, but that is not true. I am 99.9% sure that it requires at least GLIBC-2.14.
To find which GLIBC versions that package requires, run this command:
readelf -WV _pywrap_tensorflow_internal.so | grep GLIBC_
I assumed, the pip installed version was built using the publicly available tensorflow-devel docker image.
That is quite likely. And like I said, it happens to work on CentOS, but minute changes may make it not work anymore.
Update 2:
So running the readelf command as you suggested, does show the most recent required versions to be: - pip version: GLIBC_2.12 - mine : GLIBC_2.27 So from what i understand the pip version uses an older version even from CentOS, which explains why it works.
It doesn't "use" older version, it uses whatever version is available.
It requires a minimum version 2.12, while your build requires a minimum version 2.27.
How do they achieve this? Do they use a different image that has an older libc? If so, where can i get it? Or do they use the public image, but build with some bazel flag, that 'limits' symbols to the ones contained up to libc 2.12?
You are still not getting it.
The version that your program requires depends on exactly which functions you call. In my example program, if I only call exit, my program requires vesion 2.2.5, but if I also call gettid, then my program requires version 2.30. Note: these two programs are built on the same system with the same flags.
So no: they (most likely) didn't use a different Docker image, and didn't use "magic" bazel flags. They just happened to not call any functions which require GLIBC version > 2.12, and you did.
P.S. You can find which symbol(s) are causing "bad" dependency in your build like so:
readelf -Ws _pywrap_tensorflow_internal.so | egrep 'GLIBC_2.2[0-9]'
readelf -Ws _pywrap_tensorflow_internal.so | egrep 'GLIBC_2.1[89]'
This would produce output similar to (using my second program):
readelf -Ws a.out | egrep 'GLIBC_2.[23][0-9]'
2: 0000000000000000 0 FUNC GLOBAL DEFAULT UND gettid#GLIBC_2.30 (2)
48: 0000000000000000 0 FUNC GLOBAL DEFAULT UND gettid##GLIBC_2.30
The output above shows that the only symbol my binary requires from GLIBC 2.20 or above is gettid.
To make a counter point to what Employed Russian wrote:
The version that your program requires depends on exactly which functions you call. In my example program, if I only call exit, my program requires vesion 2.2.5, but if I also call gettid, then my program requires version 2.30. Note: these two programs are built on the same system with the same flags.
I don't think that's quite accurate. My understanding, which is corroborated by https://github.com/wheybags/glibc_version_header, is that things work like so (quoting that project, emphasis mine):
Glibc uses something called symbol versioning. This means that when you use e.g., malloc in your program, the symbol the linker will actually link against is malloc#GLIBC_YOUR_INSTALLED_VERSION (actually, it will link to malloc from the most recent version of glibc that changed the implementaton of malloc, but you get the idea).
So my guess (I have not checked) would be that the Tensorflow releases are built against an older glibc (perhaps by way of being built on an older release of their target Linux distro).
I have a Rails project that is going to be using OpenCV, and it depends on a certain version of it (2.4.6.1).
I'm looking for deployment advice. The Ubuntu opencv package is an earlier version and therefore not suitable.
I can see a number of possibilities, but I'm trying to think of what will work best.
Just write it up in a README and expect people to follow it: download this, apt-get that, etc...
Add opencv, tagged at the version we need, as a git subtree, and include a Rake task to build it.
Write a script to download and compile the needed code.
Something else ?
None of them seem all that great, to tell the truth.
Can your application be made to work with OpenCV 2.4.2? That is available in Ubuntu 13.04, and you could request it be backported to 12.04. If not, you could update the source package to 2.4.6.1 (which would require learning about debian packaging but might not be too difficult since you would be modifying an existing package instead of starting from scratch), upload it to a PPA, and instruct your users on Ubuntu to install OpenCV from there. You could also package your rails application and put it in the PPA, which would make overall installation even easier.
I am new to vim, and I just followed this setup tutorial, but something went wrong. I am a ruby developer and I am not getting a a ruby highlighting syntax. I have installed janus, before with pathogen I had syntax highlighting but not know.
Also I am using the solarized theme the guy suggested but there is no difference now (in color) between folders and files in my terminal when listing a directory.
Could somebody tell me if I can install pathogen with janus? WIll this break my vim?
Thanks!
Don't install anything (and don't install Janus).
Run $ vimtutor in your terminal. As many times as needed (and don't install Janus).
Once you feel ready to use Vim for day-to-day coding, install MacVim which is built with a better feature set than the default Vim. It comes with a CLI executable so you can use it in your terminal and in tmux (and don't install Janus).
Install the vim-ruby package for better, more up-to-date Ruby support (and don't install Janus).
Don't install Janus. This thing is a pile of crap that will make your life overly complicated, hook you on plugins that may or may not be the best for you needs and prevent you from actually learning Vim properly in exchange of an artificially flattened learning curve.
Decide for a plugin/runtimepath management solution (VAM, vundle or plain Pathogen) and choose your plugins yourself according to your needs (and don't install Janus).
If you have problems with Solarized, take a look at their issue tracker and their wiki. It is fragile and you need some work to set it up correctly (and… you know the rest).