When I run, node -v from terminal on arm machine. I get below error....
node: '/usr/lib/libstdc++.so.6' library contains unsupported TLS
node: can't load library 'libstdc++.so.6'
I built the node with buildroot.
I copies all reqd libs in usr/lib also ....
And what error is showing on that lib, i copied that, libstdc++.so.6.0.19, as well.
and created symlink for libstdc++.so and libstdc++.so.6
and my output for ldd and node -v on AT91SAM9620 board =>
ldd /bin/node
libz.so.1 => /lib/libz.so.1 (0x4000e000)
libssl.so.1.0.0 => /lib/libssl.so.1.0.0 (0x40028000)
libcrypto.so.1.0.0 => /lib/libcrypto.so.1.0.0 (0x40082000)
libdl.so.0 => /lib/libdl.so.0 (0x4009f000)
librt.so.0 => /lib/librt.so.0 (0x400aa000)/bin/node:/usrlibstdc++.so.6
library contains unsupported TLS
libstdc++.so.6 => not found
libm.so.0 => /lib/libm.so.0 (0x400b3000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x400cb000)
libpthread.so.0 => /lib/libpthread.so.0 (0x400dd000)
libc.so.0 => /lib/libc.so.0 (0x400f7000)
ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x40000000)
node -v
node: '/usr/lib/libstdc++.so.6' library contains unsupported TLS
node: can't load library 'libstdc++.so.6'
Does it need anything else or any dependacies .....???
and all libs what it needs are present on board.
ls -ahl /usr/lib/ |grep libstdc++.so.6
lrwxrwxrwx 1 root root 19 Jan 22 10:15 libstdc++.so ->
libstdc++.so.6.0.19
lrwxrwxrwx 1 root root 19 Jan 21 15:08 libstdc++.so.6 ->
libstdc++.so.6.0.19
-rwx------ 1 root root 3.9M Jan 21 14:41 libstdc++.so.6.0.19
-rwxrwxrwx 1 root root 2.4K Jan 21 14:56 libstdc++.so.6.0.19-gdb.py
and ldd for that lib
ldd libstdc++.so.6.0.19
checking sub-depends for '/lib/libm.so.0'
checking sub-depends for '/lib/libc.so.0'
Segmentation fault
what is the segmentation fault is comming for ....???
what is this " library contains unsupported TLS" ...???
How can I solve this...???
How can I get out of this .....
It looks like you built libstdc++.so with an incompatible toolchain.
You should not need to copy any extra libraries. Buildroot will take care of all dependencies and install everything that is needed to your target rootfs. Just make sure that C++ support is enabled in the configuration and that you select the nodejs package.
Related
Note: There are several similar questions, which I have seen and read. None of them are the precise problem I'm having, and none of their answers work for me.
I have installed several Python versions (Python 2.7, 3.8, 3.9, and 3.10) on my macOS Ventura system using Pyenv. The installed directories include a python-config file in /bin and an /include directory with many header files, so I do not need to install python-devel or similar:
$ ls -al /Users/williamsn/.pyenv/versions/3.10.9/bin/*-config
lrwxr-xr-x 1 williamsn staff 17 Dec 19 17:24
/Users/williamsn/.pyenv/versions/3.10.9/bin/python-config -> python3.10-config
lrwxr-xr-x 1 williamsn staff 17 Dec 19 17:24
/Users/williamsn/.pyenv/versions/3.10.9/bin/python3-config -> python3.10-config
-rwxr-xr-x 1 williamsn staff 2073 Dec 19 17:24
/Users/williamsn/.pyenv/versions/3.10.9/bin/python3.10-config
$ ls -al /Users/williamsn/.pyenv/versions/3.10.9/include/python3.10/
total 1192
drwxr-xr-x 86 williamsn staff 2752 Dec 19 17:24 .
drwxr-xr-x 3 williamsn staff 96 Dec 19 17:24 ..
-rw-r--r-- 1 williamsn staff 3224 Dec 19 17:24 Python.h
...
-rw-r--r-- 1 williamsn staff 3026 Dec 19 17:24 import.h
...
-rw-r--r-- 1 williamsn staff 48878 Dec 19 17:24 pyconfig.h
...
-rw-r--r-- 1 williamsn staff 2863 Dec 19 17:24 weakrefobject.h
As a best practice, I work exclusively in virtualenvs to keep the base Python installation clean and pristine. I create my virtualenvs using the venv module built in to Python 3:
$ python3.10 -m venv my_venv
After doing so, there are two problems:
The my_venv/include directory is empty (does not contain the python3.10 directory or any of the header files from the parent Python and does not symlink to the parent Python)
There is no python-config / python3-config / python3.10-config in my_venv/bin.
So, for things requiring the Python headers:
If it tries to find the headers using python-config (which many projects do), it will fail.
If it tries to find the headers using the Python prefix and adding /include to it (which many projects do, notably Boost), it will fail.
If it tries to find the headers by importing sysconfig and calling sysconfig.get_paths(), it will succeed, albeit with paths outside the virtualenv.
Now, on a case-by-case basis, I can work around this, and already have. I can manually copy over python_config and then either export CPATH to add /Users/williamsn/.pyenv/versions/3.10.9/include/python3.10 or modify the virtualenv to symlink to /Users/williamsn/.pyenv/versions/3.10.9/include. These work, but they don't seem right to me. I can't make a global workaround anywhere (such as exporting CPATH in my Bash profile), because I'm working with multiple Python versions, and I'd end up with the wrong headers half the time. It seems to me like a virtualenv that has an empty include directory and is missing python-config when its parent has a full include directory and contains python-config is a broken virtualenv.
Is there an option I'm missing to include these pieces? Is this a bug I need to file against Python/venv?
Running RHEL 7.7 on the head node of a compute cluster. When I open VS Code 1.57.1 it hangs on the intro screen. Running with $ code --verbose, it shows the error: /usr/lib64/libstdc++.so.6: version GLIBCXX_3.4.20 not found. I have to kill -9 the hanging code process. Google tells me that the new version of VS Code uses Electron that requires the updated GLIBCXX version.
The installed version in /usr/lib64/libstdc++ is definitely out of date, and I can't update it. But I do have a newer version of GCC that is loaded by the $ module load gcc8/8.4.0 command that loads GCC from /cm/shared/apps/gcc8/8.4.0/. The library /cm/shared/apps/gcc8/8.4.0/lib64/libstdc++.so.6 has the requested version of GLIBCXX.
I have tried loading gcc8 before running code, but that doesn't change the error.
Is there a way to make VS Code use the alternative location for libstdc++.so.6? Is there an alternative to updating the system-wide libstdc++.so.6 library?
This is the full error message from --verbose:
Error: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/spdlog/build/Release/spdlog.node)
at process.func [as dlopen] (electron/js2c/asar_bundle.js:5:1846)
This shows the out-of-date default version of libstdc++:
$ strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
...
GLIBCXX_3.4.18
GLIBCXX_3.4.19 <----Nope, this version is too old!
GLIBCXX_DEBUG_MESSAGE_LENGTH
This shows the other libstdc++ library has the required version:
$ strings /cm/shared/apps/gcc8/8.4.0/lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
...
GLIBCXX_3.4.19
GLIBCXX_3.4.20 <--- Here it is!
GLIBCXX_3.4.21
...
GLIBCXX_3.4.25
GLIBCXX_DEBUG_MESSAGE_LENGTH
Per scroveez's suggestion, the /usr/lib64/libstdc++.so.6 was indeed a symlink to the older version. To fix it I copied the 'new' version 25 library into /usr/lib64/ and changed the symlink to point to the newer version.
$ ll /usr/lib/libstdc++.so.*
lrwxrwxrwx 1 root root 18 Apr 30 2019 /usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.7
-rwxr-xr-x 1 root root 739520 Nov 13 2014 /usr/lib/libstdc++.so.5.0.7
lrwxrwxrwx 1 root root 19 Jul 6 08:56 /usr/lib/libstdc++.so.6 -> libstdc++.so.6.0.25
-rwxr-xr-x 1 root root 934644 Mar 25 2020 /usr/lib/libstdc++.so.6.0.19
-rwxr-xr-x 1 root root 1570176 Jul 6 08:55 /usr/lib/libstdc++.so.6.0.25
$
after days of regular fight with postgis I stuck on this:
postgres=# CREATE EXTENSION postgis; ERROR: could not load library
"/usr/pgpro-9.6/lib/rtpostgis-2.4.so": libgdal.so.20: cannot open
shared object file: No such file or directory
and have no idea how to pass it, because library path is correct...
[combat#urpordfinal ~]$ ls -alt /usr/pgpro-9.6/lib/ total 13080
-rwxr-xr-x 1 root root 1440056 Apr 23 11:52 postgis_topology-2.4.so
drwxr-xr-x 5 root root 8192 Apr 23 11:52 .
-rwxr-xr-x 1 root root 1878728 Apr 23 11:52 rtpostgis-2.4.so
I'm running pgsql 9.6.8 and psotgis build from source
You have to make sure that libgdal.so.20 is on the shared library path.
Find out where the library is and add that directory to the shared library path.
On Linux, you would normally do that by adding the directory to /etc/ld.so.conf (or, better, to a PostGIS configuration file in /etc/ld.so.conf.d) and running ldconfig.
I am puzzled by the following sequence of commands.
sh-4.2$ pwd
/home/willard
sh-4.2$ ls -l f
-rwxr-xr-x 1 willard users 59116 Jan 23 14:54 f
sh-4.2$ file f
f: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, BuildID[sha1]=0xea0e08ff2b5a062698d45b78177acdd6bf140d1f, stripped
sh-4.2$ ./f
sh: ./f: No such file or directory
sh-4.2$ strace ./f
execve("./f", ["./f"], [/* 32 vars */]) = -1 ENOENT (No such file or directory)
write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
exit_group(1) = ?
+++ exited with 1 +++
sh-4.2$ ls -l f
-rwxr-xr-x 1 willard users 59116 Jan 23 14:54 f
sh-4.2$ uname -a
Linux xdat10 3.6.2-1-ARCH #1 SMP PREEMPT Fri Oct 12 23:58:58 CEST 2012 x86_64 GNU/Linux
How is this possible?
I found someone having the same problem (with relative explanation)
Running 32bit binary on a 64bit system
Quoting the most important sentences:
This situation often arises when you try to run a binary for the right
system (or family of systems) and superarchitecture but the wrong
subarchitecture. Here you have ELF binaries on a system that expects
ELF binaries, so the kernel loads them just fine. They are i386
binaries running on an x86_64 processor, so the instructions make
sense and get the program to the point where it can look for its
loader. But the program is a 32-bit program (as the file output
indicates), looking for the 32-bit loader /lib/ld-linux.so.2, and
you've presumably only installed the 64-bit loader
/lib64/ld-linux-x86-64.so.2 in the chroot.
You need to install the 32-bit runtime system in the chroot: the
loader, and all the libraries the programs need. On Debian amd64, the
32-bit loader is in the libc6-i386 package. You can install a bigger
set of 32-bit libraries by installing ia32-libs.
I bet there's a better way to verify this but i'd try to exec
ldd ./f
and search in the output which loader is needed to exec'it
man 2 execve:
ENOENT The file filename or a script or ELF interpreter does not
exist, or a shared library needed for file or interpreter can‐
not be found.
You could run ldd against this binary to look for libraries that could not be mapped and install them from multilib.
I want to connect with the oracle database from a perl script in solaris servier. Able to see DBI is installed but not DBD::Oracle in the current perl version 5.8.4. I dont have root acess and working on my home user id. Download the DBD-Oracle-1.50 and unzipped in the local directory where my perl script exists. I want to copy the DBD Oracle library files into a custom directory and run the script since i dont have root acess. When i read the install script in the DBD-Oracle-1.50 it's says for manuall install i need to run the below scripts . Since i dont have root access i want to copy the library modules into the local directory. Not sure how to tell these scripts to install it in the local directory where my perl script exists.
Does installing DBI and DBD in a custom directory under my user id makes it work properly. Do those modules require root access to work properly? To use DBD::Oracle does oracle needs to be installed in server. My Understanding Oracle driver DBD::Oracle should take care of it.
perl Makefile.PL
make && make test
make install
> ls -tlr /usr/perl5/vendor_perl/5.8.4/sun4-solaris-64int total 956
> -rwxr-xr-x 1 root bin 15161 Mar 26 2005 Roadmap.pod
> -rwxr-xr-x 1 root bin 1048 Sep 5 2006 TASKS.pod
> -rwxr-xr-x 1 root bin 289343 Jun 26 2007 DBI.pm
> -rwxr-xr-x 1 root bin 4608 Jun 12 2008 goferperf.pl
> -rwxr-xr-x 1 root bin 1356 Jun 12 2008 dbixs_rev.pl
> -rwxr-xr-x 1 root bin 58386 Apr 3 2010 SNMP.pm drwxr-xr-x 3 root bin 7 Oct 13 2010 NetSNMP
> drwxr-xr-x 2 root bin 3 Oct 13 2010 Win32 drwxr-xr-x
> 8 root bin 19 Oct 13 2010 DBI drwxr-xr-x 2 root
> bin 4 Oct 13 2010 Bundle drwxr-xr-x 6 root other
> 6 Oct 13 2010 auto drwxr-xr-x 3 root bin 11 Oct 13
> 2010 DBD
>
> ls -ltr /usr/perl5/vendor_perl/5.8.4/sun4-solaris-64int/DBD total 543
> -rwxr-xr-x 1 root bin 111586 May 6 2006 Pg.pm
> -rwxr-xr-x 1 root bin 28785 Sep 27 2006 Proxy.pm
> -rwxr-xr-x 1 root bin 7937 Jan 25 2007 Sponge.pm
> -rwxr-xr-x 1 root bin 42836 Feb 6 2007 DBM.pm
> -rwxr-xr-x 1 root bin 19882 Mar 28 2007 File.pm
> -rwxr-xr-x 1 root bin 12051 May 10 2007 ExampleP.pm
> -rwxr-xr-x 1 root bin 43586 May 14 2007 Gofer.pm
> -rwxr-xr-x 1 root bin 3761 Jun 15 2007 NullP.pm drwxr-xr-x 4 root bin 4 Oct 13 2010 Gofer
If DBI is already installed, you should only need to install DBD::Oracle, though you might want to install a later version of DBI. You can install DBD::Oracle under your home directory, then set the PERL5LIB environment variable to that directory (or to include that directory). The long way to install is:
perl Makefile.PL PREFIX=~/perl #Or whatever sub-directory you like
make
make test
make install
Then include at least "~/perl/lib;~/perl/lib/site_perl" in PERL5LIB before running your programs (or include a 'use lib" in your programs).
You can also set certain environment variables like PERL_MM_OPT and PERL_MB_OPT so that you don't have to specify the PREFIX= on the command line (see docs for ExtUtils::MakeMaker and Module::Build). I also recommend cpanm and setting PERL_CPANM_HOME to something under your home directory.
Perl modules can be very well installed in a custom directory. This situation usually arises when you don't have root access to install the PM. Once you have installed DBI and DBD in your custom folder there are several different ways to make sure that perl is aware of this installation.
1. Set the environment variable PERL5LIB
Perl will look for modules in the directories specified in PERL5LIB environment variable before looking in the standard library and current directory, so you can set this variable to locate your modules.
The syntax is the same you use for the PATH environment variables, so you separate the directories with colons on unix and with a semicolon on Windows.
Example:
# unix, bourne shell
PERL5LIB=/home/path/lib:/usr/another/path/lib; export PERL5LIB
Be aware that scripts running with -T option (taint checks) do not use that variable, so in those cases this option won't work.
2. Use '-I' command line parameter
The syntax should be something like:
perl -I /home/path/lib -I /usr/another/lib script.pl
3. Add the library path in your script
The command for including the path in your script is: use lib "path".
Notice that this statement prepends "path" to the #INC array, so it's basically the same as unshift #INC, "path"
Example:
#!/usr/bin/perl
use lib "/home/path/lib";
use lib "/usr/another/lib";