PYODBC Cannot find driver for MSSQL - python-3.x

I am attempting to connect to SQL Server using a simple python script that looks like the following.
import pyodbc
details = {
'server': '<hostname>',
'database': '<database>',
'username': '<username>',
'password': '<password>'
}
connect_string = 'DRIVER={{ODBC Driver 17 for SQL Server}};SERVER={server};PORT=1443;DATABASE={database};UID={username};PWD={password}'.format(**details)
connection = pyodbc.connect(connect_string)
print(connection)
The only difference is that I have removed the config value for obvious reasons. However, when I run this script I get the following error:
Traceback (most recent call last):
File "connect.py", line 12, in <module>
connection = pyodbc.connect(connect_string)
pyodbc.Error: ('01000', "[01000] [unixODBC][Driver Manager]Can't open lib 'ODBC Driver 17 for SQL Server' : file not found (0) (SQLDriverConnect)")
For reference the output of runnning odbcinst -j gives me:
unixODBC 2.3.4
DRIVERS............: /etc/odbcinst.ini
SYSTEM DATA SOURCES: /etc/odbc.ini
FILE DATA SOURCES..: /etc/ODBCDataSources
USER DATA SOURCES..: /home/bipvanwinkle/.odbc.ini
SQLULEN Size.......: 8
SQLLEN Size........: 8
SQLSETPOSIROW Size.: 8
cat /etc/odbcinst.ini:
[SQLServer]
Description = ODBC Driver 17 for SQL Server
Driver = /usr/lib/x86_64-linux-gnu/libodbc.so
Setup = /usr/lib/x86_64-linux-gnu/libodbc.so.1
UsageCount = 1
FileUsage = 1
cat /etc/odbc.ini:
[SQLServer]
Description = ODBC Driver 17 for SQL Server
Driver = /usr/lib/x86_64-linux-gnu/libodbc.so
Servername =
Database =
UID =
Port = 1433
ls /usr/lib/x86_64-linux-gnu/libodbc.so:
/usr/lib/x86_64-linux-gnu/libodbc.so
ldd /usr/lib/x86_64llinux-gnu/libodbc.so:
linux-vdso.so.1 (0x00007ffc86bec000)
libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f9841306000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f98410e7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9840cf6000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9840af2000)
/lib64/ld-linux-x86-64.so.2 (0x00007f984177d000)
If it helps, both /etc/odbcinst.ini and /etc/odbc.ini were initially empty. I used a template I found online to fill them out. I definitely could have made errors.
Any ideas where I've gone wrong?
P.S. I'm running this on Ubuntu 17.10

Related

logstash Error: com.mariadb.jdbc.Driver not loaded

I'm trying to sync some tables from MariaDB to ElasticSearch using LogStash.
I'm on a Debian Buster (10) Server
$ java -version
openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment (build 11.0.4+11-post-Debian-1deb10u1)
OpenJDK 64-Bit Server VM (build 11.0.4+11-post-Debian-1deb10u1, mixed mode, sharing)
$ mariadb --version
mariadb Ver 15.1 Distrib 10.3.15-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
$ /usr/share/logstash/bin/logstash --version
logstash 7.2.0
I tried different connectors :
$ ls -l /usr/share/java/
mariadb-java-client.jar
$ ls -l /etc/logstash/connectors/
mariadb-java-client-2.1.2.jar
mariadb-java-client-2.2.6.jar
mariadb-java-client-2.3.0.jar
mariadb-java-client-2.4.2.jar
mysql-connector-java-8.0.17.jar
Using "org.mariadb.jdbc.Driver" for mariadb connectors and "com.mysql.cj.jdbc.Driver" for mysql connector
$ cat /etc/logstash/conf.d/db-fr-bank.conf
input {
jdbc {
jdbc_connection_string => "jdbc:mariadb://localhost:3306/db_fr"
jdbc_user => "logstash"
jdbc_password => "<password>"
jdbc_driver_library => "/usr/share/java/mariadb-java-client.jar"
jdbc_driver_class => "org.mariadb.jdbc.Driver"
statement => "SELECT * FROM bank"
}
}
output {
elasticsearch {
hosts => "localhost:9200"
index => "fr-bank"
}
}
But, instead of syncing, i keep getting :
$ /usr/share/logstash/bin/logstash -f /etc/logstash/conf.d/db-fr-bank.conf
...
[ERROR] 2019-07-29 02:08:17.563 [[main]<jdbc] jdbc - Failed to load /usr/share/java/mariadb-java-client.jar {:exception=>#<TypeError: failed to coerce jdk.internal.loader.ClassLoaders$AppClassLoader to java.net.URLClassLoader>}
[ERROR] 2019-07-29 02:08:17.598 [[main]<jdbc] javapipeline - A plugin had an unrecoverable error. Will restart this plugin.
Pipeline_id:main
Plugin: <LogStash::Inputs::Jdbc jdbc_user=>"logstash", jdbc_password=><password>, statement=>"SELECT * FROM bank", jdbc_driver_library=>"/usr/share/java/mariadb-java-client.jar", jdbc_connection_string=>"jdbc:mariadb://localhost:3306/db_fr", id=>"38a6d112755a5e87278761cf5f41b7e509212d1d02837a03672df2face00943a", jdbc_driver_class=>"org.mariadb.jdbc.Driver", enable_metric=>true, codec=><LogStash::Codecs::Plain id=>"plain_f3094292-7482-4b73-95c4-7f78da4da911", enable_metric=>true, charset=>"UTF-8">, jdbc_paging_enabled=>false, jdbc_page_size=>100000, jdbc_validate_connection=>false, jdbc_validation_timeout=>3600, jdbc_pool_timeout=>5, sql_log_level=>"info", connection_retry_attempts=>1, connection_retry_attempts_wait_time=>0.5, parameters=>{"sql_last_value"=>1970-01-01 00:00:00 UTC}, last_run_metadata_path=>"/root/.logstash_jdbc_last_run", use_column_value=>false, tracking_column_type=>"numeric", clean_run=>false, record_last_run=>true, lowercase_column_names=>true>
Error: org.mariadb.jdbc.Driver not loaded. Are you sure you've included the correct jdbc driver in :jdbc_driver_library?
Exception: LogStash::ConfigurationError
Stack: /usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-input-jdbc-4.3.13/lib/logstash/plugin_mixins/jdbc/jdbc.rb:163:in `open_jdbc_connection'
/usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-input-jdbc-4.3.13/lib/logstash/plugin_mixins/jdbc/jdbc.rb:221:in `execute_statement'
/usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-input-jdbc-4.3.13/lib/logstash/inputs/jdbc.rb:277:in `execute_query'
/usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-input-jdbc-4.3.13/lib/logstash/inputs/jdbc.rb:263:in `run'
/usr/share/logstash/logstash-core/lib/logstash/java_pipeline.rb:309:in `inputworker'
/usr/share/logstash/logstash-core/lib/logstash/java_pipeline.rb:302:in `block in start_input'
...
Same issue here.
I use the workaround from here with this and it works.
ie:
Copy the driver file to {logstash install dir}/logstash-core/lib/jars/ directory. These jars get added to the correct JDK classpath as logstash is started via java.
And
Change the jdbc_driver_library value in the logstash conf to "". i.e.: jdbc_driver_library => "" as well, otherwise the code still tries to load the jar separately

psycopg2 ImportError: undefined symbol: PQconninfo

Couldn't able to import psycopg2
Output in python console:
import psycopg2
Traceback (most recent call last):
File "", line 1, in
File "/home/user/.py_virtualenvs/verb_py3/lib/python3.5/site-packages/psycopg2/init.py", line 50, in
from psycopg2._psycopg import ( # noqa
ImportError: /home/user/.py_virtualenvs/verb_py3/lib/python3.5/site-packages/psycopg2/_psycopg.cpython-35m-x86_64-linux-gnu.so: undefined symbol: PQconninfo
Installed the psycopg2-binary package solved my issue.
pip install psycopg2-binary
This might be a defect problem in the underlying system. There might be multiple version of shared library, and at runtime you may not be able to find the proper library. It is usually painful to resolve. Since I am seeing the same problem, I will give a try at how to figure out the problem. This will be more useful than giving a fixed solution. I still have to find a solution for myself: 1. build the libpq library from a newer version. 2. find the proper libpq that was used at compile time by psycopg2.
Go to the source directory of psycopg2:
myuid#mycomputer:~/Downloads/psycopg2$ find . -name "*.c" | xargs grep PQconninfo
./psycopg/psycopgmodule.c: PQconninfoOption *options = NULL;
./psycopg/psycopgmodule.c: options = PQconninfoParse(Bytes_AS_STRING(dsn), &err);
./psycopg/psycopgmodule.c: PyErr_SetString(OperationalError, "PQconninfoParse() failed");
./psycopg/psycopgmodule.c: PQconninfoFree(options); /* safe on null */
./psycopg/connection_int.c: PQconninfoOption *connopts, *ptr;
./psycopg/connection_int.c: connopts = PQconninfoParse(pgdsn, NULL);
./psycopg/connection_int.c: PQconninfoFree(connopts);
./psycopg/connection_int.c: PQconninfoOption *options = NULL;
./psycopg/connection_int.c: if (!(options = PQconninfoParse(dsn, NULL))) {
./psycopg/connection_int.c: PQconninfoFree(options);
./psycopg/conninfo_type.c:".. seealso:: libpq docs for `PQconninfo()`__ for details.\n"
./psycopg/conninfo_type.c: PQconninfoOption *options = NULL;
./psycopg/conninfo_type.c: if (!(options = PQconninfo(self->conn->pgconn))) {
./psycopg/conninfo_type.c: PQconninfoFree(options);
./psycopg/conninfo_type.c: PyErr_SetString(NotSupportedError, "PQconninfo not available in libpq < 9.3");
./psycopg/connection_type.c: PQconninfoOption *options = NULL;
./psycopg/connection_type.c: if (!(options = PQconninfo(self->pgconn))) {
./psycopg/connection_type.c: PQconninfoFree(options);
./psycopg/connection_type.c: PyErr_SetString(NotSupportedError, "PQconninfo not available in libpq < 9.3");
./psycopg/utils.c:/* Make a dict out of PQconninfoOption array */
./psycopg/utils.c:psyco_dict_from_conninfo_options(PQconninfoOption *options, int include_password)
./psycopg/utils.c: PQconninfoOption *o;
Note: psycopg author already gave you an answer by the line:
"PQconninfo not available in libpq < 9.3"
Which means that the problem is the older libpq at RUNTIME, you probably used a newer version of libpq otherwise, psycopg2 may not compile.
By the line: PQconninfo(self->conn->pgconn)
You know that PQconninfo is a C function and it should be in your libpq
Your error message usually tells you where is the problem, in my case it is:
/usr/local/lib/python3.8/site-packages/psycopg2-2.8.5.dev0-py3.8-linux-x86_64.egg/psycopg2
Full error: >>> import psycopg2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.8/site-packages/psycopg2-2.8.5.dev0-py3.8-linux-x86_64.egg/psycopg2/__init__.py", line 50, in <module>
from psycopg2._psycopg import ( # noqa
ImportError: /usr/local/lib/python3.8/site-packages/psycopg2-2.8.5.dev0-py3.8-linux-x86_64.egg/psycopg2/_psycopg.cpython-38-x86_64-linux-gnu.so: undefined symbol: PQconninfo
Here you should find a shared library:
_psycopg.cpython-38-x86_64-linux-gnu.so
Take a look at the library:
ldd _psycopg.cpython-38-x86_64-linux-gnu.so
linux-vdso.so.1 => (0x00007ffe985c7000)
libpq.so.5 => /usr/lib64/libpq.so.5 (0x00007ff922a13000)
libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007ff9227f7000)
libc.so.6 => /usr/lib64/libc.so.6 (0x00007ff922429000)
libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007ff9221b7000)
libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00007ff921d54000)
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007ff921a6b000)
libcom_err.so.2 => /usr/lib64/libcom_err.so.2 (0x00007ff921867000)
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007ff92161a000)
libldap_r-2.4.so.2 => /usr/lib64/libldap_r-2.4.so.2 (0x00007ff9213bb000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff922e87000)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007ff921188000)
libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007ff920f84000)
libz.so.1 => /usr/lib64/libz.so.1 (0x00007ff920d6e000)
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007ff920b5e000)
libkeyutils.so.1 => /usr/lib64/libkeyutils.so.1 (0x00007ff92095a000)
libresolv.so.2 => /usr/lib64/libresolv.so.2 (0x00007ff920741000)
liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007ff920532000)
libsasl2.so.3 => /usr/lib64/libsasl2.so.3 (0x00007ff920315000)
libssl3.so => /usr/lib64/libssl3.so (0x00007ff9200bc000)
libsmime3.so => /usr/lib64/libsmime3.so (0x00007ff91fe94000)
libnss3.so => /usr/lib64/libnss3.so (0x00007ff91fb65000)
libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007ff91f935000)
libplds4.so => /usr/lib64/libplds4.so (0x00007ff91f731000)
libplc4.so => /usr/lib64/libplc4.so (0x00007ff91f52c000)
libnspr4.so => /usr/lib64/libnspr4.so (0x00007ff91f2ee000)
libselinux.so.1 => /usr/lib64/libselinux.so.1 (0x00007ff91f0c7000)
libcrypt.so.1 => /usr/lib64/libcrypt.so.1 (0x00007ff91ee90000)
librt.so.1 => /usr/lib64/librt.so.1 (0x00007ff91ec88000)
libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007ff91ea26000)
libfreebl3.so => /usr/lib64/libfreebl3.so (0x00007ff91e823000)
Notice the line: libpq.so.5 => /usr/lib64/libpq.so.5
Now take a look at this library and only interested in the PPconninfo (it has a lots of functions and data)
nm -D /usr/lib64/libpq.so.5 | grep PQconninfo
000000000000cb90 T PQconninfoFree
000000000000df30 T PQconninfoParse
See you don't have PQconninfo function.
I believe it is more helpful by illustrating how to solve this problem; this may help you solve many similar problems.
Now I will add the solution on my system:
It turned out that there are multiple libpg on my system.
cd /usr
find . -name "libpq*"
... many others ignored
./pgsql-11/lib/libpq.so
Then update LD_LIBRARY_PATH to /usr/pgsql-11/lib:/usr/local/lib64, then the problem is gone.
python3.8
Python 3.8.1 (default, Jan 7 2020, 15:07:37)
[GCC 7.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import psycopg2
Re-installing psycopg2 using conda instead of using pip resolved the issue.
Just like #Kemin Zhou has said in one of the answers, one of the reasons for this problem could be an older libpq.so file.
I'm currently using Cent OS 7 and the version of postgresql-lib installed was:
$ yum list installed | grep postgres
Failed to set locale, defaulting to C
postgresql.x86_64 9.2.24-4.el7_8 installed
postgresql-devel.x86_64 9.2.24-4.el7_8 installed
postgresql-libs.x86_64 9.2.24-4.el7_8 installed
And I was not even able to update it because yum was unable to find the later versions for it:
$ yum list --showduplicates postgresql
Failed to set locale, defaulting to C
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
* epel: mirrors.ircam.fr
Installed Packages
postgresql.x86_64 9.2.24-4.el7_8 installed
Available Packages
postgresql.i686 9.2.24-2.el7 base
postgresql.x86_64 9.2.24-2.el7 base
postgresql.i686 9.2.24-2.el7_7 updates
postgresql.x86_64 9.2.24-2.el7_7 updates
postgresql.i686 9.2.24-4.el7_8 updates
postgresql.x86_64 9.2.24-4.el7_8 updates
This link helped me out.
Using that link I first added this repo that contained the updated postgresql10-libs:
$ yum install https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
and then I installed the updated postgresql10-libs
$ yum install postgresql10-libs.x86_64

How to connect remote SQL SERVER DB with python and convert tables into Pandas Data frame

I am using ubuntu and python3.5
Trying to connect with remote database with credentials(demo)
jdbc_host = '57.56.254.98'
jdbc_port = '21433'
jdbc_user = 'username'
jdbc_pass = "password"
jdbc_dbname = 'database'
jdbc_server=jdbc_host+':'+jdbc_port
jdbc_url = 'jdbc:sqlserver://{0}:{1}'.format(jdbc_host, jdbc_port,jdbc_dbname)
jdbc_driver_path = 'sqljdbc41.jar'
configProperties = {
'user':jdbc_user,
'password':jdbc_pass
}
i have tried pyodbc, pymssql, and pypyodbc with the following code
con = pyodbc.connect("DRIVER={SQL Server};server=jdbc_server;database=jdbc_dbname;uid=jdbc_user,pwd=jdpc_pass")
and similar code example i found from many sites all of them returns some errors like
Error: ('01000', "[01000] [unixODBC][Driver Manager]Can't open lib 'SQL Server' : file not found (0) (SQLDriverConnect)")
i tried configuring FreeTDS server but it returns error
Authentication failed for user 'username'
although i can connect this database with pyspark using this code with same credentials
marksInfo = spark.read.jdbc(url=jdbc_url, table='tablename', properties=configProperties)
I can read and process data from it using pyspark but its kinda slow for this small database in 'Action' operations so looking for alternatives
Hope i am clear
Thanks any help will be appreciated
/etc/odbcinst.ini
[SQL Server]
Description = TDS driver (Sybase/MS SQL)
# Some installations may differ in the paths
#Driver = /usr/lib/odbc/libtdsodbc.so
#Setup = /usr/lib/odbc/libtdsS.so
Driver = /usr/lib/x86_64-linux-gnu/odbc/libtdsodbc.so
Setup = /usr/lib/x86_64-linux-gnu/odbc/libtdsS.so
CPTimeout =
CPReuse =
FileUsage = 1
result for command : ldd /usr/lib/x86_64-linux-gnu/odbc/libtdsodbc.so
linux-vdso.so.1 => (0x00007ffc36b38000)
libodbcinst.so.2 => /usr/local/lib/libodbcinst.so.2 (0x00007f28212f3000)
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f28210a9000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f2820d78000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2820b5b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2820791000)
libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f2820586000)
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f28202b4000)
libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f2820085000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f281fe80000)
libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f281fc75000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f281fa5b000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f281f7f6000)
libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 (0x00007f281f5c3000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f281f3b0000)
libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007f281f179000)
libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007f281ef46000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f281ecc6000)
/lib64/ld-linux-x86-64.so.2 (0x0000560d012ae000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f281eac1000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f281e8bd000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f281e6a2000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f281e499000)
i can connect using tsql with the database
tsql -S server:port -U username -P 'p#sword\\'
But pyodbc throws this error
Error: ('01000', "[01000] [unixODBC][Driver Manager]Can't open lib 'FreeTDS' : file not found (0) (SQLDriverConnect)")

gDebugger libGL error on linux

I'm trying to debug my OpenGl project with gDEBugger, but unfortunately gDEBugger is not even starting:
~/bin/gDEBugger581-x86_64> ./gDEBugger-bin
libGL error: failed to load driver: swrast
libGL error: Try again with LIBGL_DEBUG=verbose for more details.
Segmentation fault
~/bin/gDEBugger581-x86_64> LIBGL_DEBUG=verbose ./gDEBugger-bin
libGL: screen 0 does not appear to be DRI2 capable
libGL: OpenDriver: trying /usr/lib64/dri/updates/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/updates/swrast_dri.so
libGL error: dlopen /usr/lib64/dri/updates/swrast_dri.so failed (/usr/lib64/dri/updates /swrast_dri.so: cannot open shared object file: No such file or directory)
libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so
libGL error: dlopen /usr/lib64/dri/swrast_dri.so failed (/usr/lib64/dri/swrast_dri.so: undefined symbol: _glapi_tls_Dispatch)
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
Segmentation fault
this happens with the last gremedy version (5.8.1), the last AMD version (6.2.4) and the latest CodeXL version (CodeXL doesn't crash, but the same error appears non the less and debugging doesn't work).
I'm on OpenSuse 13.1, I have a NVIDIA card and the latest drivers installed. Other OpenGL programms work just fine. So far I've tried to reinstall NVIDIA drivers, reinstall all MESA packages, update CUDA from 5.5 to 6.5, checked that all mesa packages are installed from the standard suse repo and ran ldd:
~/bin/gDEBugger581-x86_64> ldd gDEBugger-bin
linux-vdso.so.1 (0x00007fffe9ffe000)
libGRBaseTools.so => ./libGRBaseTools.so (0x00007f41df93e000)
libGROSWrappers.so => ./libGROSWrappers.so (0x00007f41df6cc000)
libGRAPIClasses.so => ./libGRAPIClasses.so (0x00007f41df358000)
libGRProcessDebugger.so => ./libGRProcessDebugger.so (0x00007f41df123000)
libGRApiFunctions.so => ./libGRApiFunctions.so (0x00007f41deedf000)
libGRApplicationComponents.so => ./libGRApplicationComponents.so (0x00007f41debce000)
libgDEBuggerAppCode.so => ./libgDEBuggerAppCode.so (0x00007f41de5b0000)
libwx_base-2.8.so.0 => ./libwx_base-2.8.so.0 (0x00007f41de29e000)
libwx_gtk2_core-2.8.so.0 => ./libwx_gtk2_core-2.8.so.0 (0x00007f41ddcd9000)
libwx_gtk2_html-2.8.so.0 => ./libwx_gtk2_html-2.8.so.0 (0x00007f41dda2f000)
libwx_gtk2_adv-2.8.so.0 => ./libwx_gtk2_adv-2.8.so.0 (0x00007f41dd753000)
libwx_gtk2_aui-2.8.so.0 => ./libwx_gtk2_aui-2.8.so.0 (0x00007f41dd4e2000)
libwx_gtk2_gl-2.8.so.0 => ./libwx_gtk2_gl-2.8.so.0 (0x00007f41dd2d5000)
libwx_gtk2_stc-2.8.so.0 => ./libwx_gtk2_stc-2.8.so.0 (0x00007f41dcfcb000)
libfreeimage.so.3 => ./libfreeimage.so.3 (0x00007f41dcc35000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f41dc92d000)
libm.so.6 => /lib64/libm.so.6 (0x00007f41dc62a000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f41dc413000)
libc.so.6 => /lib64/libc.so.6 (0x00007f41dc065000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f41dbe61000)
librt.so.1 => /lib64/librt.so.1 (0x00007f41dbc59000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f41dba3b000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f41db6fd000)
libz.so.1 => /lib64/libz.so.1 (0x00007f41db4e7000)
libGL.so.1 => /usr/X11R6/lib64/libGL.so.1 (0x00007f41db19b000)
libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x00007f41dab5c000)
libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x00007f41da8a7000)
libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x00007f41da683000)
libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007f41da31c000)
libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x00007f41da108000)
libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00007f41d9ee7000)
libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007f41d9c9b000)
libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f41d9a09000)
libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f41d97cc000)
libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007f41d957b000)
libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007f41d9377000)
libgthread-2.0.so.0 => /usr/lib64/libgthread-2.0.so.0 (0x00007f41d9175000)
libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f41d8e72000)
libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00007f41d8c6f000)
libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00007f41d8a69000)
libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007f41d8861000)
libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00007f41d85e2000)
/lib64/ld-linux-x86-64.so.2 (0x00007f41dfb49000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f41d83c3000)
libnvidia-tls.so.340.32 => /usr/lib64/tls/libnvidia-tls.so.340.32 (0x00007f41d81c0000)
libnvidia-glcore.so.340.32 => /usr/lib64/libnvidia-glcore.so.340.32 (0x00007f41d55ad000)
libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f41d539b000)
libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007f41d518e000)
libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007f41d4f88000)
libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007f41d4c69000)
libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f41d4a5f000)
libXi.so.6 => /usr/lib64/libXi.so.6 (0x00007f41d484f000)
libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007f41d4645000)
libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007f41d443a000)
libXcomposite.so.1 => /usr/lib64/libXcomposite.so.1 (0x00007f41d4237000)
libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007f41d4034000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f41d3e10000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f41d3bf9000)
libharfbuzz.so.0 => /usr/lib64/libharfbuzz.so.0 (0x00007f41d39a6000)
libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f41d3769000)
libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f41d353f000)
libffi.so.4 => /usr/lib64/libffi.so.4 (0x00007f41d3337000)
libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007f41d30d1000)
libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007f41d2eb5000)
libuuid.so.1 => /usr/lib64/libuuid.so.1 (0x00007f41d2cb0000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f41d2aac000)
libpixman-1.so.0 => /usr/lib64/libpixman-1.so.0 (0x00007f41d2803000)
libEGL.so.1 => /usr/X11R6/lib64/libEGL.so.1 (0x00007f41d24fa000)
libxcb-shm.so.0 => /usr/lib64/libxcb-shm.so.0 (0x00007f41d22f7000)
libxcb-render.so.0 => /usr/lib64/libxcb-render.so.0 (0x00007f41d20ed000)
libgraphite2.so.3 => /usr/lib64/libgraphite2.so.3 (0x00007f41d1ed1000)
libnvidia-glsi.so.340.32 => /usr/lib64/libnvidia-glsi.so.340.32 (0x00007f41d1c49000)
I noticed, that when running my own program with LIBGL_DEBUG=verbose there is not libGL output at all. I'm using glfw 2.7 and glew 1.9 if it matters. glut apps work.
I suppose that gDEBugger has a different way to find and load libGL and somehow it ends up using the mesa one and not the nvidia one. but my knowledge of mesa and nvidia driver and the workings of it are quite limited.
edit:
new information:
strace -e open ./gDEBugger-bin 2>&1 | grep libGL.so
open("./tls/x86_64/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./tls/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./x86_64/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("./libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/mpi/gcc/openmpi/lib64/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/damdam/bin/pgmodeler/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib64/libGL.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/usr/X11R6/lib64/libGL.so.340.32", O_RDONLY) = 3
open("/usr/X11R6/lib64/libGL.so.340.32", O_RDONLY) = 3
open("/usr/X11R6/lib64/libGL.so.340.32", O_RDONLY) = 4
open("/usr/lib64/libGL.so.1", O_RDONLY|O_CLOEXEC) = 7
open("/usr/X11R6/lib64/libGL.so.340.32", O_RDONLY) = 7
open("/usr/lib64/libGL.so.1", O_RDONLY) = 7
for comparison, this is the same for a working program: http://paste.opensuse.org/76645738
and this is the full output (without grep): http://paste.opensuse.org/8336779
i tried to setup the following links in /usr/lib64/:
libGLESv1_CM.so -> /usr/X11R6/lib64/libGLES
libGLESv1_CM.so.1 -> /usr/X11R6/lib64/libGL
libGLESv1_CM.so.1.1.0 -> /usr/X11R6/lib64/l
libGLESv2.so -> /usr/X11R6/lib64/libGLESv2.
libGLESv2.so.2 -> /usr/X11R6/lib64/libGLESv
libGLESv2.so.2.0.0 -> /usr/X11R6/lib64/libG
libGL.so -> /usr/X11R6/lib64/libGL.so
libGL.so.1 -> /usr/X11R6/lib64/libGL.so
libGL.so.1.2 -> /usr/X11R6/lib64/libGL.so
libGL.so.1.2.0 -> /usr/X11R6/lib64/libGL.so
after that the behaviour changed, the program crashed with a segfault and not printing anything.
edit:
new information
the gremedy gDEBugger (5.8.1) doesn't load /usr/lib64/libGL.so any more when
export LIBGL_DRIVERS_PATH="/usr/X11R6/lib64/"
it just crashes. so my guess is now, that it knew about the correct libGL all the time, but couldn't load it. either there is something strange with my system, or i'm the first reporting about this problem.
I had the same problem with the same distro, same release. Eventually I traced it to the environment variable LD_LIBRARY_PATH.
I had added /usr/lib/ and /usr/lib64/ to LD_LIBRARY_PATH to try to resolve a linking problem. It seems including those directories in LD_LIBRARY_PATH meant /usr/lib64/libGL.so.1 from the package Mesa-libGL1 hid /usr/X11R6/lib64/libGL.so.1 from the package x11-video-nvidiaG02.
Re-exporting LD_LIBRARY_PATH without those two directories had libGL sorted out and working again.
The error messages indicate that for some reason gDEBugger dynamically links a Mesa variant of libGL.so (only Mesa tries to talk the DRI protocol). With your NVidia GPU in the system and I presume the NVidia proprietary drivers being installed and configured as well, this indicates, something is seriously off.
The other possibility is, that you're don't have the NVidia proprietary drivers installed at all and are running completely off Mesa. The problem is, that the NVidia GPU support of Mesa is only rudimentary for any GPU built past 2005.
Note that if you're using the NVidia proprietary drivers you don't need Mesa being installed at all (although having it and using the Mesa libGL.so as linking target for your programs, even if the NVidia libGL.so is used at runtime is quite sensible).

HTML::TagFilter command line vs apache

I installed HTML::TagFilter from CPAN on a Fedora machine
This snippet works just fine on the command line :
my $tf = new HTML::TagFilter;
$tf->deny_tags( { TABLE => {style => ["BORDER-BOTTOM"]} });
$tf->deny_tags( { TABLE => {prevstyle => ['any']} }); $str = $tf->filter($str);
But when the same code is run on Apache, I am getting this error:
[Fri Dec 14 16:11:48 2012] [error] Can't locate object method "new" via
package "HTML::TagFilter" at
/usr/local/lib/perl5/site_perl/5.10.0/HTML/TagFilter.pm line 320.
What could be the source of this error?

Resources