I am attempting to install CouchDB on my planetlab Unix machines from the source packages.
I installed Erlang r16b01 using Kerl: http://docs.basho.com/riak/1.3.0/tutorials/installation/Installing-Erlang/#Install-using-kerl
I installed openssl from the source package.
So, I ran "./configure --with-erlang=path/to/erlang/using/kerl" and I get the error
"configure: error: Could not find the Erlang crypto library"
This error indicates that Erlang was not compiled with OpenSSL support.
So, I tried using
"KERL_CONFIGURE_OPTIONS=--with-ssl=path/to/openssl/lib"
(Not sure if I'm using the above command correctly)
Then, reinstalled and reactivated Erlang.
This still brings up the same error.
I checked if Erlang if it could execute "crypto.start()", and it let me type the command, but it doesn't have a reply "ok" like in the documention: http://dennisreimann.de/blog/installing-couchdb-and-erlang-on-ubuntu-hardy/
Please help!
1) Did you first create a user couchdb and then do everything as that user? Including erlang build and install? That might be easier.
2) There is an error in your test, you need to terminate your command in the erl shell with a dot, otherwise you get no responce, like you already noticed. crypto:start(). is correct:
$ erl
Eshell V6.1 (abort with ^G)
1> crypto:start().
** exception error: undefined function crypto:start/0
After a successful build and installation it will respond ok:
$ erl
Eshell V6.1 (abort with ^G)
1> crypto:start().
ok
And you can also stop it afterwards:
2> crypto:stop().
ok
3>
=INFO REPORT==== 10-Aug-2014::20:22:06 ===
application: crypto
exited: stopped
type: temporary
3) You need the development package of OpenSSL including the header files as well as the binary command program openssl. At least version 0.9.8 of OpenSSL is required. As a sidenote for people who are on debian and ubuntu, it is usually enough to run:
sudo apt-get install openssl libssl-dev
In your case, you should somehow make sure that your openssl source install includes all the above (openssl binaries, header files).
4) Most probably it could be an issue with finding the libraries. I recommend reading this answer, which deals with a unix based system, and it could point you to the right direction:
https://stackoverflow.com/a/14776521/362951
Depending on the error message after the crypto:start(). you could try to somehow add the path and logout of the shell and relogin and then activate kerl and try again. No need to rebuild if it was present and found at compile time.
5) Your kerl configuration looks good. Again using debian/ubuntu paths a ~/.kerlrc could look like
KERL_CONFIGURE_OPTIONS="--with-ssl=/usr/lib/ssl"
And hopefully the ssl path you are inserting is the correct one.
You could also try and omit the path, maybe it finds the correct one by itself. On http://www.erlang.org/doc/installation_guide/INSTALL.html it looks like it is valid to do so:
KERL_CONFIGURE_OPTIONS="--with-ssl"
Currently kerl silently produces a build without crypto if it fails to find the headers https://github.com/yrashk/kerl/issues/31
6) I see you are giving the --with-erlang parameter to couchdb, does it point to the right directory? Or maybe it needs to go one level deeper or one level up.
Otherwise possibly an older, system. wide erlang could be used, if found.
Also I am not sure if the combination of a kerl environment and passing the erlang location using the --with-erlang parameter to couchdb works. I did not try the --with-erlang parameter with kerl, because I activate the kerl environment before compiling couchdb and then again before the couchdb start script.
Related
I followed the Software Collections Quick Start and I now have Python 3.5 installed. How can I make it always enabled in my ~/.bashrc, so that I do not have to enable it manually with scl enable rh-python35 bash?
Use the scl_source feature.
Create a new file in /etc/profile.d/ to enable your collection automatically on start up:
$ cat /etc/profile.d/enablepython35.sh
#!/bin/bash
source scl_source enable python35
See How can I make a Red Hat Software Collection persist after a reboot/logout? for background and details.
This answer would be helpful to those who have limited auth access on the server.
I had a similar problem for python3.5 in HostGator's shared hosting. Python3.5 had to be enabled every single damn time after login. Here are my 10 steps for the resolution:
Enable the python through scl script python_enable_3.5 or scl enable rh-python35 bash.
Verify that it's enabled by executing python3.5 --version. This should give you your python version.
Execute which python3.5 to get its path. In my case, it was /opt/rh/rh-python35/root/usr/bin/python3.5. You can use this path to get the version again (just to verify that this path is working for you.)
Awesome, now please exit out of the current shell of scl.
Now, lets get the version again through this complete python3.5 path /opt/rh/rh-python35/root/usr/bin/python3.5 --version.
It won't give you the version but an error. In my case, it was
/opt/rh/rh-python35/root/usr/bin/python3.5: error while loading shared libraries: libpython3.5m.so.rh-python35-1.0: cannot open shared object file: No such file or directory
As mentioned in Tamas' answer, we gotta find that so file. locate doesn't work in shared hosting and you can't install that too.
Use the following command to find where that file is located:
find /opt/rh/rh-python35 -name "libpython3.5m.so.rh-python35-1.0"
Above command would print the complete path (second line) of the file once located. In my case, output was
find: `/opt/rh/rh-python35/root/root': Permission denied
/opt/rh/rh-python35/root/usr/lib64/libpython3.5m.so.rh-python35-1.0
Here is the complete command for the python3.5 to work in such shared hosting which would give the version,
LD_LIBRARY_PATH=/opt/rh/rh-python35/root/usr/lib64 /opt/rh/rh-python35/root/usr/bin/python3.5 --version
Finally, for shorthand, append the following alias in your ~/.bashrc
alias python351='LD_LIBRARY_PATH=/opt/rh/rh-python35/root/usr/lib64 /opt/rh/rh-python35/root/usr/bin/python3.5'
For verification, reload the .bashrc by source ~/.bashrc and execute python351 --version.
Well, there you go, now whenever you login again, you have got python351 to welcome you.
This is not just limited to python3.5, but can be helpful in case of other scl installed softwares.
I compiled my program with gcc using openssl crypto library.
I moved the executable to an other system, and after installing openssl tried to run it. I got the following error:
error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory
What I understand from the following the library is present, but has another name:
locate libcrypto
/usr/lib64/.libcrypto.so.1.0.2f.hmac
/usr/lib64/.libcrypto.so.10.hmac
/usr/lib64/libcrypto.so
/usr/lib64/libcrypto.so.1.0.2f
/usr/lib64/libcrypto.so.10
/usr/lib64/pkgconfig/libcrypto.pc
Can I somehow tell the binary to use one of the present libraries? Or is there a way to install the one which is required?
The compilation was done on Ubuntu 15.10 64 bit, tried to run on Fedora 4.2.3-300.fc23.x86_64.
Can I somehow tell the binary to use one of the present libraries?
No, you can't: there is a reason these libraries have a different name: they are not ABI-compatible. If you managed to somehow tell the binary to use the other library, the result will be a crash if you are lucky, or a silent corruption if you are not.
(BTW, you can try this by creating a symbolic link: ln -s libcrypto.so.1.0.2f libcrypto.so.1.0.0, but you've been warned not to do this).
is there a way to install the one which is required?
Sure: you should be able to copy libcrypto.so.1.0.0 from Ubuntu machine to Fedora one, assuming you can't find a Fedora package that provides it.
When compiling with -fsanitize=memory I get WARNING: Trying to symbolize code, but external symbolizer is not initialized! when running the program. How do I initialize the external symbolizer?
I solved my own problem using MSAN_SYMBOLIZER_PATH=$(which llvm-symbolizer-3.4) ./a.out. The problem is that Ubuntu postfixes the version number but the binary doesn't know that. Of course you need to use MSAN instead of ASAN when using the memory sanitizer.
You are supposed to be able to set the ASAN_FILTER environment variable to point at a symbolizer, but I could not get it to work. However, you can redirect stderr into a symbolizer after the fact. You'll still get the warnings about the uninitialized symbolizer, but the filenames and line numbers will be correct.
You can use asan_symbolizer.py as the external symbolizer. After downloading it from that link (to /tmp, for example), invoke your program like so (in bash, for this example):
./myprogram 2>&1 | /tmp/asan_symbolize.py | c++filt
On my Ubuntu system, the issue is that LLVM's tools are installed under /usr/bin with version suffixes (like llvm-symbolizer-4.0), and the sanitizer tools are looking for them without version suffixes.
LLVM also installs its binaries to, e.g., /usr/lib/llvm-4.0/bin; the tools under /usr/bin are actually just symlinks. So an easy solution is to add the appropriate /usr/lib/llvm-*/bin directory to your path when working with sanitizers.
I received such warning when I run program debug version (compiled with -fsanitize=address) on Linux machine that didn't contain clang installation. The problem disappeared after I installed clang from devtoolset.
I am trying to compile Network.HTTP (http://hackage.haskell.org/package/network) on win32/cygwin. However, it does fail with following message:
Setup.hs: Missing dependency on a foreign library:
* Missing (or bad) header file: HsNet.h
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
If the header file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
Unfortuntely it does not give more clues. The HsNet.h includes sys/uio.h which, actually should not be included, and should be configurered correctly.
Don't use cygwin, instead follow Johan Tibells way
Installing MSYS
Install the latest Haskell Platform. Use the default settings.
Download version 1.0.11 of MSYS. You'll need the following files:
MSYS-1.0.11.exe
msysDTK-1.0.1.exe
msysCORE-1.0.11-bin.tar.gz
The files are all hosted on haskell.org as they're quite hard to find in the official MinGW/MSYS repo.
Run MSYS-1.0.11.exe followed by msysDTK-1.0.1.exe. The former asks you if you want to run a normalization step. You can skip that.
Unpack msysCORE-1.0.11-bin.tar.gz into C:\msys\1.0. Note that you can't do that using an MSYS shell, because you can't overwrite the files in use, so make a copy of C:\msys\1.0, unpack it there, and then rename the copy back to C:\msys\1.0.
Add C:\Program Files\Haskell Platform\VERSION\mingw\bin to your PATH. This is neccesary if you ever want to build packages that use a configure script, like network, as configure scripts need access to a C compiler.
These steps are what Tibell uses to compile the Network package for win and I have used this myself successfully several times on most of the haskell platform releases.
It is possible to build network on win32/cygwin. And the above steps, though useful (by Jonke) may not be necessary.
While doing the configuration step, specify
runghc Setup.hs configure --configure-option="--build=mingw32"
So that the library is configured for mingw32, else you will get link or "undefined references" if you try to link or use network library.
This combined with #Yogesh Sajanikar's answer made it work for me (on win64/cygwin):
Make sure the gcc on your path is NOT the Mingw/Cygwin one, but the
C:\ghc\ghc-6.12.1\mingw\bin\gcc.exe
(Run
export PATH="/cygdrive/.../ghc-7.8.2/mingw/bin:$PATH"
before running cabal install network in the Cygwin shell)
I have source code of a compiler which I am building like this:
/path/to/srcdir/configure --prefix=/path/to/installdir
make
make install
I want to distribute the resulting 'installdir' to other machines, with the intent that anybody could use the compiler binaries without going through the 3-stage build process (I am just including the installdir in my distribution tarball).
For testing, I am copying the installdir to another machine under a different user, and then just trying to compile a test program using the binaries I just copied over, like this:
installdir/bin/ucc -mp -o test load_bl.c
Then, I get an error as follows:
cc1: error: /home/sghosh/normalbuild/installdir/open64-gcc-4.2.0/include: Permission denied
cc1: error: /home/sghosh/normalbuild/installdir/open64-gcc-4.2.0/lib/gcc/x86_64-redhat-linux/4.2.0/include: Permission denied
cc1: error: /home/sghosh/normalbuild/installdir/open64-gcc-4.2.0/x86_64-redhat-linux/include: Permission denied
The /home/sghosh/normalbuild/install is what is specified as --prefix during configure on my build machine. The installdir/bin/ucc binary require some files in the open64-gcc-4.2.0 dir under installdir, but since that is the path mentioned in --prefix, so it's still looking for it there, and I want it to look into the same dir in the current machine. FYI, I do not have sudo/root privileges.
How do I come up with a binary distribution that would work in any machine (build once, use anywhere sorts), and not look into the initial --prefix path in this case?
I have had a similar question in superuser, but since lots of edit happened and I got no response to the new question, so I am writing it here.
Check this tool: https://github.com/pgbovine/CDE
CDE is a tool that automatically packages up the Code, Data, and Environment involved in running any set of Linux commands so that they can execute identically on another computer without any installation or configuration.