I downloaded postgis-2.1.0SVN, autogen, configured and make, but 'make check' fails and the logs end with
psql:/home/admin/postgis-2.1.0SVN/regress/00-regress-install/share/contrib/postgis/postgis.sql:47:
ERROR: could not load library
"/home/admin/postgis-2.1.0SVN/regress/00-regress-install/lib/postgis-2.1.so":
/home/admin/postgis-2.1.0SVN/regress/00-regress-install/lib/postgis-2.1.so:
undefined symbol: json_tokener_errors
I ran ldd on postgis-2.1.so and got
linux-vdso.so.1 => (0x00007fff055ff000)
libgeos_c.so.1 => /usr/local/lib/libgeos_c.so.1 (0x00007ffcc79fd000)
libproj.so.0 => /usr/lib/libproj.so.0 (0x00007ffcc77ac000)
libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007ffcc7450000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffcc7091000)
libgeos-3.3.6.so => /usr/local/lib/libgeos-3.3.6.so (0x00007ffcc6d08000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ffcc6a07000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ffcc67f1000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffcc64f5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ffcc62f0000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ffcc60d9000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffcc7ecb000
I have json-c built and installed from the github project
the ./configure response ended with:
PostGIS is now configured for x86_64-unknown-linux-gnu
-------------- Compiler Info -------------
C compiler: gcc -g -O2
C++ compiler: g++ -g -O2
SQL preprocessor: /usr/bin/cpp -traditional-cpp -P
-------------- Dependencies --------------
GEOS config: /usr/local/bin/geos-config
GEOS version: 3.3.6
PostgreSQL config: /usr/bin/pg_config
PostgreSQL version: PostgreSQL 9.1.6
PROJ4 version: 48
Libxml2 config: /usr/bin/xml2-config
Libxml2 version: 2.7.8
JSON-C support: yes
PostGIS debug level: 0
Perl: /usr/bin/perl
--------------- Extensions ---------------
PostGIS Raster: disabled
PostGIS Topology: enabled
but I am suspicious of this last line from the configure output:
checking json/json.h usability... yes
checking json/json.h presence... yes
checking for json/json.h... yes
checking for json_object_get in -ljson... no
I got same errors on my ubuntu 12.10 too and resolved to link libjson to libjson-c
cd /usr/lib/
sudo mv libjson.so libjson.so.bak
sudo ln -s libjson-c.so.2.0.0 libjson.so
sudo ldconfig
reconfigure and compile again.
Hope that helps
I had the same error, I was trying to install from the git source json-c. I resolved it installing json-c from the repository, and json-c-devel. Then libconfig command.
Then go to postgis folder
./configure
make
make install
make test
Hope it helps you.
Great day!
Mario T.
Related
We are trying to test postgresql from hammer db, getting below error when I run the librarycheck in in hammerdbcli. I'm using hammerdb version4.1 in RHEL7.9
Checking database library for PostgreSQL
Error: failed to load Pgtcl - couldn't load file "/root/HammerDB-4.1/lib/pgtcl2.1.1/libpgtcl2.1.1.so": /root/HammerDB-4.1/lib/pgtcl2.1.1/libpgtcl2.1.1.so: undefined symbol: lo_truncate64
Ensure that PostgreSQL client libraries are installed and the location in the LD_LIBRARY_PATH environment variable
The HammerDB Documentation section can help here under the section "Verifying the Installation of Database Client Libraries".
On Linux use the ldd command to determine which PostgreSQL libraries are in your path. In this example libpq from a PostgreSQL 14 installation is found and librarycheck runs successfully.
$ ldd libpgtcl2.1.1.so
linux-vdso.so.1 (0x00007ffc621ff000)
libpq.so.5 => /opt/postgresql-14.1/lib/libpq.so.5 (0x00007f34c2e69000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f34c2c5d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f34c2c3a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f34c30c8000)
$ ./hammerdbcli
HammerDB CLI v4.4
Copyright (C) 2003-2022 Steve Shaw
Type "help" for a list of commands
The xml is well-formed, applying configuration
hammerdb>librarycheck
...
Checking database library for PostgreSQL
Success ... loaded library Pgtcl for PostgreSQL
...
It is likely that you are finding a library earlier than version 9.3 where lo_truncate64 was introduced so ensure that the LD_LIBRARY_PATH is set to a PostgreSQL library from a version that is listed in the HammerDB Test Matrix.
Ubuntu 20.04.1 LTS
64-bit
3.36.3 Gnome
Intel core-i7-975H
31.2GiB Memory
1.6 TB Disk Space
Had my flu vaccine
COVID-19: Neg, but I'm boring and don't go anywhere anyway...
I've tried a few fixes, including this one:
Message "Unable to run arm-none-eabi-gdb: cannot find libncurses.so.5"
But no love. I still continue to receive the same error. I'm trying to flash a softdevice using Arduino IDE v1.8.13. GDB version here:
arm-none-eabi-gdb --version
libncurses versions here:
dpkg -l 'ncurses' | grep '^ii'
I do not know what else to try or check. Would someone have any thoughts on what further to check?
#MarkPlotnick - I ran ls -ld $(dpkg -S libncurses.so.5), the result:
ls -ld $(dpkg -S libncurses.so.5)
Then I checked specifically if libncurses5:i386 was installed by trying to install it and it shows the that:
libncurses5:i386 is already the newest version (6.2-0ubuntu2).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
I tried one more time a little differently:
sudo apt-get -y install libc6:i386 libstdc++6:i386 libncurses5:i386 libudev1:i386
Then libudev1:i386 was the only package to install. But if I try to find the file:
~$ locate libncurses5:i386
Then I get five file in this location:
/var/lib/dpkg/info/libncurses5:i386.list
/var/lib/dpkg/info/libncurses5:i386.md5sums
/var/lib/dpkg/info/libncurses5:i386.shlibs
/var/lib/dpkg/info/libncurses5:i386.symbols
/var/lib/dpkg/info/libncurses5:i386.triggers
It's like Schödinger File...
First of all, since you are running a 64 bit version of Ubuntu, you should verify you installed the Linux 64 bit version of the Arduino IDE v1.18.13. If this is not the case, this may explain why installing i386 packages did not fix your problem - If you did not, I would strongly suggest to remove the Linux 32 bit version, and install the Linux 64 bit version instead.
This verification can be done by executing the following command:
file ~/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-gdb
You should see something like:
/home/user/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-gdb: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.8, stripped
The important information here would be ELF 64-bit LSB executable.
The 64 bit version of libncurses.so.5 is of course missing:
ldd ~/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-gdb
linux-vdso.so.1 (0x00007ffccf1ed000)
libncurses.so.5 => not found
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f68fa317000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f68fa125000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f68fa11f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f68fa482000)
It can be installed using the following command:
sudo apt-get install libncurses5
After running sudo ldconfig:
ldd ~/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-gdb
linux-vdso.so.1 (0x00007ffcc41f5000)
libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5 (0x00007f890c00d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f890bebe000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f890bccc000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f890bcc6000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f890bc98000)
/lib64/ld-linux-x86-64.so.2 (0x00007f890c04f000)
Your GDB should now be functional:
~/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-gdb -tui
Note that the same kind of issues may happen with the GNU Arm Embedded Toolchain as well on Ubuntu 20.04.1. It can be fixed by installing the missing packages:
sudo apt-get install libtinfo5 libncursesw5 libpython2.7
I am tryin to compile an opensource project for ARM (Xvisor) but apparently gcc is using the wrong ldfile to link the library libncurse indeed when I compile, I got the following error:
/usr/gnat/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.3.1/ld: cannot find libncurses.so.5
And ldconfig seems to have the library in it
ldconfig -p | grep "curse"
libncursesw.so.5 (libc6,x86-64) => /lib/x86_64-linux-gnu/libncursesw.so.5
libncurses.so.5 (libc6,x86-64) => /lib/x86_64-linux-gnu/libncurses.so.5
libncurses.so.5 (libc6) => /lib/i386-linux-gnu/libncurses.so.5
libncurses.so.5 (libc6) => /lib32/libncurses.so.5
I don't understand why gcc is using the gnat ldfile instead of the system ldfile.
Try to reinstall build-essential package
sudo apt-get remove build-essential && sudo apt-get install build-essential
/usr/gnat is not the main directory for the system library
The solution was that Makefile was using gcc tool instead of the cross compile gcc:arm-eabi-gcc
I download curl7.40 source code, and I have already compile openssl
1.0.2 source code, Now I want to compile curl with openssl 1.0.2.
./configure --prefix=/usr/local/curl-7.40.0 --with-ssl
--with-libssl-prefix=/usr/local/openssl-1.0.2
make && make install
After I install, I ldd curl library but still link with system default library.
ldd libcurl.so
linux-vdso.so.1 => (0x00007fff2db2e000)
libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 (0x00007fafb9b6e000)
librtmp.so.0 => /usr/lib/x86_64-linux-gnu/librtmp.so.0 (0x00007fafb9954000)
libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007fafb96f5000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(0x00007fafb931b000)
...
UPDATE
After some search, I use below command to config.
./configure --prefix=/usr/local/curl-7.40.0 --with-ssl=/usr/local/openssl-1.0.2
But when make install, it will show below error information.
../lib/.libs/libcurl.so: undefined reference to `SSLv2_client_method'
collect2: error: ld returned 1 exit status
The problem is likely with how you have build the OpenSSL library.
It is likely you have built openssl with SSLv2 disabled as some distributions have SSLv2 disable by default. Look at the ./config for your system when you are compiling OpenSSL, and find the option that controls the OPENSSL_NO_SSL2 preprocessor flag.
In order to use proper version of openssl while making from source, you can make openssl like this:
cd <path-to-openssl-dir>
./config enable-ssl2 enable-ssl3 --prefix=<path-to-openssl-install-dir>
Then, you can link your curl version properly to openssl by:
./configure --with-ssl=<path-to-openssl-install-dir>
SSLv2_client_method() is used in lib/vtls/openssl.c, line 1575 with a check for availability of this function via autoconf. It seems to me that autoconf's AC_CHECK_FUNCS incorrectly finds your system installation of openssl which has SSLv2 enabled before #includeing your own installation of openssl-1.0.2 which doesn't have SSLv2_client_method() and thus assumes the function to be available.
Try passing CFLAGS=-I/usr/local/openssl-1.0.2/include or even "CFLAGS=-I/usr/local/openssl-1.0.2/include -DOPENSSL_NO_SSL2" as arguments to ./configure to force openssl.c to make do without the SSLv2_client_method() incorrectly assumed to be available.
I'm writing a (hopefully) small project that would end up being distributed in binary form for Mac OS. I'm looking for a way to deploy the thing with a database that doesn't have a completely screwed up driver installation process. The mysql driver requires the mysqldb binary driver, which is a bear to compile, as is the postgresql binary driver.
I was looking into pure-python mysql drivers, and I found pymysql. Is there any way to deploy this as the driver? Can anyone suggest a way to easily distribute these things?
sqlite will do the job just fine if it isn't too database intense. Default support in Django and the best thing: No extra dependencies needed.
If you install python using homebrew, you'll find a lot of the problems with binary drivers just go away.
Homebrew: https://github.com/mxcl/homebrew
Once you've installed homebrew, install python 2.7 using:
brew install python --framework
You'll then want to change OSX's symbolic link for the current version of Python to point to the one from homebrew. My symlink is like this:
/System/Library/Frameworks/Python.framework/Versions/Current -> /usr/local/Cellar/python/2.7.1/Frameworks/Python.framework/Versions/Current
I can't remember if I had to do anything else, basically the goal is such that when you run python from the terminal it's pointing to the one in /usr/local/Cellar.
Then you'll want to easy_install pip, again making sure it's using the right version of python.
Now you should be able to install python packages easily, even ones that use binaries. Here's the results from a fresh virtualenv:
(test)andrew-ingrams-imac:test andy$ pip install MySQL-python
Downloading/unpacking MySQL-python
Downloading MySQL-python-1.2.3.tar.gz (70Kb): 70Kb downloaded
Running setup.py egg_info for package MySQL-python
warning: no files found matching 'MANIFEST'
warning: no files found matching 'ChangeLog'
warning: no files found matching 'GPL'
Installing collected packages: MySQL-python
Running setup.py install for MySQL-python
building '_mysql' extension
/usr/bin/cc -fno-strict-aliasing -fno-common -dynamic -O3 -march=core2 -msse4.1 -w -pipe -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Dversion_info=(1,2,3,'final',0) -D__version__=1.2.3 -I/usr/local/mysql/include -I/usr/local/Cellar/python/2.7.1/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c _mysql.c -o build/temp.macosx-10.4-x86_64-2.7/_mysql.o -Os -g -fno-common -fno-strict-aliasing -arch x86_64
/usr/bin/cc -L/usr/local/Cellar/readline/6.2.1/lib -bundle -undefined dynamic_lookup -L/usr/local/Cellar/readline/6.2.1/lib build/temp.macosx-10.4-x86_64-2.7/_mysql.o -L/usr/local/mysql/lib -lmysqlclient_r -lpthread -o build/lib.macosx-10.4-x86_64-2.7/_mysql.so -arch x86_64
warning: no files found matching 'MANIFEST'
warning: no files found matching 'ChangeLog'
warning: no files found matching 'GPL'
Successfully installed MySQL-python
Cleaning up...
(test)andrew-ingrams-imac:test andy$ python
Python 2.7.1 (r271:86832, May 19 2011, 20:48:36)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.9)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import MySQLdb
>>>