Tomcat + OpenSSL符号查找错误未定义符号EC_KEY_new_by_curve_name [英] Tomcat + OpenSSL symbol lookup error undefined symbol EC_KEY_new_by_curve_name
问题描述
我正在尝试在CentOS上使用OpenSSL设置Tomcat.我已经下载了OpenSSL源代码,Tomcat本机库源代码和Tomcat APR.
I am trying to setup Tomcat with OpenSSL on CentOS. I have downloaded OpenSSL source, Tomcat native libraries source and Tomcat APR.
编译了上述所有源代码,使用以下选项编译了OpenSSL
Compiled all of above mentioned sources, compiled OpenSSL using following options
./config shared
已将生成的".so"文件添加到LD_LIBRARY_PATH.但是当我启动tomcat时,出现以下错误,并且tomcat无法启动
Added generated ".so" files to LD_LIBRARY_PATH. But when I start tomcat I get following error and tomcat does not start
/usr/java/jre1.7.0_51/bin/java: symbol lookup error: /usr/local/apr-1.5.1/lib/libtcnative-1.so.0.1.32: undefined symbol: EC_KEY_new_by_curve_name
我是否缺少用于编译OpenSSL的任何命令行参数?顺便说一句,我提到了 https://wiki.openssl.org/index.php/Compilation_and_Installation 编译OpenSSL.
Am I missing any command line arguments for compiling OpenSSL? BTW I referred https://wiki.openssl.org/index.php/Compilation_and_Installation to compile OpenSSL.
编辑
我要编译Apache本机库- http://tomcat.apache.org/native-doc /
To compile Apache native libraries I referred - http://tomcat.apache.org/native-doc/
推荐答案
我遇到了同样的问题. 我试图用我自己在另一台机器上构建的tcnative启动Tomcat,但具有相同的体系结构和操作系统.
I have got the same issue. I was trying to start Tomcat with tcnative that I have built by myself on another machine but with the same architecture and OS.
由于某些遗留方面的原因,似乎已经在我的SunOS中安装的OpenSSL是在没有ECC支持的情况下构建的. 请参阅《 OpenSSL用户指南》 http://www.openssl.org/docs/fips/"ECC和NSA分许可证"下的UserGuide-2.0.pdf .
It seems that OpenSSL, that was already installed in my SunOS was built without ECC support due to some legacy aspects. See the OpenSSL user guide http://www.openssl.org/docs/fips/UserGuide-2.0.pdf under "ECC and the NSA sublicense".
我所做的是再次重建库.对于具有Sun-studio编译器的SunOS 11.2:
What I've done was to rebuild once again the libraries. For SunOS 11.2 with Sun-studio compiler:
./配置solaris64-x86_64-cc --openssldir =/work/shared/openssl --libdir = lib共享zlib-dynamic
./Configure solaris64-x86_64-cc --openssldir=/work/shared/openssl --libdir=lib shared zlib-dynamic
年利率(1.52):
./配置CC = cc CFLAGS =-m64" LDFLAGS =-m64" --prefix =/work/shared/apr --exec-prefix =/work/shared/apr
./Configure CC=cc CFLAGS="-m64" LDFLAGS="-m64" --prefix=/work/shared/apr --exec-prefix=/work/shared/apr
TCNATIVE(1.1.33):
./configure CC = cc --prefix =/work/shared/tcnative --with-apr =/work/shared/apr --with-ssl =/work/shared/openssl --with-java-home =/usr/jdk/jdk1.7.0_80 CFLAGS =-m64 -fPIC" LDFLAGS =-m64"
./configure CC=cc --prefix=/work/shared/tcnative --with-apr=/work/shared/apr --with-ssl=/work/shared/openssl --with-java-home=/usr/jdk/jdk1.7.0_80 CFLAGS="-m64 -fPIC" LDFLAGS="-m64"
也在Tomcat/bin文件夹中,我创建了具有以下内容的setenv.sh:
Also in Tomcat/bin folder I have created setenv.sh with the following contents:
LD_LIBRARY_PATH = $ LD_LIBRARY_PATH:$ CATALINA_HOME/lib:/work/shared/tcnative/lib导出LD_LIBRARY_PATH JAVA_OPTS =-d64 -Djava.library.path =/work/shared/tcnative/lib:/usr/jdk/latest/lib -Dfile.encoding = UTF-8 -Xms512m -Xmx512m -XX:NewSize = 256m -XX: MaxNewSize = 256m -XX:PermSize = 256m -XX:MaxPermSize = 512m -XX:+ OptimizeStringConcat -XX:+ UseStringCache -XX:+ DisableExplicitGC" 导出JAVA_OPTS
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$CATALINA_HOME/lib:/work/shared/tcnative/lib export LD_LIBRARY_PATH JAVA_OPTS="-d64 -Djava.library.path=/work/shared/tcnative/lib:/usr/jdk/latest/lib -Dfile.encoding=UTF-8 -Xms512m -Xmx512m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=256m -XX:MaxPermSize=512m -XX:+OptimizeStringConcat -XX:+UseStringCache -XX:+DisableExplicitGC" export JAVA_OPTS
如您所见,我在所有地方都使用了前缀路径,以避免覆盖系统文件夹中的文件.我不确定100%会解决此问题,但是上述步骤可能会为您提供帮助.
As you can see I have used Prefix path everywhere to avoid overriting files in the system folders. I'm not sure 100% about the reason of the fix, but the mentioned steps may help you.
更新: 在有问题的环境中使用"ldd libtcnative-1.so"进行检查时,系统似乎无法从编译过程中从其获取路径中找到apr和openssl库时,将它们从默认系统文件夹中获取,这是令人惊讶的-没有ECC的Hello OpenSSL. 因此,如果您将这3个文件都放在同一位置,然后将这个预先配置的文件夹复制到一个保持相同路径的新系统中(如有必要),那么一切都应该正常工作而无需接触任何系统库.
Update: Checking with "ldd libtcnative-1.so" on the problematic environment it looks like when the system cannot find apr and openssl libraries from the paths from where they were taken during the compilation it takes them from default system folder and here is the surprise - Hello OpenSSL without ECC. So if you build all 3 in the same place and just copy this preconfigured folder to a new system maintaining the same path (if necessary) - everything should work without touching any system libraries.
这篇关于Tomcat + OpenSSL符号查找错误未定义符号EC_KEY_new_by_curve_name的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!