ec2 server postgres error "version `GLIBC_2.14' not found" - postgresql

While trying to \i create_db.sql psql throws the error:
psql:create_db.sql:123: ERROR: could not load library
"/usr/lib64/pgsql/plpgsql.so": /lib64/libc.so.6: version
`GLIBC_2.14' not found (required by /usr/lib64/pgsql/plpgsql.so)
Line 123 of create_db.sql is the last line of the file, at the end of a a function definition:
$$ language plpgsql;
Versions of stuff:
$ psql --version
psql (PostgreSQL) 9.2.7
$ /lib64/libc.so.6 --version
GNU C Library (GNU libc) stable release version 2.17, by Roland McGrath et al.
Copyright (C) 2012 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.
Compiled by GNU CC version 4.8.2 20131212 (Red Hat 4.8.2-7).
Compiled on a Linux 3.2.5 system on 2014-06-09.
Available extensions:
The C stubs add-on version 2.1.2.
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
RT using linux kernel aio
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
Do I need to have glibc exactly version 2.14 or should 2.17 work too?

Your PostgreSQL install, or your OS install in general, is at least somewhat broken.
At a guess, you must've force-installed some RPM you found somewhere random instead of configuring repositories and using yum install to install PostgreSQL.
You don't need an exactly matching glibc version. It just has to declare that it's compatible with the required version by exposing a suitable GLIBC_ symbol .
e.g. on my Fedora 20, with glibc 2.18, I'd have no problems running programs compiled for glibc 2.14 because:
$ /lib64/libc.so.6 --version
GNU C Library (GNU libc) stable release version 2.18, by Roland McGrath et al.
$ nm /lib64/libc.so.6| grep GLIBC_2.14
0000000000000000 A GLIBC_2.14
my glibc declares that it's compatible with 2.14.

Related

MYSQLConnection call to #database.setter incorrectly routes to the _mysql_connector c-extenstion

Running on Mac Big Sur 11.6.2
Using Python 3.8
Mysql 8.0.29 Homebrew
MYSQLConnection call to #database.setter, i.e. db_conn.database = my_db_name, incorrectly routes to the _mysql_connector c-extenstion, but I don not have the c extension installed, so the call raises an exception. After pip install mysql-connector-python the file WHEEL contains Root-Is-Purelibe: true and top_level.txt is missing _mysql_connector. I expect calling db_conn.database = my_db_name to execute the MySQLConnection class’ database(value) method in connection.py, not route the call to a non-existent _mysql_connector I have been unable to get pip to install the mysql-connector-python with c extension despite trying various suggestions in stackoverflow.
Sorry, I don't a reputation yet to reply in comment to Nuno-Mariz, so posting the following.
I work on the same team as #needpythonhelp, and we have nearly identical macbook pro laptops, they are not M1. We use the the same Pipfile to create a project-specific .venv. His does not get the _mysql_connector, and my .venv does (I don't remember how I got my python 3.8 version a year ago). See difference below. Could his lack of _mysql_connector have anything to do with missing CPPFLAGS or LDFLAGS when his Python version was installed (presumably built from source e.g. pyenv or annaconda)?
My system
clang --version
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
$ python3
Python 3.8.5 (v3.8.5:580fbb018f, Jul 20 2020, 12:11:27)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
cat .venv/lib/python3.8/site-packages/mysql_connector_python-8.0.23.dist-info/WHEEL
Wheel-Version: 1.0
Generator: bdist_wheel (0.35.1)
Root-Is-Purelib: false
Tag: cp38-cp38-macosx_10_14_x86_64
cat .venv/lib/python3.8/site-packages/mysql_connector_python-8.0.23.dist-info/top_level.txt
_mysql_connector
_mysqlxpb
mysql
mysqlx
ls -la .venv/lib/python3.8/site-packages/_mysql*
-rwxr-xr-x 1 brian staff 7876288 May 25 18:53 .venv/lib/python3.8/site-packages/_mysql_connector.cpython-38-darwin.so
-rwxr-xr-x 1 brian staff 3190548 May 25 18:53 .venv/lib/python3.8/site-packages/_mysqlxpb.cpython-38-darwin.so
needpythonhelp's system
$ clang --version
Apple clang version 11.0.3 (clang-1103.0.32.62)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
$ python3
Python 3.8.3 (default, Jul 2 2020, 11:26:31)
[Clang 10.0.0 ] :: Anaconda, Inc. on darwin
his WHEEL file has
Root-Is-Purelib: true
Tag: py2-none-any
Tag: py3-none-any
top_level.txt
mysql
mysqlx
he does not have either of these in .venv/lib/python3.8/site-packages
_mysqlxpb.cpython-38-darwin.so
_mysql_connector.cpython-38-darwin.so
Edit/Update to the above info
I did a test later today where I used pyenv to install the latest CPython 3.8.13, and built a new .venv from the same Pipfile as noted above. This .venv is like #needpythonhelp's .venv. So now I have one .venv (CPython 3.8.13) that does NOT have _mysql_connector and Root-Is-Purelib: false, etc., and another .venv (from my original CPython 3.8.5 installed a year ago) that does have it.
This is what my Pyenv install today looked like:
❯ pyenv install 3.8:latest
python-build: use openssl#1.1 from homebrew
python-build: use readline from homebrew
Downloading Python-3.8.13.tar.xz...
-> https://www.python.org/ftp/python/3.8.13/Python-3.8.13.tar.xz
Installing Python-3.8.13...
python-build: use tcl-tk from homebrew
python-build: use readline from homebrew
python-build: use zlib from xcode sdk
Installed Python-3.8.13 to /Users/brian/.pyenv/versions/3.8.13
Any ideas on how to consistently get the c-ext when I use pyenv to install new Python versions?

Cygwin: C standard library does not support <uchar.h>?

Scenario:
$ echo "#include <uchar.h>" | gcc -xc - -std=c11 -pedantic -Wall -Wextra
<stdin>:1:10: fatal error: uchar.h: No such file or directory
compilation terminated.
$ gcc --version
gcc (GCC) 11.2.0
$ uname -a
CYGWIN_NT-10.0 xxx 3.3.4(0.341/5/3) 2022-01-31 19:35 x86_64 Cygwin
Does is mean that C standard library does not support <uchar.h>?
UPDATE. From Brian Inglis:
Nobody else has noticed or mentioned those in the last decade, so there
may not be (any updates), as volunteers have limited time and their own interests and
priorities.
Given that newlib is a freestanding implementation, and gcc does not
provide that header, those definitions or declarations, these are
considered platform implementation issues, which someone supporting that
platform has to decide if they will provide and support.
ICU provides uchar.h which Cygwin libicu-devel maintainer installs under
/usr/include/unicode/ with Unicode licence under
/usr/share/icu//LICENSE.
You could pull those two files from the ICU distro for use in your work.
It also is/will be available on glibc platforms which support it.
Remember that GNU products are GPL licensed with possibly undesirable
requirements for most commercial products.
Similarly, TIME_UTC may not be available on some newlib
platforms/targets, so it will be up to platform and/or target
maintainers to decide if they can support it, and provide implementations.
I don't know what your host platform is, your newlib target, or what
POSIX time.h CLOCK_/clock_... support is available, but you may wish to
use that instead, until someone can provide the ISO C equivalent in
newlib under a BSD licence.
You may also wish to look at what is available in *BSD sources.
Install the libicu-devel package
the header will be under:
/usr/include/unicode/uchar.h

why didn't my g++ and gcc version get upgraded?

I am on a Mac. I updated my OSx to Yosemite. I updated my xcode to version 6. I downloaded the command line tools.
And still, whenever I type in g++ --version, I get:
# g++ --version
couldn't understand kern.osversion `14.1.0'
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Copyright (C) 2007 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.
meaning, I am still using the old version of g++ and gcc.
Why wasn't it upgraded? I am interested in using c++0x in Eclipse, and for that I need a newer g++/gcc compiler.
EDIT: following the comment below, I have two questions:
Why
$ clang --version
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
do I still seem to have an old version of clang?
Why didn't the installation of xcode and the command-line tools create the proper links to clang?
It looks like you maybe have an old version of xcode also installed.
From the command line you can switch to the proper one with
xcode-select --switch <path>
You should see something like this
$ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
$ clang --version
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
I had a similar problem installing ios-deploy after upgrading to yosemite. i was getting the same
couldn't understand kern.osversion `14.1.0'
for gcc. I ultimately solved it by:
cd /opt/local/bin/
sudo rm gcc
sudo ln -s /Applications/Xcode.app/Contents/Developer/usr/bin/gcc gcc
This correctly pointed gcc to the the version provided by Xcode 6.1.

pdftotext on Centos 6 64bit?

I have a HostGator VPS server, and want to be able to run pdftotext, part of xpdf (http://www.foolabs.com/xpdf/download.html).
After testing this out on my Mac, it worked fine, so I went to installing it on my VPS server.
I followed the installation instructions and it all isntalled flawlessly:
Copy the executables (xpdf, pdftotext, etc.) to to /usr/local/bin.
Copy the man pages (*.1 and *.5) to /usr/local/man/man1 and /usr/local/man/man5.
Copy the sample-xpdfrc file to /usr/local/etc/xpdfrc
Then I tested it out:
root#*** [~]# pdftotext
pdftotext: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by pdftotext)
So as you can see, it couldn't find /lib64/libc.so.6. /lib64/libc.so.6 is there, however, as shown by this:
root#*** [~]# /lib64/libc.so.6
GNU C Library stable release version 2.5, by Roland McGrath et al.
Copyright (C) 2006 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.
Compiled by GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-52).
Compiled on a Linux 2.6.9 system on 2012-03-19.
Available extensions:
The C stubs add-on version 2.1.2.
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
GNU libio by Per Bothner
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
RT using linux kernel aio
Thread-local storage support included.
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
I then contacted HostGator, where they told me that it will not work on my server, as it can't find /lib64/libc.so.6, and is therefor not available on Centos 6 64bit.
If this is indeed true, are there any alternatives to pdftotext that do a simple and fast conversion that would work on this server? Is it possible that the pdftotext can be complied for a different version, or that I installed it incorrectly with permissions?
Neither of these commands will work:
yum install xpdf
yum install poppler-utils
xpdf will install poppler-utils anyway and this will result in this pdftotext
pdftotext version 0.26.5
Copyright 2005-2014 The Poppler Developers - http://poppler.freedesktop.org
Copyright 1996-2011 Glyph & Cog, LLC
This is not the version you want. You want this one:
pdftotext version 4.03 [www.xpdfreader.com]
Copyright 1996-2021 Glyph & Cog, LLC
This will require going to www.xpdfreader.com and then clicking on "Download". Use the latest versions from this page to set up the newer pdftotext command.
I actually compiled the sources myself:
cd /tmp
wget https://dl.xpdfreader.com/xpdf-4.03.tar.gz
tar -xf xpdf-4.03.tar.gz
cd xpdf-4.03
mkdir build
cmake -DCMAKE_BUILD_TYPE=Release
If successful you should see:
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/xpdf-4.03
Then just type:
make
It should end with:
[100%] Built target pdftotext
Then type
make install
Now when you type pdftotext you should see:
pdftotext version 4.03 [www.xpdfreader.com]
Copyright 1996-2021 Glyph & Cog, LLC
Note: I wrote all my code for pdftotext version 4.03. Took me a while to realise 4.03 and 0.26 produce vastly different results.

In compiling shogun machine learning toolbox for matlab interface, what are the necessary packages I need to install for cygwin?

I don't want to install all as it consumes much space..
the following is what i'm sure is needed:
gcc, make python..
what else?
On the site, in their documentation on installing...
http://www.shogun-toolbox.org/doc/en/current/installation.html
Requirements
SHOGUN requires the standard linux utils like bash, grep, test, sed,
cut, ldd, uname gcc g++ and cat python (debian package: python2.4 or
python2.5) for the ./configure to work.
Optionally you will need atlas and lapack (debian packages
lapack3-dev, atlas3-headers atlas3-base-dev or atlas3-altivec-dev
atlas3-sse2-dev) installed. Note that atlas/lapack is only supported
under linux (high performance computing should be done under linux
only anyway). In case atlas/lapack is unavailable, don't worry most of
shogun will work without, though slightly slower versions are used.
To
enable Multiple Kernel Learning with CPLEX(tm) just make sure cplex
can be found in the PATH. If it is not found shogun will resort to
GLPK (if version at least 4.29 is found) for 1-norm MKL, p-norm MKL
with p>1 will work nonetheless.
To compile the C# interface you need to have the C# developer files
(debian package mono-utils) installed.
To compile the Lua interface
you need to have the Lua developer files (debian package lua)
installed.
To compile the Java interface you need to have the Java
developer files (debian package openjdk-6-jdk) installed.
To compile
the R interface you need to have the R developer files (debian package
r-base-dev) installed.
To compile the Ruby interface you need to have
the Ruby developer files (debian package ruby) installed.
To compile
the octave interface you need to have the octave developer files
(debian package octave3.0-headers) installed.
To compile the python
interface you need to have numpy version 1.x installed (debian package
python-numpy) installed.