I have installed moses successfully, I have also install xmlrpc-c via
sudo apt-get install libxmlrpc-core-c3 then I have built the moses via
./bjam --with-xmlrpc-c=[/path/to/xmlrpc-c-config]. While doing these I have followed the instructions in http://www.statmt.org/moses/?n=Development.GetStarted. Up to that point, I guess everything was correct. From now, I need to connect to the machine where moses is installed, however I could not start the mosesserver. What should I do with the file in mosesdecoder/contrib/server/mosesserver.cpp. I think after the build an executable should be created in there , or am I going to compile it manually? Btw, this is the remote version: x86_64 x86_64 x86_64 GNU/Linux.
Thanks in advance...
"mosesserver" binary executable is located in mosesdecoder/bin directory after successful compilation.
It can be started in a similar fashion to moses, i.e.
/path/to/mosesserver -f /path/to/moses.ini
It will run a web server on port 8080 by default, expecting XML-RPC v2 protocol to communicate.
For building, make sure you have Boost libraries (+ devel package) installed at a location where they can be found (i.e. /lib or /usr/lib or lib64, depending on the system) or add the path to LD_LIBRARY_PATH if you compile them manually.
Related
I trying to get set up with Variant Effect Predictor (VEP) on the command line. I'm following the setup tutorial but I'm encountering some errors around dependencies. I'm also quite new to the command line so if anyone is able to break down the solution too then I'd be very grateful. Thanks!
Tutorial: https://www.ensembl.org/info/docs/tools/vep/script/vep_tutorial.html
VEP requirements: http://www.ensembl.org/info/docs/tools/vep/script/vep_download.html#requirements
I also have Perl v5.32.1.
What I've done:
I installed dependencies (listed in the requirements page) with the following commands:
- sudo -s cpanm DBI
- sudo -s cpanm Archive::Zip
- sudo -s cpanm DBD::mysql
For DBD:mysql, I got the follwoing message:
--> Working on DBD::mysql
Fetching http://www.cpan.org/authors/id/D/DV/DVEEDEN/DBD-mysql-4.050.tar.gz ... OK
Configuring DBD-mysql-4.050 ... N/A
! Configure failed for DBD-mysql-4.050. See /root/.cpanm/work/1626111140.5937/build.log for details.
Trying it out anyway, I ran perl INSTALL.pl (from the tutorial page) and got the message below. I would like VEP to run in online mode too if possible.
`WARNING: DBD::mysql module not found. VEP can only run in offline (--offline) mode without DBD::mysql installed
http://www.ensembl.org/info/docs/tools/vep/script/vep_download.html#requirements
Hello! This installer is configured to install v104 of the Ensembl API for use by the VEP.
It will not affect any existing installations of the Ensembl API that you may have.
It will also download and install cache files from Ensembl's FTP server.
Checking for installed versions of the Ensembl API...done
Setting up directories
Destination directory ./Bio already exists.
Do you want to overwrite it (if updating VEP this is probably OK) (y/n)? y
- fetching BioPerl
- unpacking ./Bio/tmp/release-1-6-924.zip
ERROR: Unable to unpack file ./Bio/tmp/release-1-6-924.zip without Archive::Extract or tar/unzip/gzip`
You show us this error:
Configure failed for DBD-mysql-4.050. See /root/.cpanm/work/1626111140.5937/build.log for details.
So looking in there will give you more clues about what the problems are. Without that, we can only guess.
But we can make educated guesses. The DBD::mysql distribution comes with a file called DBD::mysql::INSTALL which will talk you through some of the problems you'll find while installing this module.
It's important to note that DBD::mysql is a wrapper around MySQL's client libraries. They are written in C, so you'll need a C compiler installed in order to build DBD::mysql. You'll also need the client libraries and the development versions of the client libraries (for the C header files that you'll need to compile the module). On Ubuntu, those packages are called "libmysqlclient" and "libmysqlclient-dev". If you don't have a C compiler, then you'll want to install "gcc" too.
But this is all getting a bit complicated. There's another, simpler, approach. If you're using the system version of Perl (the version that was installed as part of the operating system and probably lives in /usr/bin/perl) then I'd recommend using the pre-build Ubuntu version of the package, which you can install by running:
$ sudo apt-get install libdbd-mysql-perl
Installing that version uses the OS's own package manager, and the package manager knows which other packages are needed in order for it to work - so it will install those as well.
People will probably complain that you're better off installing the modules from CPAN as it gives you more flexibility and allows you to use more up-to-date packages than the versions from your OS repos. And they're right. But, honestly, if you're a non-Perl programmer who just wants to get an application up and running, this is by far the simplest approach.
(But, as I said above, this is all guesswork as you haven't shared the most important errors with us.)
I would need to install Memcached on a server for which I don't have root rights.
Is it (legally) possible to install it on another server (i.e. a
CentOS virtual machine) and then bring the "compiled executable" on
the original server?
If yes, how do I avoid libraries and other dependencies issues?
I would like to avoid contacting server admins if possible as this translates in high waiting times.
It is possible as long as you compile the dependencies into the memcached binary.
This implies disabling shared and building a static binary.
You can find someone having experience doing the same in this discussion:
So the relevant steps are:
got latest libevent from: http://www.monkey.org/~provos/libevent/
build libevent as follows:
(cd in libevent directory first)
a. configure --prefix=/home/hduin/ots/libevent-1.4.13-build
b. make install
in latest memcached directory:
a. configure --with-libevent=/home/hduin/ots/libevent-1.4.13-build
b. edit Makefile and add -static to LDFLAGS and -lrt to LIBS
definitions
c. make
Trying to install swift on my Ubuntu 14.04.3 server. Followed the guide on Swift.org.
download the install package
fetched the gpg keys
verified the .sig file
extracted the file and added the usr/bin subdir to my PATH
However when I try running swift I get "No such file or directory"
Swift seems to be found:
icanzilb#underplot:~/public$ which swift
/home/icanzilb/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin/swift
Path is correct:
icanzilb#underplot:~/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin$ echo $PATH
/home/icanzilb/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin:...
But can't run it:
icanzilb#underplot:~/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin$ swift
-bash: /home/icanzilb/swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a-ubuntu14.04/usr/bin/swift: No such file or directory
=====
Update 1: I tried the development and stable builds of Swift from swift.org and the .sig checks out but still getting the same error.
Both the swift executable and my Ubuntu are 64 bit.
It really looks like this is a problem of an architecture mismatch, as indicated by one of the commenters, or a corrupted download. The swift executable is in the path and is picked up by which. Judging from the name of the directory where it is located, it is indeed for Ubuntu 14.04. I would try the following:
file `which swift`
This should tell you it is an ELF 64-bit executable, dynamically linked, etc. If that is not the case, you have a corrupted binary somehow.
Then do
uname -a
which should identify your system as Ubuntu 14, x86_64 among other things. If that is the case, you probably have a corrupted binary. Unpack the downloaded package again and retry. If your system is not x86_64, then you are on a wrong architecture.
Update 2/4/2016:
Based on the additional info you provided about the binary and the architecture, I tend to believe this is a platform mismatch. The output of uname doesn't show it is an Ubuntu box. Besides, the Linux kernel is 4.4.0, and the binary is for 2.6.24. I can successfully run the same binary on an Ubuntu 14.04 installation with a 3.19.0 kernel. The kernel version difference is not necessarily a problem in itself, but an indicator that the platform may not be a standard Ubuntu 14.04 install.
As another check, could you please do cat /etc/os-release and cat /etc/lsb-release? Those files should indicate if the platform is indeed Ubuntu. If it is, then I'm wondering how you ended up with this late kernel version. It is possible some other components of the OS are also too recent and incompatible with the Swift binary. This may be some strange custom Linode image... If you have a machine you can use, virtual or physical, try downloading and installing a standard Ubuntu 14.04.
I am getting the following error:
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib/php/extensions/no-debug-non-zts-20121212/mcrypt.so' -
/lib64/libc.so.6: version `GLIBC_2.14' not found (required by
/usr/lib/php/extensions/no-debug-non-zts-20121212/mcrypt.so)
Does mcrypt require glibc 2.14?
We are running CentOS 6.4 (latest stable version of CentOS) and it comes with glibc 2.12 (can't really upgrade glibc as being a core part of OS, changing it will likely break lots of stuff)
How do I make my PHP 5.5.4 run mcsypt under these circumstances?
Current configuration (phpinfo output) is here.
I was also having issues installing mcrypt on my VPS dev server so I thought I would post my solution in the hopes that it helps someone. I am running Centos OS 6.5 and had upgraded PHP to 5.5.13 using the Webtatic EL yum repository. https://webtatic.com/packages/php55/
First shh into your server
ssh admin#domain.com
initially I was trying to do (which was not working):
yum update
yum install php-mcrypt
I then realized my mistake when I looked at php -v and realized php-common was conflicting as the above code was trying to load a dependency from 5.3.
I then executed the following correct commands:
rpm -Uvh http://mirror.webtatic.com/yum/el6/latest.rpm
yum update
yum install php55w-mcrypt
service httpd restart
This worked perfectly for me.
I also read while researching this issue that some people did have to add the extension to their .ini file manually by adding the following line but i did not have to do this.
extension=mcrypt.so
you can find the location of your php.ini file by looking at phpinfo(); and see which configuration it is loading. For me the following ini files were loading:
/etc/php.ini
/etc/php.d/mcrypt.ini
/var/www/vhosts/system/domain.com/etc/php.ini
If the installation is successful then you will see the extension when you echo phpinfo();
Try installing php-mcrypt using yum. That should pull in any other libraries you need to run it.
yum install php-mcrypt
In light of your update, it would appear that you are trying to use the MCrypt extension built from another PHP Source which was created by an updated GLIBC library. The only proper solution I can see is the following:
You first need to ensure you have libmcrypt, libmcrypt-devel, and mcrypt installed before continuing. Check your CentOS repository.
Download the PHP Source from http://php.net
Untar the downloaded source tar -zxf php-5.5.4.tar.gz
cd into the source cd php-5.4.4
Copy your current ./configure string. The whole thing!
Add support for Mcrypt --with-mcrypt=/usr and run the new configure command
make && make install
restart Apache and PHP-FPM
This will keep your current configuration just as CentOS has built it but with the additional support of MCrypt as you are looking to have. Once you've done this, you do not need to enable the MCrypt extension in your php.ini file as it will be built into PHP itself and will be automatically loaded for you now.
When in doubt, you can also read up on the installation here http://us1.php.net/manual/en/mcrypt.installation.php
I've been trying to get Zend installed on my Mac Pro for some time. I've tried installing it manually, with homebrew, and with port. I've changed php's, reinstalled php, updated php, reinstalled openssl multiple times.
php.ini has openssl in it and it is uncommented, curl is also enabled.
no matter which way I go about it I always get a message like this or very similar (always ssl)
You must enable the openssl extension to download files via https
I also installed a certificate for ssl.
currently I have downloaded the zip for the Zend 2.2.2 'tutorial', extracted to a sites directory and have run
composer install
which as given me:
Loading composer repositories with package information
Installing dependencies (including require-dev)
- Installing zendframework/zendframework (2.2.2)
[RuntimeException]
You must enable the openssl extension to download files via https
install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-custom-installers] [--no-scripts] [--no-progress] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader]
I know its installed. I've reinstalled it 3 times. Only thing I can think of is maybe there is more than one php.ini but I haven't been able to find a second one.
thanks in advance for any advice.
I ran php info in apache and got the old install of php version 5.3, when I run it from the command line I get the new 5.4 ?
$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
$ composer diag
Checking platform settings: FAIL
The openssl extension is missing, which will reduce the security and stability of Composer.
If possible you should enable it or recompile php with --with-openssl
Checking http connectivity: OK
Checking composer.json: OK
Checking disk free space: OK
Checking composer version: OK
There is more than one php.ini - the command line version of PHP has a separate one. To see what that is, run php -i | grep ini from the command line - the output should include the .ini files being used near the top.
(Disclaimer: I'm not a Mac user so things may be different in Apple world.)
I'd like to say there was an easy fix. My suggestion is to use homebrew, install everything, then make sure your php.ini is in the right spot (probably have to move it) and also that you change the permissions on local\openssl so that homebrew can write to it. Eventually by moving php.ini around and installing php54 I was able to get it to work.
these are great resources
http://juniorgrossi.com/2013/working-with-multiple-php-versions-on-mac-os-x/
http://railsapps.github.io/openssl-certificate-verify-failed.html