I thought I would use wsl (windows subsystem for Linux) to cross-compile an application I have. I downloaded a .tar of the cross system, moved the .tar to wsl, untarred it, and now I can't run the compiler. I don't understand! And I am obviously brand new at wsl :)
Here's what I see:
rw#seven:~$ ln -s /opt/crosstool/gcc-4.0.1-glibc-2.3.5/arm-unknown-linux-gnu/bin/ ct
rw#seven:~$ ct/arm-unknown-linux-gnu-c++
-bash: ct/arm-unknown-linux-gnu-c++: No such file or directory
rw#seven:~$ ll ct/arm-unknown-linux-gnu-c++
-rwxr-xr-x 2 500 500 206621 Feb 12 2006 ct/arm-unknown-linux-gnu-c++*
rw#seven:~$ file ct/arm-unknown-linux-gnu-c++
ct/arm-unknown-linux-gnu-c++: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, with debug_info, not stripped
rw#seven:~$ strace ct/arm-unknown-linux-gnu-c++
execve("ct/arm-unknown-linux-gnu-c++", ["ct/arm-unknown-linux-gnu-c++"], 0x7ffe4559ecf0 /* 21 vars */) = -1 ENOENT (No such file or directory)
strace: exec: No such file or directory
+++ exited with 1 +++
rw#seven:~$ ldd ct/arm-unknown-linux-gnu-c++
not a dynamic executable
rw#seven:~$
Is there some way to run this compiler under wsl?
It's wsl 2. Ubuntu. Windows 10.
rw#seven:~$ uname -a
Linux seven 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Thank you, Mark.
https://askubuntu.com/questions/454253/how-to-run-32-bit-app-in-ubuntu-64-bit
solved my immediate problem. Which leads me to the next problem, of course :)
Related
trying to compile openmpi with intel oneapi 2022.0.1 compilers
OS is 5.4.0-26-generic #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
I got the intel compilers as follows (just to make sure I didn't mess anything up at that step)
sudo add-apt-repository "deb https://apt.repos.intel.com/oneapi all main"
sudo apt install intel-basekit
sudo apt install intel-hpckit
Configuring openmpi with:
./configure --prefix=${HPCX_HOME}/ompi-icc CC=/opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/icc CXX=/opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/icpc F77=/opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/ifort FC=/opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/ifort --with-ucx=/usr --with-platform=contrib/platform/mellanox/optimized
my .bashrc has (root has the same .bashrc)
source /opt/intel/oneapi/setvars.sh
export LD_LIBRARY_PATH=/opt/intel/oneapi/compiler/2022.0.1/linux/compiler/lib/intel64_lin
After configure I do : sudo make all install and get the following error:
ld: /opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/../../bin/intel64/../../lib/icx-lto.so: error loading plugin: libimf.so: cannot open shared object file: No such file or directory
There is no ifortvars.sh with this new version of oneAPI which seems to have solved similar issues for others in the past.
libimf.so is in:
/opt/intel/oneapi/itac/2021.5.0/bin/rtlib/libimf.so
/opt/intel/oneapi/compiler/2022.0.1/linux/compiler/lib/intel64_lin/libimf.so
/opt/intel/oneapi/intelpython/python3.9/pkgs/intel-cmplr-lib-rt-2022.0.1-intel_3633/lib/libimf.so
/opt/intel/oneapi/intelpython/python3.9/lib/libimf.so
/opt/intel/oneapi/intelpython/python3.9/envs/2022.0.1/lib/libimf.so
Any help and/or advice regarding compiling openmpi with recent intel compilers would be appreciated.
Here is the solution I found but doubt that this is the most elegant way of doing this:
OS is 5.4.0-26-generic #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
my .bashrc has (root has the same .bashrc)
source /opt/intel/oneapi/setvars.sh
created intel_libs.conf in
/etc/ld.so.conf.d/ and added the line /opt/intel/oneapi/compiler/2022.0.1/linux/compiler/lib/intel64_lin this is where the libimf.so lives.
sudo ldconfig
compiled openmpi with intel compilers fine after that using:
./configure --prefix={HPCX_HOME}/ompi-icc CC=/opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/icc CXX=/opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/icpc F77=/opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/ifort FC=/opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/ifort --with-ucx=/usr --with-platform=contrib/platform/mellanox/optimized
sudo make all
sudo make install
I hope this helps someone else and please let me know if there is a better way of doing this. Cheers
I am also facing similar issue not exactly. I installed the new ifort using the following command lines:
wget https://registrationcenter-download.intel.com/akdlm/irc_nas/18236/l_BaseKit_p_2021.4.0.3422.sh
sudo bash l_BaseKit_p_2021.4.0.3422.sh
wget https://registrationcenter-download.intel.com/akdlm/irc_nas/18211/l_HPCKit_p_2021.4.0.3347.sh
sudo bash l_HPCKit_p_2021.4.0.3347.sh
There is no file called setvars.sh inside the source /opt/intel/oneapi/, also while compiling any mpiifort file it is throwing me an error saying:
error loading plugin: libimf.so: cannot open shared object file: No such file or directory
Not even sure, if this is related to this thread or not, but any further guidance would be very helpful, thanks in advance.
I need to analyse linux binary executable file using strace for capturing the system calls.
On running the command:
/usr/bin/strace ./005f32fffe1da3bc100e7dcd8b2f8f2c
I got this error:
execve("./005f32fffe1da3bc100e7dcd8b2f8f2c", ["./005f32fffe1da3bc100e7dcd8b2f8f"...], 0x7fffd9d0a120 /* 53 vars */) = -1 ENOENT (No such file or directory) fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 write(2, "/usr/bin/strace: exec: No such f"..., 49/usr/bin/strace: exec: No such file or directory ) = 49 getpid() = 3699 exit_group(1) = ? +++ exited with 1 +++
My file type is 32 bit ELF binary.
file 005f32fffe1da3bc100e7dcd8b2f8f2c
005f32fffe1da3bc100e7dcd8b2f8f2c: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-, stripped
My machine is 64 bit running Ubuntu and I have libc6-i386 lib32stdc++6 lib32gcc1 lib32ncurses5 lib32z1 installed.
This binary is strange: it is linked to use /lib/ld- as a dynamic loader.
The 32-bit i386 dynamic loader is usually called /lib/ld-linux.so.2. We can assume that your binary has been corrupted in some way.
In your other comment, you said that the binary will not run without strace (because /lib/ld- does not exist). Running the binary under strace can magically make the binary work.
You should be able to run it under strace by using explicit loader invocation:
strace -ff /lib/ld-linux.so.2 ./005f32fffe1da3bc100e7dcd8b2f8f2c
Update:
I am getting some system calls like this :
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
stat64("/lib/i686/sse2", 0xffe9b300) = -1 ENOENT (No such file or directory)
+++ exited with 127 +++
I am not sure what kind of system calls are these ?
This is the dynamic linker attempting to load your program, and using access and stat64 system calls.
how to run the following file with strace? How do know which library to use in strace command with -ff option based on file command output ?
file mosquitto_pub
mosquitto_pub: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 2.6.32, BuildID[sha1]=7ced951dc3a859a6829feb46fd5cf757a6073361, not stripped
This is a 64-bit binary with similarly corrupted /lib64/l dynamic loader.
The standard 64-bit loader for GLIBC on x86-64 is /lib64/ld-linux-x86-64.so.2, so the command you want is:
strace -ff /lib64/ld-linux-x86-64.so.2 ./mosquitto_pub
So I just installed Arch and most things are working fine, but when I try to use pacman or curl, I get the error:
pacman: error while loading shared libraries: /usr/lib/libcurl.so.4: invalid ELF header
Also, I can't seem to run anything pacman-related for now... not even a pacman --help
Not sure if useful, but ls -l /usr/lib | grep libcurl gives:
-rw-r--r-- 1 root root 594016 Jun 22 12:21 libcurl.a
lrwxrwxrwx 1 root root 16 Jun 22 12:21 libcurl.so -> libcurl.so.4.3.0
lrwxrwxrwx 1 root root 16 Jun 22 12:21 libcurl.so.4 -> libcurl.so.4.3.0
-rwxr-xr-x 1 root root 408324 Jun 22 12:21 libcurl.s0.4.3.0
Thanks in advance!
Update: running ./curl-config gives the error, "cannot execute binary file". This makes me wonder if maybe I have a 64 bit version, whilst I'm running Arch i686. What is the best way to handle this?
maybe I have a 64 bit version, whilst I'm running Arch i686
That would do it. Run file ./curl-config. If it says ELF 64-bit LSB executable,... reinstall curl from correct packages.
I am running Centos 5.8 on a production server. I have an application that needs to use the keyctl command, but everytime the app calls (or I call) the command, I have some errors.
The first error was this:
root#server [~] keyctl show
segmentation fault
Then, I re-installed the keyutils binaries using yum. These are the keyutils packages I have on the server:
root#server [~]# rpm -qa | grep keyutils
keyutils-libs-1.2-1.el5
keyutils-libs-1.2-1.el5
keyutils-1.2-1.el5
keyutils-libs-devel-1.2-1.el5
And now, I have another different error:
root#server [~]# keyctl show
keyctl: symbol lookup error: /lib64/libkeyutils.so.1: undefined symbol: dlopen
I checked the libraries of keyctl, and libdl is not there.
root#server [~]# ldd /bin/keyctl
linux-vdso.so.1 => (0x00007fffcc5fd000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00000033df000000)
libc.so.6 => /lib64/libc.so.6 (0x0000003d7ae00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003d7aa00000)
All libraries that uses are fine.
root#server [~]# ls -al /lib64/libkeyutils*
-rwxr-xr-x 1 root root 9472 Jan 6 2007 /lib64/libkeyutils-1.2.so*
lrwxrwxrwx 1 root root 18 Nov 21 07:56 /lib64/libkeyutils.so.1 -> libkeyutils.so.1.9*
-rwxr-xr-x 1 root root 34584 Jan 6 2007 /lib64/libkeyutils.so.1.9*
root#server [~]# ls -al /lib64/libdl*
-rwxr-xr-x 1 root root 23360 Aug 27 08:59 /lib64/libdl-2.5.so*
lrwxrwxrwx 1 root root 12 Nov 16 02:01 /lib64/libdl.so.2 -> libdl-2.5.so*
root#server [~]#
Have you ever seen this problem before? I tried run the same version on others distros and it works.
I would like to re-install this server, but I can't because it is a production server.
Is there a way I can add or link a shared library to a binary already linked to others .so libraries?
Look at: http://blog.solidshellsecurity.com/2013/02/08/sshd-spam-rootkit-lib64libkeyutils-so-1-9/
It appears that there is no such legitimate file as libkeyutils.so.1.9
It is a rootkit, the latest legitimate version of this library is libkeyutils.so.1.3 on CentOS 6.3 (final).
rm -f /lib64/libkeyutils.so.1.9
ldconfig
/etc/init.d/sshd restart
There's also a suspected (as of now) unpatched user escalation priviledge flaw in all CentOS and RedHat kernels: https://access.redhat.com/security/cve/CVE-2013-0871 and http://blog.configserver.com/index.php?itemid=716
You may also need to reinstall SSH:
https://serverfault.com/questions/476954/remove-shared-library-from-sshd
https://forums.cpanel.net/f185/sshd-rootkit-323962.html
LD_PRELOAD=/lib64/libdl-2.5.so keyctl show
I just installed g++ from cygwin, when I try to compile a C++ file I am not getting any executable produced by the compiler, see example below. What's going wrong?
Directory of C:\helloworld
01/02/2011 04:50 PM .
01/02/2011 04:50 PM ..
01/02/2011 04:48 PM 94 helloworld.cpp
1 File(s) 94 bytes
2 Dir(s) 24,658,272,256 bytes free
C:\helloworld>g++-4 helloworld.cpp
C:\helloworld>dir
Volume in drive C is OS
Volume Serial Number is C47B-942D
Directory of C:\helloworld
01/02/2011 04:50 PM .
01/02/2011 04:50 PM ..
01/02/2011 04:48 PM 94 helloworld.cpp
1 File(s) 94 bytes
2 Dir(s) 24,657,747,968 bytes free
C:\helloworld>
For others who end up here with g++ producing no output.
I solved it by running cygcheck -s in the cygwin terminal window. This checks (amongst others) for multiple instances of cygwin1.dll. In my case WinAVR was causing problems, uinstalling did the the trick
This link was also helpful in getting Cygwin to run properly: http://thehacklist.blogspot.nl/2009/04/cygwin-ls-command-not-found.html
The problem seems to be (judging from your C:\ prompt) that you are not running Cygwin. Try double-clicking the Cygwin icon.
You should be able to run any Cygwin program from the DOS prompt since Cygwin is not an operating system like Linux, it is primarily a special DLL that programs link against + tools. However, in this case, I suspect that path issues are preventing g++ from running, either the path to g++ itself or to some libs g++ requires. Cygwin apps are notoriously bad at giving any info when they don't run, and the solution is to run them via strace.
C:\cygwin\bin> strace g++
Then any issues will be shown in a windows dialog box.