compiling the fresh grass trunk I get several compilation issues on tgrass and some wxpython modules (animation, vdigit, iclass) and the problem resides into:
ImportError: /usr/local/lib/libgdal.so.1: undefined symbol: sqlite3_column_table_name
I just updated also the gdal trunk. Any pointers on whether this is a problem in gdal, grass or sqlite3 (I use the EPEL sqlite-devel pakage)
Thank you in advance
–
Best regards,
Dr. Margherita DI LEO
Scientific / technical project officer
European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261
Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission.
On Thu, Dec 12, 2013 at 2:18 PM, Margherita Di Leo
<dileomargherita@gmail.com> wrote:
Hi All,
compiling the fresh grass trunk I get several compilation issues on tgrass
and some wxpython modules (animation, vdigit, iclass) and the problem
resides into:
ImportError: /usr/local/lib/libgdal.so.1: undefined symbol:
sqlite3_column_table_name
I just updated also the gdal trunk. Any pointers on whether this is a
problem in gdal, grass or sqlite3 (I use the EPEL sqlite-devel pakage)
Be sure that all used packages are built against the same library version.
The "ldd" command is useful to figure out the "who calls whom".
compiling the fresh grass trunk I get several compilation issues on tgrass
and some wxpython modules (animation, vdigit, iclass) and the problem
resides into:
ImportError: /usr/local/lib/libgdal.so.1: undefined symbol:
sqlite3_column_table_name
I just updated also the gdal trunk. Any pointers on whether this is a
problem in gdal, grass or sqlite3 (I use the EPEL sqlite-devel pakage)
Be sure that all used packages are built against the same library version.
The “ldd” command is useful to figure out the “who calls whom”.
cool command, thanks. But I don’t know if in this case is useful: http://pastebin.com/h7ig0iT0 doesn’t tell me a lot.
What I did in order to try to solve the issue:
I removed the fresh gdal trunk installation and opted for the package coming from ELGIS (I had also tried with the version 1.9.2 compiled by myself, because i used to have it compiled without problem before upgrading to gdal trunk and before updating the grass trunk). As a result, I receive the same compilation error: http://pastebin.com/S8EUEZjK
Of course at any tentative I ran make clean and make distclean.
Any pointers?
Thanks
madi
–
Best regards,
Dr. Margherita DI LEO
Scientific / technical project officer
European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261
Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission.
compiling the fresh grass trunk I get several compilation issues on tgrass and some wxpython modules (animation, vdigit, iclass) and the problem resides into:
ImportError: /usr/local/lib/libgdal.so.1: undefined symbol: sqlite3_column_table_name
The problem resides in an old version of sqlite that I was using, coming from package:
=====
$ rpm -qi sqlite3-dbf.x86_64
Name : sqlite3-dbf Relocations: (not relocatable)
Version : 2011.01.24
Vendor: Fedora Project
Release : 1.el6 Build Date: Sat 11 Feb 2012 10:50:28 AM CET
Install Date: Mon 16 Dec 2013 10:58:33 AM CET Build Host: x86-15.phx2.fedoraproject.org
Group : Applications/Text Source RPM: sqlite3-dbf-2011.01.24-1.el6.src.rpm
Size : 49144 License: GPLv3+
Signature : RSA/8, Sat 11 Feb 2012 05:49:50 PM CET, Key ID 3b49df2a0608b895
Packager : Fedora Project
URL : http://sqlite.mobigroup.ru/wiki?name=sqlite3-dbf
Summary : Converter of XBase / FoxPro tables to SQLite
Description :
SQLiteDBF converts XBase databases, particularly FoxPro tables with memo files,
into a SQL dump. It has no dependencies other than standard Unix libraries.
SQLiteDBF is designed to be incredibly fast and as efficient as possible.
Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission.