无法在Openshift缩放应用程序上安装mysql2 gem [英] Cannot install mysql2 gem on openshift scaled app

问题描述

我正在尝试在Rails 4/ruby​​ 2.0 OpenShift缩放应用程序上用ruby安装mysql2 gem. 但是，捆绑安装失败，尝试执行"gem install mysql2"，这将导致以下错误:

I'm trying to install mysql2 gem with ruby on rails 4/ruby 2.0 OpenShift scaled app. But, bundle install fails, trying "gem install mysql2", which leads to the following error:

gem install mysql2
Fetching: mysql2-0.4.1.gem (100%)
Building native extensions.  This could take a while...
ERROR:  Error installing mysql2:
    ERROR: Failed to build gem native extension.

    /opt/rh/ruby200/root/usr/bin/ruby extconf.rb
checking for ruby/thread.h... yes
checking for rb_thread_call_without_gvl() in ruby/thread.h... yes
checking for rb_thread_blocking_region()... yes
checking for rb_wait_for_single_fd()... yes
checking for rb_hash_dup()... yes
checking for rb_intern3()... yes
-----
Using mysql_config at /opt/rh/mysql55/root/usr/bin/mysql_config
-----
checking for mysql.h... yes
checking for errmsg.h... yes
checking for mysqld_error.h... yes
-----
Don't know how to set rpath on your system, if MySQL libraries are not in path mysql2 may not load
-----
-----
Setting libpath to /opt/rh/mysql55/root/usr/lib64/mysql
-----
creating Makefile

make "DESTDIR="
gcc -I. -I/opt/rh/ruby200/root/usr/include -I/opt/rh/ruby200/root/usr/include/ruby/backward -I/opt/rh/ruby200/root/usr/include -I. -I/opt/rh/mysql55/root/usr/include/mysql -DHAVE_RUBY_THREAD_H -DHAVE_RB_THREAD_CALL_WITHOUT_GVL -DHAVE_RB_THREAD_BLOCKING_REGION -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_HASH_DUP -DHAVE_RB_INTERN3 -DHAVE_MYSQL_H -DHAVE_ERRMSG_H -DHAVE_MYSQLD_ERROR_H    -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -mtune=generic -fPIC  -m64 -o client.o -c client.c
gcc -I. -I/opt/rh/ruby200/root/usr/include -I/opt/rh/ruby200/root/usr/include/ruby/backward -I/opt/rh/ruby200/root/usr/include -I. -I/opt/rh/mysql55/root/usr/include/mysql -DHAVE_RUBY_THREAD_H -DHAVE_RB_THREAD_CALL_WITHOUT_GVL -DHAVE_RB_THREAD_BLOCKING_REGION -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_HASH_DUP -DHAVE_RB_INTERN3 -DHAVE_MYSQL_H -DHAVE_ERRMSG_H -DHAVE_MYSQLD_ERROR_H    -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -mtune=generic -fPIC  -m64 -o infile.o -c infile.c
gcc -I. -I/opt/rh/ruby200/root/usr/include -I/opt/rh/ruby200/root/usr/include/ruby/backward -I/opt/rh/ruby200/root/usr/include -I. -I/opt/rh/mysql55/root/usr/include/mysql -DHAVE_RUBY_THREAD_H -DHAVE_RB_THREAD_CALL_WITHOUT_GVL -DHAVE_RB_THREAD_BLOCKING_REGION -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_HASH_DUP -DHAVE_RB_INTERN3 -DHAVE_MYSQL_H -DHAVE_ERRMSG_H -DHAVE_MYSQLD_ERROR_H    -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -mtune=generic -fPIC  -m64 -o mysql2_ext.o -c mysql2_ext.c
gcc -I. -I/opt/rh/ruby200/root/usr/include -I/opt/rh/ruby200/root/usr/include/ruby/backward -I/opt/rh/ruby200/root/usr/include -I. -I/opt/rh/mysql55/root/usr/include/mysql -DHAVE_RUBY_THREAD_H -DHAVE_RB_THREAD_CALL_WITHOUT_GVL -DHAVE_RB_THREAD_BLOCKING_REGION -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_HASH_DUP -DHAVE_RB_INTERN3 -DHAVE_MYSQL_H -DHAVE_ERRMSG_H -DHAVE_MYSQLD_ERROR_H    -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -mtune=generic -fPIC  -m64 -o result.o -c result.c
gcc -I. -I/opt/rh/ruby200/root/usr/include -I/opt/rh/ruby200/root/usr/include/ruby/backward -I/opt/rh/ruby200/root/usr/include -I. -I/opt/rh/mysql55/root/usr/include/mysql -DHAVE_RUBY_THREAD_H -DHAVE_RB_THREAD_CALL_WITHOUT_GVL -DHAVE_RB_THREAD_BLOCKING_REGION -DHAVE_RB_WAIT_FOR_SINGLE_FD -DHAVE_RB_HASH_DUP -DHAVE_RB_INTERN3 -DHAVE_MYSQL_H -DHAVE_ERRMSG_H -DHAVE_MYSQLD_ERROR_H    -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -mtune=generic -fPIC  -m64 -o statement.o -c statement.c
rm -f mysql2.so
gcc -shared -o mysql2.so client.o infile.o mysql2_ext.o result.o statement.o -L. -L/opt/rh/ruby200/root/usr/lib64 -L/opt/rh/mysql55/root/usr/lib64/mysql -L. -fstack-protector -rdynamic -Wl,-export-dynamic  -m64  -lruby -L/opt/rh/mysql55/root/usr/lib64/mysql -lmysqlclient -lpthread -lz -lm -lrt -lssl -lcrypto -ldl  -lpthread -lrt -ldl -lcrypt -lm   -lc
/usr/bin/ld: cannot find -lmysqlclient
collect2: ld returned 1 exit status
make: *** [mysql2.so] Error 1


Gem files will remain installed in /var/lib/openshift/541424415004469f3a000b85/.gem/gems/mysql2-0.4.1 for inspection.
Results logged to /var/lib/openshift/541424415004469f3a000b85/.gem/gems/mysql2-0.4.1/ext/mysql2/gem_make.out

MySQL库/SDK应该由RedHat在PaaS产品中维护/提供，所以我有些困惑.有趣的是，直到今天晚上，它都运行良好.

MySQL libraries/SDK are supposed to be maintained/provided by RedHat in the PaaS offering, so I'm a bit stuck. Interestingly enough, until tonight, it worked well.

最初的答案表明，我错过了问题中的一个重点.在OpenShift中，没有对齿轮的root访问权限，因此我无法按照以下建议执行yum install.这确实是一个 OpenShift特定问题，而不是一般性问题.我绝对知道如何安装MySQL开发库.抱歉，由于缺少一条信息而造成的混乱.

The first answers revealed, that I missed an important point in the question. In OpenShift one does not have root access to the gear, so I cannot execute yum install as suggested below. It is really an OpenShift specific question, not a general one. I definitely know how to install MySQL development libraries. Sorry about the confusion, caused by the missing piece of information.

推荐答案

好吧，我终于做到了，我正在发布答案，以便其他人在遇到相同问题时可以从中受益.

Ok, I finally made it and I'm posting the answer so that others can benefit from that in case they meet the same problem.

出现这种现象的原因显然是以前的OpenShift部署方法在中间中断了，这使齿轮处于不一致的状态(mysql2 gem的问题就是这种情况的一个征兆).我基本上试图做的是通过捆绑并从git HEAD重新构建，将其手动恢复到一致状态.

The reason for the behavior was apparently that the previous deployment approach in OpenShift broke in the middle, which left the gear in an inconsistent state (the issue with mysql2 gem was one symptom of that). What I basically tried to do is to bring it back to a consistent state manually by bundle'ing and re-building from the git HEAD.

这不起作用.

尝试从我的开发存储库中推送git也没有用，因为自上次推送以来没有任何变化(这显然是由于某些OpenShift内部错误而导致部署中断). 最后，我对包进行了一些更改(在本例中，通过bundle update更新了一个gem)和更新的Gemfile.lock. 由于我还签入了"force_clean_build"标记，因此随后的推送从头开始重新构建了齿轮，并且使其处于一致状态.

Attempts to push to the gear git from my development repository did not work either, since nothing has changed from the last push (which resulted in deployment that broke apparently due to some OpenShift internal bugs). What I did at the end, I made some change in the bundle (in my case updated one gem by bundle update) and this updated Gemfile.lock. Since I also checked in "force_clean_build" marker, the subsequent push rebuilt the gear from scratch, also having brought it to a consistent state.

长话短说，如果OpenShift部署在中间中断，最好对源进行伪造更改并将其与标记force_clean_build一起推送到齿轮的git gear deploy HEAD而不是尝试手动重建，因为后者无法清除可能发生的不一致情况.

Long story short, if OpenShift deployment breaks in the middle, it is much better to make a fake change in sources and push them in conjunction with the marker force_clean_build to the gear's git than to try to rebuild manually by gear deploy HEAD, since the latter does not clean up the possibly occurred inconsistency.

这篇关于无法在Openshift缩放应用程序上安装mysql2 gem的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！