I'm trying to set up unixODBC to connect to a Netezza database, however I'm getting a "Undefined symbol: SSL_connect" when I try to connect using isql.
Currently using: CentOS 5.5, unixODBC 2.3.0 (Same issue with 2.2.11).
I have done the following:
Configured the LD_LIBRARY_PATH, ODBCINI, and NZ_INI_FILE_PATH according to the README.txt that came with the ODBC drivers.
Ensued that all libraries are loaded by using the ldd command and setting up symbolic links for libssl and libcrypto.
Updated the /etc/ld.so.conf file to ensure the netezza drivers path is loaded.
Used nm to confirm that the SSL_connect symbol is in the driver.
Running dltest against the file for this symbol reports a "file not found" error, which is what I normally get when I try to run isql -v, however I changed the LD_DEBUG environment variable to get additional debugging info, which led me to SSL_connect.
(FYI, export LD_DEBUG=files isql sospos is what I used.)
Any thoughts? This is driving my crazy as it appears everything is there, but it's still not working. Worst part is that I set up the same thing on Ubuntu 10.10 months ago and it worked without any issues.
UPDATE:
First, ldd on the libnzodbc.so file looks good. All dependencies have been satisfied.
Second, the only thing I could see in the file that was missing was the libc.mo file for the en_US locale, so I set up a symbolic link to the en_GB one. Unfortunately, it's still throwing the same error even though it it looks like it found every other lib it's looking for. Is there anything else in the strace output I should be looking for?
UPDATE 2:
An issue I'm currently seeing is that isql is looking for gconv_end in ISO8859-1.so, however that symbol does not exist. Interestingly enough, the symbol does not exist on my Ubuntu server VM and isql works fine. Both versions of unixODBC I specified above have the same issue.
UPDATE 3:
O.K. Re-ran ldd with the -d and -r options and yes, there are still issues. Every SSL* symbol is missing. I'm guessing this means that I created a symbolic link to the wrong file. Anyone know which ssl library file contains SSL_connect?
O.K. Figured it out. It turns out the symbolic link I created was pointing to the wrong library file. Originally I did this:
(/usr/lib/) ln -s libssl3.so libssl.so.4
I should have done this:
(/usr/lib) ln -s ../../lib/libssl.so.0.9.8e libssl.so.4
Well, SSL_connect is from the OpenSSL libs. Maybe you could try using strace on isql and post the parts where it fails (I suspect) to load a libssl. It may be that your existing ssl lib doesn't match what the driver is looking for. What does ldd show on the driver lib?
If anyone is still looking at a similar issue, there's a django-netezza package that works well: https://github.com/msabramo/django-netezza
Related
So I've upgraded to a newer version of Linux kernel using Yocto. The new kernel version is for 4.1.15 and runs on an iMX6 chip. I've also included openssh-server, tools-sdk, and tools-debug for development recipes. The problem is that when I connect to build I get the following error:
loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof
(_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))'
failed
Now if I type into the command prompt sh -c "LANG=en_US" I get the same error as above. If I type in sh -c "LANG=/usr/lib/locale/en_US" then I do not get an error. When I type locale everything is listed as POSIX and when I type locale -a I get:
C
POSIX
en_GB
en_US
The last two are stored under /usr/lib/locale. My version of gcc is 5.2 and my glibc is v2.22. I've looked all over the internet for other solutions but they are either for Ubuntu where the package manager comes in handy or it's some really specific fix like editing a file that I don't have in my Yocto build.
Edit:
The machine is for a SMARC-FiMX6 SoM and the instructions are here. I'm not sure what branch of Yocto is being pulled down.
After troubleshooting the problem is from the glibc library. A patch, #114739, is on the openembedded website which details what to do to fix this issue. Just patch the file, rebuild, and the issue is fixed. See here for details, the patch is at the bottom of the page.
I have a problem with the libstdc++.so.6 library when I execute a program in MATLAB. The code works fine on my laptop and my desktop, which is why I'm sure the problem is a library or linking compatibility issue:
/home/arturo/Virality/viral_cluster_ml/Viral_features/code/segment_pedro/segment: error while loading shared libraries: libstdc++.so.6: wrong ELF class: ELFCLASS64
I've google some answers on how to fix the library, and some say that I should remove the library to later re-install the correct version:
error while loading shared libraries: libstdc++.so.6: wrong ELF class: ELFCLASS64
The problem is that I can't afford the luxury to delete a library, because I am ssh'ing to a cluster at the lab I'm working in. I really wouldn't want to mess up any programs that are running at the cluster, so isn't there another way of fixing this problem? I'm hoping a solution similar to:
sudo apt-get install libstd++6
that doesn't require me to delete or modify any files, but rather to install them.
Or maybe the error is that I'm not linking the library correctly?
The file does exist, as when I use
locate libstd++.so.6
the computer finds it at these directories:
/usr/lib64/libstdc++.so.6
/usr/lib64/libstdc++.so.6.0.13
/usr/local/MATLAB/R2012b/sys/os/glnxa64/libstdc++.so.6
/usr/local/MATLAB/R2012b/sys/os/glnxa64/libstdc++.so.6.0.13
/usr/local/MATLAB/R2012b/toolbox/sldv/sldv/polyspace-dvo/lib/x86-linux/libstdc++.so.6
/usr/local/MATLAB/R2012b/toolbox/sldv/sldv/polyspace-dvo/lib/x86-linux/libstdc++.so.6.0.13
/usr/local/MATLAB/R2013a/sys/os/glnxa64/libstdc++.so.6
/usr/local/MATLAB/R2013a/sys/os/glnxa64/libstdc++.so.6.0.13
/usr/local/MATLAB/R2013a_DCS/sys/os/glnxa64/libstdc++.so.6
/usr/local/MATLAB/R2013a_DCS/sys/os/glnxa64/libstdc++.so.6.0.13
/usr/local/Matlab_R2012a/bin/glnxa64/libstdc++.so.6
/usr/local/Matlab_R2012a/bin/glnxa64/libstdc++.so.6.0.13
/usr/local/Matlab_R2012a/sys/os/glnxa64/libstdc++.so.6
/usr/local/Matlab_R2012a/sys/os/glnxa64/libstdc++.so.6.0.13
/usr/local/Matlab_R2012a/toolbox/sldv/sldv/polyspace-dvo/lib/x86-linux/libstdc++.so.6
/usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.py
/usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.pyc
/usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.pyo
/usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.py
/usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.pyc
/usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.pyo
I've also tried setting the path to the the file before running MATLAB, without anyluck:
LD_LIBRARY_PATH=/usr/lib64:/home/arturo/Virality/viral_cluster_ml/Viral_features/code/scene_sun ./matlab
Similar link and problem:
http://www.linuxquestions.org/questions/linux-newbie-8/apt-get-messed-up-812346/
Problem was solved by recompiling a subfolder of the code on the cluster.
It seems like the perl program is trying to load the ODBC.so file instead of the freetds file that should be used instead. It's giving a symbol lookup error message. Trying to find SQLAllocHandle in ODBC.so
Has anyone ran into this error before? Just got done installing the drivers so I'm completely at a loss and utterly confused.
Found out the issue. iodbc drivers were affecting the unixodbc drivers. So I removed the iodbc files from /usr/lib.
Removed the DBD::ODBC module and then reinstalled it.
Fixed.
I was previously running apache 2.2.20 and openssl 1.0.0e. I installed openssl 1.0.1, then downloaded the tarball for apache 2.4.1 and installed apr 1.4.6 & apr-util 1.4.1 with --prefix=/usr/local. I configured apache2 with:
sudo ./configure --prefix=/usr/local/apache2 --enable-mods-shared=all
--enable-deflate --enable-proxy --enable-proxy-balancer --enable-proxy-http
--enable-rewrite --enable-cache --enable-mem-cache --enable-ssl --enable-headers
--with-mpm=worker --with-included-apr
But after running sudo make I get an error:
httpd-2.4.1/support/ab.c:2227: undefined reference to `SSLv2_client_method'
What is causing this error and how do I correct it?
You may have built openssl with SSLv2 disabled, some distributions have that disabled (Debian, starting from 7.0 -Wheezy- is one). Looking at the source, it looks like if you define the OPENSSL_NO_SSL2 preprocessor flag, apache won't call the SSLv2_client_method() function.
You can also download openssl's tarbal and compile openssl with
./config shared no-ssl2
This will set the flag OPENSSL_NO_SSL2 that Jon Lin mentioned.
It has nothing to do with OpenSSL compilation. PHP is the culprit which is causing the error.
(Note: The is another issue with OpenSSL which might prevent u from generating openssl.so and opencrypto.so shared libraries)
Here is the overview of how it happened. PHP compiles its compilation and when "make install" is given it copies the libphp*.so to /usr/local/apache2/modules.
The source code for this error is openssl.c in /usr/local/php-5.5.3/ext/openssl
So the simple solution is to handle it in the top level Makefile. By adding
CPPFLAGS = -D_REENTRANT -DTHREAD=1 -DOPENSSL_NO_SSL2
Make the above change AFTER you run the configure script. Hope this helps :)
Try with another Apache version. With Apache 2.2.15 the error was present but when i change to Apache 2.2.27 the "reference to `SSLv2_client_method" error simply disappeared
The compilation line is:
./configure --with-ssl --enable-ssl
That's all.
I'm on a network where I don't have root access, so everything I install is under a prefix ~/bin (actually referenced by its full path).
So I have openbox working fine, which is what I'm using to send this from. Imlib2 I do ./configure --prefix=~/bin; make; make install.
Then I run from the tint2 source directory
IMLIB2_CFLAGS=-i~/bin/include/Imlib2.h *only typoed here
export IMLIB2_CFLAGS
IMLIB2_LIBS=-l~/bin/lib/libImlib2.a
export IMLIB2_LIBS
./configure --prefix=~/bin
which leaves me with this charming message
checking for IMLIB2... yes
checking for imlib_context_set_display in -lImlib2... no
configure: error: Imlib2 must be built with X support
Edit:
So Imlib2 is now compiled --with-x and installed to the location I'm referencing. I am still receiving an identical error message.
I'm guessing it's because I don't know what the flags are for the initial configure of imlib2?
Probably, yes. ./configure --help will usually give you advice on what to do (i.e., how to pass the correct information to the configure script; but you'll need to find out what that information is a la imlib2).
If your Q is accurate, you should fix the spelling of CLFAGS in the first line.
More generally, you could use:
CPPFLAGS=-I~/bin/include LDFLAGS=-L~/bin/lib ./configure ...
However, as the accepted answer suggests, there is often a direct way to specify the location of pre-requisite software packages.
See also: Linking with a different .so file in Linux.