I am trying to use rrdtool to store and graph the number of BGP updates per origin ASN. I am using the python-rrdtool package to create the RRD and populate it with data parsed from a historical CSV file.
The RRD gets created successfully and the updates seem to be stored correctly:
$ rrdtool fetch -e 1635077700 -s 1635074400 updates-2021-10-25-originas.rrd AVERAGE
45609 9829 4758 24560 134371 45769 45528 134033 134674 17439
1635074700: -nan -nan -nan -nan -nan -nan -nan -nan -nan -nan
1635075000: 5.3247000000e+04 4.7140000000e+03 2.8530000000e+03 1.5900000000e+03 1.8880000000e+03 1.1760000000e+03 9.7800000000e+02 4.8300000000e+02 2.3500000000e+02 5.7900000000e+02
1635075300: 9.0302000000e+04 5.1010000000e+03 2.9060000000e+03 2.6160000000e+03 2.0000000000e+03 1.5190000000e+03 1.3270000000e+03 1.2370000000e+03 1.1120000000e+03 7.8500000000e+02
1635075600: 1.0403100000e+05 5.2270000000e+03 3.0260000000e+03 2.8990000000e+03 2.1260000000e+03 1.5740000000e+03 1.4100000000e+03 1.6890000000e+03 1.7640000000e+03 9.2000000000e+02
1635075900: 9.7802000000e+04 5.2220000000e+03 2.8260000000e+03 2.6140000000e+03 2.0850000000e+03 1.5500000000e+03 1.3400000000e+03 1.8530000000e+03 1.4570000000e+03 9.4600000000e+02
1635076200: 9.1486000000e+04 5.7090000000e+03 3.5840000000e+03 2.8870000000e+03 2.0980000000e+03 1.7810000000e+03 1.2890000000e+03 3.2900000000e+02 3.2900000000e+02 8.6100000000e+02
1635076500: 1.0457200000e+05 6.6210000000e+03 3.6170000000e+03 3.2040000000e+03 2.2840000000e+03 1.8300000000e+03 1.5070000000e+03 1.2450000000e+03 8.1600000000e+02 9.0700000000e+02
1635076800: 6.8104000000e+04 3.2830000000e+03 1.9570000000e+03 1.8700000000e+03 1.7000000000e+03 1.0960000000e+03 9.3700000000e+02 9.1100000000e+02 6.6900000000e+02 6.5600000000e+02
1635077100: 2.5433000000e+04 1.0370000000e+03 7.2600000000e+02 7.4800000000e+02 4.8600000000e+02 3.6000000000e+02 3.8400000000e+02 2.4200000000e+02 1.6900000000e+02 1.8300000000e+02
1635077400: -nan -nan -nan -nan -nan -nan -nan -nan -nan -nan
1635077700: -nan -nan -nan -nan -nan -nan -nan -nan -nan -nan
1635078000: -nan -nan -nan -nan -nan -nan -nan -nan -nan -nan
When I attempt to generate the graph using the command line tool, the process exits with error code 0. But no graph appears to be generated:
$ ls -l
total 260469
-rwxrwxrwx 1 root root 385626 Oct 26 20:41 updates-2021-10-25-head100k.txt.bz2
-rwxrwxrwx 1 root root 7232 Oct 26 11:15 updates-2021-10-25-head1k.txt.bz2
-rwxrwxrwx 1 root root 3653614 Oct 26 23:19 updates-2021-10-25-head1m.txt.bz2
-rwxrwxrwx 1 root root 613376 Oct 27 10:14 updates-2021-10-25-originas.rrd
-rwxrwxrwx 1 root root 613376 Oct 27 10:14 updates-2021-10-25-prefix.rrd
-rwxrwxrwx 1 root root 53683974 Oct 26 18:00 updates-2021-10-25-report.txt
-rwxrwxrwx 1 root root 207761131 Oct 25 13:51 updates-2021-10-25.txt.bz2
$ rrdtool graph -e 1635077700 -s 1635074400 -a PNG updates-2021-10-25-originas.png DEF:45609=updates-2021-10-25-originas.rrd:45609:AVERAGE
$ echo $?
0
$ ls -l
total 260469
-rwxrwxrwx 1 root root 385626 Oct 26 20:41 updates-2021-10-25-head100k.txt.bz2
-rwxrwxrwx 1 root root 7232 Oct 26 11:15 updates-2021-10-25-head1k.txt.bz2
-rwxrwxrwx 1 root root 3653614 Oct 26 23:19 updates-2021-10-25-head1m.txt.bz2
-rwxrwxrwx 1 root root 613376 Oct 27 10:14 updates-2021-10-25-originas.rrd
-rwxrwxrwx 1 root root 613376 Oct 27 10:14 updates-2021-10-25-prefix.rrd
-rwxrwxrwx 1 root root 53683974 Oct 26 18:00 updates-2021-10-25-report.txt
-rwxrwxrwx 1 root root 207761131 Oct 25 13:51 updates-2021-10-25.txt.bz2
I've tried different combinations of command line switches like --imgformat, --height, --width, -t (for title), but nothing seems to work.
(The -s (start time) and -e (end time) switches are in "rrdtool fetch" and "rrdtool graph" to constrain the time period for which I have data.)
I'm running this on Ubuntu 20.04.3, with rrdtool installed from Canonical's repo.
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
Release: 20.04
Codename: focal
$ which rrdtool
/usr/bin/rrdtool
$ dpkg -S /usr/bin/rrdtool
rrdtool: /usr/bin/rrdtool
$ dpkg -l | grep rrdtool
ii python3-rrdtool:amd64 1.7.2-3build2 amd64 time-series data storage and display system (Python3 interface)
ii python3-rrdtool-dbg:amd64 1.7.2-3build2 amd64 time-series data storage and display system (Python3 debug interface)
ii rrdtool 1.7.2-3build2 amd64 time-series data storage and display system (programs)
Some answers I've googled indicated that rrdtool might not have all the libraries it needs. I checked that and everything seems to be okay, with one exception.
$ ldd /usr/bin/rrdtool
linux-vdso.so.1 (0x00007ffd299c6000)
librrd.so.8 => /lib/x86_64-linux-gnu/librrd.so.8 (0x00007f2dde736000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2dde713000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2dde521000)
libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f2dde4e9000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2dde39a000)
libdbi.so.1 => /lib/x86_64-linux-gnu/libdbi.so.1 (0x00007f2dde18a000)
libpangocairo-1.0.so.0 => /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f2dde176000)
libpango-1.0.so.0 => /lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f2dde127000)
libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f2dde0c7000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f2dddf9e000)
libcairo.so.2 => /lib/x86_64-linux-gnu/libcairo.so.2 (0x00007f2ddde7b000)
libxml2.so.2 => /lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f2dddcc1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2dde7b2000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2dddca3000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2dddc9d000)
libpangoft2-1.0.so.0 => /lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f2dddc84000)
libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f2dddc3d000)
libfribidi.so.0 => /lib/x86_64-linux-gnu/libfribidi.so.0 (0x00007f2dddc20000)
libthai.so.0 => /lib/x86_64-linux-gnu/libthai.so.0 (0x00007f2dddc15000)
libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f2dddb0e000)
libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 (0x00007f2dddb02000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f2ddda8f000)
libpixman-1.so.0 => /lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f2ddd9e8000)
libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f2ddd929000)
libxcb-shm.so.0 => /lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f2ddd924000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f2ddd8f8000)
libxcb-render.so.0 => /lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f2ddd8e9000)
libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f2ddd6df000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f2ddd5a2000)
libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007f2ddd58d000)
libicuuc.so.66 => /lib/x86_64-linux-gnu/libicuuc.so.66 (0x00007f2ddd3a7000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f2ddd37c000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f2ddd34e000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f2ddd345000)
libdatrie.so.1 => /lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007f2ddd33b000)
libgraphite2.so.3 => /lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f2ddd30e000)
libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f2ddd306000)
libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f2ddd2fe000)
libicudata.so.66 => /lib/x86_64-linux-gnu/libicudata.so.66 (0x00007f2ddb83d000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2ddb65b000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2ddb640000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f2ddb624000)
$ ls `ldd /usr/bin/rrdtool | sed -e 's/.*=>[ \t]*//' | sed -e 's/ (0x.*//'`
ls: cannot access 'linux-vdso.so.1': No such file or directory
/lib64/ld-linux-x86-64.so.2 /lib/x86_64-linux-gnu/libfribidi.so.0 /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 /lib/x86_64-linux-gnu/libXau.so.6
/lib/x86_64-linux-gnu/libbsd.so.0 /lib/x86_64-linux-gnu/libgcc_s.so.1 /lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 /lib/x86_64-linux-gnu/libxcb-render.so.0
/lib/x86_64-linux-gnu/libcairo.so.2 /lib/x86_64-linux-gnu/libglib-2.0.so.0 /lib/x86_64-linux-gnu/libpcre.so.3 /lib/x86_64-linux-gnu/libxcb-shm.so.0
/lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libgobject-2.0.so.0 /lib/x86_64-linux-gnu/libpixman-1.so.0 /lib/x86_64-linux-gnu/libxcb.so.1
/lib/x86_64-linux-gnu/libdatrie.so.1 /lib/x86_64-linux-gnu/libgraphite2.so.3 /lib/x86_64-linux-gnu/libpng16.so.16 /lib/x86_64-linux-gnu/libXdmcp.so.6
/lib/x86_64-linux-gnu/libdbi.so.1 /lib/x86_64-linux-gnu/libharfbuzz.so.0 /lib/x86_64-linux-gnu/libpthread.so.0 /lib/x86_64-linux-gnu/libXext.so.6
/lib/x86_64-linux-gnu/libdl.so.2 /lib/x86_64-linux-gnu/libicudata.so.66 /lib/x86_64-linux-gnu/librrd.so.8 /lib/x86_64-linux-gnu/libxml2.so.2
/lib/x86_64-linux-gnu/libexpat.so.1 /lib/x86_64-linux-gnu/libicuuc.so.66 /lib/x86_64-linux-gnu/libstdc++.so.6 /lib/x86_64-linux-gnu/libXrender.so.1
/lib/x86_64-linux-gnu/libffi.so.7 /lib/x86_64-linux-gnu/liblzma.so.5 /lib/x86_64-linux-gnu/libthai.so.0 /lib/x86_64-linux-gnu/libz.so.1
/lib/x86_64-linux-gnu/libfontconfig.so.1 /lib/x86_64-linux-gnu/libm.so.6 /lib/x86_64-linux-gnu/libuuid.so.1
/lib/x86_64-linux-gnu/libfreetype.so.6 /lib/x86_64-linux-gnu/libpango-1.0.so.0 /lib/x86_64-linux-gnu/libX11.so.6
I'm suspecting "linux-vdso.so.1" may be a red herring since I'm able to run rrdtool with no missing-library errors.
What would cause rrdtool graph not to generate any output file?
After some readjustment of my search terms, I did find the answer here (thank you thank you jwilson!)
From the rrdtool graph documentation:
You need at least one DEF and one LINE, AREA, GPRINT, PRINT statement to generate anything useful.
The documentation is not clear that, if you do not have a LINE, AREA, GPRINT or PRINT statement, no file gets written and rrdtool exits without doing anything.
Related
When I run
$ python manage.py inspectdb --database=mssql_database
I have the following error
django.db.utils.Error: ('01000', "[01000] [unixODBC][Driver Manager]Can't open lib '/opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.9.so.1.1' : file not found (0) (SQLDriverConnect)")
but the file libmsodbcsql-17.9.so.1.1 is there.
$ cat /etc/odbcinst.ini
[ODBC]
Trace=Yes
TraceFile=/tmp/odbc.log
[FreeTDS]
Description=TDS driver (Sybase/MS SQL)
Driver=libtdsodbc.so
Setup=libtdsS.so
CPTimeout=
CPReuse=
UsageCount=2
[ODBC Driver 17 for SQL Server]
Description=Microsoft ODBC Driver 17 for SQL Server
Driver=/opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.9.so.1.1
UsageCount=1
$ odbcinst -j
unixODBC 2.3.7
odbcinst: symbol lookup error: odbcinst: undefined symbol: odbcinst_system_file_name
$ ldd /opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.9.so.1.1
linux-vdso.so.1 (0x00007fff545c4000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9f85470000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f9f85268000)
libodbcinst.so.2 => /home/pd/sibp/env/lib/python3.6/site-packages/sqlanydb-1.0.11.dist-info/lib64/libodbcinst.so.2 (0x00007f9f84fcc000)
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f9f84cf6000)
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f9f84aab000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f9f84722000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9f84384000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9f8416c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9f83f4d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9f83b5c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9f85a80000)
libdbtasks17_r.so => /home/pd/sibp/env/lib/python3.6/site-packages/sqlanydb-1.0.11.dist-info/lib64/libdbtasks17_r.so (0x00007f9f83912000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f9f836f8000)
libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f9f834c6000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f9f832c2000)
libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f9f830b7000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f9f82eb3000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f9f82c99000)
OS: Ubuntu 18.04.6 LTS
I started fresh with clean system and I'm creating snapshots of my virtualbox now. This happens as a result of installing SQL Anywhere Database Client.
See here. I need SQL Anywhere Database Client to work with Sybase. After finishing this installation I have the above error.
$ pip list
Package Version
------------- -------
Django 1.8
django-pyodbc 1.1.3
pip 21.3.1
pyodbc 4.0.32
setuptools 59.6.0
sqlany-django 1.13
sqlanydb 1.0.11
wheel 0.37.1
While not a complete answer for this particular case, the following information may be helpful for others having difficulty using both sqlanydb (for SAP SQL Anywhere) and pyodbc (for Microsoft SQL Server) on the same machine.
The SQL Anywhere setup instructions cited in the question instruct us to
source "/opt/sqlanywhere17/bin64/sa_config.sh"
in .bashrc. That script includes, in part
LD_LIBRARY_PATH="$SQLANY17/lib32:${LD_LIBRARY_PATH:-}"
LD_LIBRARY_PATH="$SQLANY17/lib64:${LD_LIBRARY_PATH:-}"
export LD_LIBRARY_PATH
which prepends the SQLANY17/ directories to any existing LD_LIBRARY_PATH. On a vanilla install of Xubuntu 20.04 there is no LD_LIBRARY_PATH defined, so the net result is
$ echo $LD_LIBRARY_PATH
/opt/sqlanywhere17/lib64:/opt/sqlanywhere17/lib32:
That works fine for sqlanydb
# any.py
import sqlanydb
# Initiate connection to the database
DB_PARAMS = {"HOST": "192.168.0.199",
"USER": "dba",
"PASSWORD":"sql",
"DB":""}
conn = sqlanydb.connect(host=DB_PARAMS['HOST'], uid=DB_PARAMS['USER'], pwd=DB_PARAMS['PASSWORD'], dbn=DB_PARAMS['DB'])
# Instantiate cursor
curs = conn.cursor()
# Execute a query
curs.execute("SELECT 'success' as connection_status FROM SYS.DUMMY")
result = curs.fetchall()
print(result)
$ python3 any.py
[('success',)]
but it causes pyodbc to fail
# pyo.py
import pyodbc
cnxn = pyodbc.connect(
"Driver=ODBC Driver 17 for SQL Server;"
"Server=192.168.0.199;"
"Database=test;"
"UID=scott;PWD=tiger^5HHH;"
)
crsr = cnxn.cursor()
print(crsr.execute("SELECT 'success' AS connection_status").fetchall())
$ python3 pyo.py
Traceback (most recent call last):
File "pyo.py", line 3, in <module>
cnxn = pyodbc.connect(
pyodbc.Error: ('01000', "[01000] [unixODBC][Driver Manager]Can't open lib '/opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.9.so.1.1' : file not found (0) (SQLDriverConnect)")
If we add a third LD_LIBRARY_PATH tweak to sa_config.sh
LD_LIBRARY_PATH="$SQLANY17/lib32:${LD_LIBRARY_PATH:-}"
LD_LIBRARY_PATH="$SQLANY17/lib64:${LD_LIBRARY_PATH:-}"
LD_LIBRARY_PATH="/lib/x86_64-linux-gnu/:${LD_LIBRARY_PATH:-}"
export LD_LIBRARY_PATH
and restart the machine to apply the changes then any.py (above) continues to work, but pyo.py (above, unmodified) works, too:
$ python3 pyo.py
[('success', )]
Looks like you have driver issue, run the following command and it should work
sudo apt-get install tdsodbc
update content of odbcinst.ini
$ sudo nano /etc/odbcinst.ini
[FreeTDS]
Description = TDS Driver for MSSQL
driver = path/to/libtdsodbc.so
setup = path/to/libtdsS.so
[EDIT]
Kindly share output after running this
import pyodbc
print(pyodbc.drivers())
Also kindly check if followed all steps here for target OS:
https://learn.microsoft.com/en-us/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server?view=sql-server-2017
I am currently porting my OGRE 3D-based C++ application from pure Windows to Linux. I am using Ubuntu 18.04 LTS and a manually build OGRE 3D 1.12.1 which was compiled and installed to /usr/local/lib and /usr/local/lib/OGRE which is the default install location.
See:
$ ls -lah /usr/local/lib/
total 9,2M
drwxr-xr-x 6 root root 4,0K Aug 3 11:38 .
drwxr-xr-x 10 root root 4,0K Feb 10 01:12 ..
lrwxrwxrwx 1 root root 22 Aug 3 11:38 libOgreBites.so -> libOgreBites.so.1.12.1
-rw-r--r-- 1 root root 337K Aug 3 11:33 libOgreBites.so.1.12.1
-rw-r--r-- 1 root root 681K Aug 3 11:21 libOgreGLSupport.a
lrwxrwxrwx 1 root root 21 Aug 3 11:38 libOgreHLMS.so -> libOgreHLMS.so.1.12.1
-rw-r--r-- 1 root root 177K Aug 3 11:36 libOgreHLMS.so.1.12.1
lrwxrwxrwx 1 root root 21 Aug 3 11:38 libOgreMain.so -> libOgreMain.so.1.12.1
-rw-r--r-- 1 root root 5,7M Aug 3 11:20 libOgreMain.so.1.12.1
lrwxrwxrwx 1 root root 33 Aug 3 11:38 libOgreMeshLodGenerator.so -> libOgreMeshLodGenerator.so.1.12.1
-rw-r--r-- 1 root root 362K Aug 3 11:34 libOgreMeshLodGenerator.so.1.12.1
lrwxrwxrwx 1 root root 24 Aug 3 11:38 libOgreOverlay.so -> libOgreOverlay.so.1.12.1
-rw-r--r-- 1 root root 576K Aug 3 11:28 libOgreOverlay.so.1.12.1
lrwxrwxrwx 1 root root 25 Aug 3 11:38 libOgreProperty.so -> libOgreProperty.so.1.12.1
-rw-r--r-- 1 root root 79K Aug 3 11:34 libOgreProperty.so.1.12.1
lrwxrwxrwx 1 root root 31 Aug 3 11:38 libOgreRTShaderSystem.so -> libOgreRTShaderSystem.so.1.12.1
-rw-r--r-- 1 root root 1,3M Aug 3 11:31 libOgreRTShaderSystem.so.1.12.1
drwxr-xr-x 3 root root 4,0K Aug 3 11:38 OGRE
drwxr-xr-x 2 root root 4,0K Aug 3 11:38 pkgconfig
drwxrwsr-x 4 root staff 4,0K Jun 23 15:36 python2.7
drwxrwsr-x 3 root staff 4,0K Feb 10 01:12 python3.6
$ ls -lah /usr/local/lib/OGRE
total 1,2M
drwxr-xr-x 3 root root 4,0K Aug 3 11:38 .
drwxr-xr-x 6 root root 4,0K Aug 3 11:38 ..
drwxr-xr-x 2 root root 4,0K Aug 3 11:38 cmake
lrwxrwxrwx 1 root root 25 Aug 3 11:38 Codec_FreeImage.so -> Codec_FreeImage.so.1.12.1
-rw-r--r-- 1 root root 70K Aug 3 11:26 Codec_FreeImage.so.1.12.1
lrwxrwxrwx 1 root root 20 Aug 3 11:38 Codec_STBI.so -> Codec_STBI.so.1.12.1
-rw-r--r-- 1 root root 200K Aug 3 11:26 Codec_STBI.so.1.12.1
lrwxrwxrwx 1 root root 30 Aug 3 11:38 RenderSystem_GL3Plus.so -> RenderSystem_GL3Plus.so.1.12.1
-rw-r--r-- 1 root root 886K Aug 3 11:26 RenderSystem_GL3Plus.so.1.12.1
My CMake build is finding all the required libraries (also the ones in /usr/local/lib/OGRE), but after I have compiled my binaries, my Ubuntu is unable to find the shared libraries located under /usr/local/lib/OGRE:
$ ldd client
linux-vdso.so.1 (0x00007ffd2fde2000)
libhoibase.so => /home/thomas/game/build/hoibase/libhoibase.so (0x00007fbcb3b0c000)
libOgreMain.so.1.12.1 => /usr/local/lib/libOgreMain.so.1.12.1 (0x00007fbcb343e000)
libOgreBites.so.1.12.1 => /usr/local/lib/libOgreBites.so.1.12.1 (0x00007fbcb31fc000)
libOgreOverlay.so.1.12.1 => /usr/local/lib/libOgreOverlay.so.1.12.1 (0x00007fbcb2f8a000)
libOgreRTShaderSystem.so.1.12.1 => /usr/local/lib/libOgreRTShaderSystem.so.1.12.1 (0x00007fbcb2c77000)
RenderSystem_GL3Plus.so.1.12.1 => not found
libSDL2-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 (0x00007fbcb2945000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fbcb25bc000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbcb221e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fbcb2006000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbcb1c15000)
libCGAL.so.13 => /usr/lib/x86_64-linux-gnu/libCGAL.so.13 (0x00007fbcb19f6000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fbcb17ef000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fbcb156e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbcb136a000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbcb114b000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fbcb0e13000)
libXt.so.6 => /usr/lib/x86_64-linux-gnu/libXt.so.6 (0x00007fbcb0baa000)
libXaw.so.7 => /usr/lib/x86_64-linux-gnu/libXaw.so.7 (0x00007fbcb0936000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007fbcb0682000)
libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007fbcb037b000)
libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007fbcb012b000)
libsndio.so.6.1 => /usr/lib/x86_64-linux-gnu/libsndio.so.6.1 (0x00007fbcaff1b000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fbcafd09000)
libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007fbcafaff000)
libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007fbcaf8fc000)
libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007fbcaf6ec000)
libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007fbcaf4e1000)
libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1 (0x00007fbcaf2dd000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007fbcaf0d7000)
libwayland-egl.so.1 => /usr/lib/x86_64-linux-gnu/libwayland-egl.so.1 (0x00007fbcaeed5000)
libwayland-client.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007fbcaecc6000)
libwayland-cursor.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x00007fbcaeabe000)
libxkbcommon.so.0 => /usr/lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007fbcae87f000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fbcae677000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbcb4350000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fbcae44f000)
libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007fbcae247000)
libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007fbcae02c000)
libXmu.so.6 => /usr/lib/x86_64-linux-gnu/libXmu.so.6 (0x00007fbcade13000)
libXpm.so.4 => /usr/lib/x86_64-linux-gnu/libXpm.so.4 (0x00007fbcadc01000)
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007fbcad9cf000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fbcad7b2000)
libpulsecommon-11.1.so => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-11.1.so (0x00007fbcad534000)
libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007fbcad2e7000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007fbcad0d2000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007fbcacec8000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007fbcaccc2000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fbcacaba000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fbcac8b6000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fbcac6b0000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007fbcac42c000)
libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007fbcac222000)
libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007fbcabfa9000)
libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007fbcabda3000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fbcabb7d000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fbcab961000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007fbcab646000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007fbcab42c000)
libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007fbcab1b5000)
libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007fbcaafac000)
libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007fbcaad81000)
libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007fbcaaad8000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fbcaa8bd000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fbcaa6a8000)
What am I doing wrong? What is the trick to make Ubuntu find my RenderSystem_GL3Plus.so.1.12.1?
I am currently porting my OGRE 3D-based C++ application from pure Windows to Linux. I am using Ubuntu 18.04 LTS and a manually build OGRE 3D 1.12.1 which was compiled and installed to /usr/local/lib and /usr/local/lib/OGRE which is the default install location...
As others have stated, the various OGRE libraries cannot be found by the runtime linker. When executing in the build folder, you usually use LD_LIBRARY_PATH to provide the override you need to put a library on path.
Once you perform a make install the binary should be able to find the library because either (1) library is in a well known path; or (2) binary has a RUNPATH with the location of the library. Sometimes you use (3) use LD_LIBRARY_PATH after install. Doing (3) kind of sucks and you should avoid it.
It sounds like the program client lacks a RUNPATH with the location of OGRE libraries. client should have a DT_RUNPATH with /usr/local/lib/OGRE (and not a DT_RPATH). Also see Is there a way to inspect the current rpath on Linux?.
You want a DT_RUNPATH because DT_RUNPATH allows LD_LIBRARY_PATH overrides. DT_RPATH does not allow LD_LIBRARY_PATH overrides.
If the RUNPATH is not there, then add it with LDFLAGS += -Wl,-R,/usr/local/lib/OGRE -Wl,--enable-new-dtags. In CMake, you add linker flags using CMAKE_MODULE_LINKER_FLAGS, CMAKE_SHARED_LINKER_FLAGS and CMAKE_STATIC_LINKER_FLAGS. -Wl,-R,/usr/local/lib/OGRE -Wl,--enable-new-dtags should be added to each one you are using. Also see How to set the LDFLAGS in CMakeLists.txt?.
Note: you probably need to add the options to LDFLAGS for both client and the OGRE libraries since the OGRE libraries probably have dependencies on one another.
Something a little more flexible for you may be to use -Wl,-R,'$$ORIGIN/../lib/OGRE' -Wl,--enable-new-dtags. $ORIGIN is where your program is located, and it tells the runtime linker to look in the relative directory ../lib/OGRE for its libraries. It allows you to move your program (in .../bin/) and libraries (in .../lib/ and .../lib/OGRE) around on the filesystem.
You can thank the glibc folks for the Linux path problems that have plagued Linux for the last 25 years or so. They think it is normal to compile against a version of a library, link against a version of the library, and then load the wrong version of the library at runtime or lose the library at runtime. They should get a Darwin Award for not fixing the idiotic decision.
(Making the wrong descision was OK since we all make mistakes. However, they have never fixed it. Instead they allow these problems to fester for decades.)
I'm compiling with g++ 5.4 on Solaris 11 and running on Solaris 10. Everything seems to work except C++ exceptions which aren't caught.
On Solaris 11:
Here are my compiler and OS versions:
$ uname -a
SunOS tf-vdevmcps11-d001 5.11 11.3 i86pc i386 i86pc
$ g++ --version
g++ (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
A simple test program.
$ cat foo.cxx
#include <iostream>
int main()
{
try {
throw 15; // f();
std::cout << "after f\n";
} catch (int i) {
std::cout << "caught " << i << '\n';
} catch (...) {
std::cout << "caught unknown exception\n";
}
}
It compiles and runs properly here:
$ g++ -fabi-version=2 -Wabi -o foo -g -m32 foo.cxx
$ ./foo
caught 15
These are the dynamic libraries it uses:
$ ldd foo
libstdc++.so.6 => /usr/lib/libstdc++.so.6
libm.so.2 => /lib/libm.so.2
librt.so.1 => /lib/librt.so.1
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
libc.so.1 => /lib/libc.so.1
On Solaris 10 it crashes:
$ ./foo
terminate called after throwing an instance of 'int'
Abort(coredump)
Here's the stack trace of the core file
$ pstack core
core 'core' of 10550: ./foo
fecca427 _lwp_kill (1, 6) + 7
fec720c3 raise (6) + 1f
fec51d2d abort (feffdd68, 9844246, 806ac20, fed40c10, 0, 0) + cd
fef24565 _ZN9__gnu_cxx27__verbose_terminate_handlerEv (0, feff0488, fef211cb, fef65e28, 8066240, 8047c30) + 175
fef211d7 _ZN10__cxxabiv111__terminateEPFvvE (fef243f0, 0, fef21235, fef21267, fef21259, fef65e28) + 17
fef21270 _ZN10__cxxabiv112__unexpectedEPFvvE (8066240, feff0488, fef21235, fef214cf, feffb818, 8047b6c)
fef214fe ???????? (8066260, 8061740, 0, fed32a40, 8047b80, fefcab34)
08051239 main (8051379, feffb818, 8047ba4, 8051053, 1, 8047bb0) + 35
08051053 _start (1, 8047c98, 0, 8047c9e, 8047ca6, 8047cad) + 83
Here are the dynamic libraries:
$ ldd foo
libstdc++.so.6 => /opt/csw/lib/libstdc++.so.6
libm.so.2 => /usr/lib/libm.so.2
librt.so.1 => /usr/lib/librt.so.1
libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1
libc.so.1 => /usr/lib/libc.so.1
libaio.so.1 => /usr/lib/libaio.so.1
libmd.so.1 => /usr/lib/libmd.so.1
The two GNU libraries are from 5.5 versions of the package:
>$ pkginfo -l CSWlibgcc-s1 CSWlibstdc++6
PKGINST: CSWlibgcc-s1
NAME: libgcc_s1 - The GNU Compiler Collection, libgcc_s.so.1
CATEGORY: application
ARCH: i386
VERSION: 5.5.0,REV=2017.10.23
BASEDIR: /
VENDOR: http://gcc.gnu.org packaged for CSW by Dagobert Michelsen
PSTAMP: dam#unstable10x-20171023221120
INSTDATE: Apr 22 2019 08:14
HOTLINE: http://www.opencsw.org/bugtrack/
EMAIL: dam#opencsw.org
STATUS: completely installed
FILES: 4 installed pathnames
1 directories
1883 blocks used (approx)
PKGINST: CSWlibstdc++6
NAME: libstdc++6 - The GNU Compiler Collection, libstdc++.so.6
CATEGORY: application
ARCH: i386
VERSION: 5.5.0,REV=2017.10.23
BASEDIR: /
VENDOR: http://gcc.gnu.org packaged for CSW by Dagobert Michelsen
PSTAMP: dam#unstable10x-20171023221408
INSTDATE: Apr 22 2019 08:06
HOTLINE: http://www.opencsw.org/bugtrack/
EMAIL: dam#opencsw.org
STATUS: completely installed
FILES: 6 installed pathnames
1 directories
2 executables
43873 blocks used (approx)
Using xerces-c-3.1.1 and SolarisStudio12.5Beta-solaris-x86-bin (on Solaris 10).
./configure CXX=CC CC=cc CXXFLAGS="-std=c++11"
gmake
gmake check
results in 37 core dumps and the error messages
terminate called after throwing an instance of 'xercesc_3_1::EndOfEntityException'
a pstack on 1 of the core files show
core 'core_gs580w_XSerializerTest_132_10_1462965423_23542' of 23542: /usr/local/src/xerces-c-3.1.3/tests/.libs/XSerializerTest -v=always pe
fdb5c925 _lwp_kill (1, 6) + 15
fdb03783 raise (6) + 1f
fdae29f5 abort (fdc725cc, 107, 8118140, fdbc3cd8, fedb04d0, fdc725cc) + cd
fdd71eb5 _ZN9__gnu_cxx27__verbose_terminate_handlerEv (1, 0, fdd6eb0b, fddb3468, 8114df0, 8045f00) + 175
fdd6eb17 ???????? (fdd71d40, 0, fdd6eb75, fdd6eba7, fdd6eb99, fddb3468)
fdd6ebb0 ???????? (8114df0, fedb04d0, fdd6eb75, fdd6ee0f, fecfa708, 807b0c0)
fdd6ee3e ???????? (8114e10, fed7d848, feb24d00, feb24aec, 8114db8, fe8f3468)
feb24bff _ZN11xercesc_3_19ReaderMgr9popReaderEv (80df840, 8045b14, 0, feb21a2c) + 11f
feb21a60 _ZN11xercesc_3_19ReaderMgr14skipPastSpacesEv (80df840, 0, 0, febf3911) + 40
febf3d4e _ZN11xercesc_3_110DTDScanner17scanExtSubsetDeclEbb (8045f00, 0, 1, 64) + 44e
feb09db0 _ZN11xercesc_3_112IGXMLScanner15scanDocTypeDeclEv (80df7b8, fec9dec8, fef90c18, feb512f1) + 1610
feb5154f _ZN11xercesc_3_110XMLScanner10scanPrologEv (80df7b8, 80e5c38, feb24700, 0) + 26f
feb0483f _ZN11xercesc_3_112IGXMLScanner12scanDocumentERKNS_11InputSourceE (80df7b8, 80e5c38, 807b0c0, feb4cb51) + 9f
feb4d0ad _ZN11xercesc_3_110XMLScanner12scanDocumentEPKt (80df7b8, 80e5c08, 807b0c0, feb4d96e) + 56d
feb4d9c4 _ZN11xercesc_3_110XMLScanner12scanDocumentEPKc (80df7b8, 8046d5c, feb98f00, 0) + 64
feb9500f _ZN11xercesc_3_117SAX2XMLReaderImpl5parseEPKc (80df500, 8046d5c, 1, 8046ca8) + af
0805e1d2 _Z8parseOnePN11xercesc_3_115BinOutputStreamEPKc (80dd6c0, 8046d5c, 807adf0, fdd2305c) + 112
0805dd70 _Z9parseCasePKc (8046d5c, 0, 3e8, 0) + b0
0805d8a6 main (3, 8046bb0, 8046bc0) + be6
0805a932 _start (3, 8046d18, 8046d52, 8046d5c, 0, 8046d69) + 72
removing CXXFLAGS="-std=c++11" from the configure results in a successful "gmake check"
Any tips on making xerces-c work with sun studio 12.5 and c++11?
Assuming the build process for Xerces 3.1.1 is the same as Xerces 3.1.4, Xerces is explicitly linking in the standard Solaris C++ run-time libraries. That's a problem because specifying -std=c++11 causes Solaris Studio to use the g++ ABI and runtime.
This is ldd output on one of the test executables from compiling Xerces 3.1.4, admittedly on Solaris 11:
bash-4.1$ ldd XSValueTest
libxerces-c-3.1.so => /home/achenle/xerces/xerces-c-3.1.4/src/.libs/libxerces-c-3.1.so
libpthread.so.1 => /lib/libpthread.so.1
libcurl.so.3 => /usr/lib/libcurl.so.3
libidn.so.11 => /usr/lib/libidn.so.11
libsldap.so.1 => /usr/lib/libsldap.so.1
libldap.so.5 => /usr/lib/libldap.so.5
libsocket.so.1 => /lib/libsocket.so.1
libnsl.so.1 => /lib/libnsl.so.1
libgss.so.1 => /usr/lib/libgss.so.1
libssl.so.1.0.0 => /lib/libssl.so.1.0.0
libcrypto.so.1.0.0 => /lib/libcrypto.so.1.0.0
libz.so.1 => /lib/libz.so.1
libstdc++.so.6 => /opt/SUNWspro/lib/compilers/CC-gcc/lib/libstdc++.so.6
libgcc_s.so.1 => /opt/SUNWspro/lib/compilers/CC-gcc/lib/libgcc_s.so.1
librt.so.1 => /lib/librt.so.1
libm.so.2 => /lib/libm.so.2
libc.so.1 => /lib/libc.so.1
libstatomic.so.1 => /opt/SUNWspro/lib/compilers/atomic/libstatomic.so.1
libCstd.so.1 => /usr/lib/libCstd.so.1
libCrun.so.1 => /usr/lib/libCrun.so.1
libscf.so.1 => /lib/libscf.so.1
libsasl.so.1 => /usr/lib/libsasl.so.1
libmd.so.1 => /lib/libmd.so.1
libnspr4.so => /usr/lib/mps/libnspr4.so
libplc4.so => /usr/lib/mps/libplc4.so
libnss3.so => /usr/lib/mps/libnss3.so
libssl3.so => /usr/lib/mps/libssl3.so
libmp.so.2 => /lib/libmp.so.2
libuutil.so.1 => /lib/libuutil.so.1
libgen.so.1 => /lib/libgen.so.1
libnvpair.so.1 => /lib/libnvpair.so.1
libsmbios.so.1 => /usr/lib/libsmbios.so.1
libsoftcrypto.so.1 => /lib/libsoftcrypto.so.1
libelf.so.1 => /lib/libelf.so.1
libdl.so.1 => /lib/libdl.so.1
libnssutil3.so => /usr/lib/mps/libnssutil3.so
libplds4.so => /usr/lib/mps/libplds4.so
libthread.so.1 => /lib/libthread.so.1
libcryptoutil.so.1 => /lib/libcryptoutil.so.1
Note the presence of libstdc++.so.6 (the g++ runtime) and libCstd.so.1 and libCrun.so.1 (the standard Solaris C++ runtime).
This is from the "What's New" documentation on Solaris Studio 12.4:
Using C++11 Features
In Oracle Solaris Studio 12.4, the C++ compiler supports C++11, a new
language and ABI (Application Binary Interface).
In C++ 11 mode, the CC compiler uses the g++ ABI and a version of
the g++ runtime library that is supplied with Oracle Solaris Studio.
For this release, version 4.8.2 of the g++ runtime library is used.
The C++11 implying the use of the g++ ABI and runtime also applies to Solaris Studio 12.5:
A.2.88 –std=v
...
c++11
Selects C++ 11 dialect and g++ binary compatibility. It sets the
__SUNPRO_CC_COMPAT preprocessor macro to 'G'.
But the Xerces build explicitly links in the standard Solaris C++ runtime in addition to the implicitly-linked g++ runtime.
I built a local version of OpenGL under my home directory. I want to link another shared library against it, but for some reason the linker still links it against the one under /usr/lib, as reported by ldd:
$ cc -o lib/libtfont.so -shared -Wl,-soname,/home/wknight/proj/wkl/tfont.lib/lib/libtfont.so tfont.o -L/home/wknight/proj/wkl/img.lib/lib -limg -L/home/wknight/swtools/opengl/lib -lGL -lGLU
$ ldd lib/libtfont.so
linux-gate.so.1 => (0xb7710000)
/home/wknight/proj/wkl/img.lib/lib/libimg.so (0xb76fc000)
libGL.so.1 => /usr/lib/libGL.so.1 (0xb7689000)
libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7618000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb74d1000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb73b4000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb73a5000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb73a0000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb739c000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7397000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb738d000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7367000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb734e000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7349000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7254000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7236000)
/lib/ld-linux.so.2 (0xb7711000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb721d000)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7214000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7211000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb720b000)
$ ls -l /home/wknight/swtools/opengl/lib/libGL*
lrwxrwxrwx 1 wknight wknight 10 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGL.so -> libGL.so.1
lrwxrwxrwx 1 wknight wknight 12 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGL.so.1 -> libGL.so.1.2
-rwxr-xr-x 1 wknight wknight 1836469 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGL.so.1.2
lrwxrwxrwx 1 wknight wknight 11 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLU.so -> libGLU.so.1
lrwxrwxrwx 1 wknight wknight 20 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLU.so.1 -> libGLU.so.1.3.070900
-rwxr-xr-x 1 wknight wknight 1634905 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLU.so.1.3.070900
lrwxrwxrwx 1 wknight wknight 11 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLw.so -> libGLw.so.1
lrwxrwxrwx 1 wknight wknight 15 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLw.so.1 -> libGLw.so.1.0.0
-rwxr-xr-x 1 wknight wknight 37068 Jan 25 16:57 /home/wknight/swtools/opengl/lib/libGLw.so.1.0.0
$
This happens even if I rename my local version of libGL.so and link against the new name. So something is happening behind the scenes that I don't understand. Is the linker looking in ld.so.cache or something? How can I override it?
I found the answer - I just needed to set LD_LIBRARY_PATH to my local version of libGL.so:
$ export LD_LIBRARY_PATH=$HOME/swtools/opengl/lib
$ ldd lib/libtfont.so
linux-gate.so.1 => (0xb778c000)
/home/wknight/proj/wkl/img.lib/lib/libimg.so (0xb7778000)
libGL.so.1 => /home/wknight/swtools/opengl/lib/libGL.so.1 (0xb771f000)
libGLU.so.1 => /home/wknight/swtools/opengl/lib/libGLU.so.1 (0xb76ae000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7559000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb743c000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb742d000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb742a000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7424000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb741f000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb7415000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb73fc000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb73f8000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7302000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb72dc000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb72be000)
/lib/ld-linux.so.2 (0xb778d000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb72a5000)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb729c000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7299000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7293000)
$
This now makes sense to me when I consider that ldd must use the runtime environment in reporting shared library dependencies, not just what is present in the shared library itself. I would have set LD_LIBRARY_PATH before using some executable linked against the shared library, but it didn't occur to me until now that I must also set it for examining the shared library itself.
I built a local version of OpenGL under my home directory
Why? What is your intention doing this? OpenGL is not so much a library, but a specification. What you built is most likely MesaGL. MesaGL does offer HW accelerated OpenGL only with a certain subset of drivers, which also must match your very MesaGL version. Without them, MesaGL will drop into a slow software rasterizer fallback.
As a general rule you always link your program dynamically to the system's libGL.so. If there's no libGL.so present shipping a fallback implementation makes sense only if you can deal with a very slow software rasterizer. Otherwise I'd be better to just inform the user about his systems shortcomings and that either a better GPU must be installed, or the driver installation fixed.
Anyway, if you want to change the path a library is searched in, you should look into the rpath linker flag.