Recently i have updated to Catalina and when i have tried running ngrok below error comes in:
-bash: ./ngrok: cannot execute binary file
Below are the details of file and system:
cmd:- file ./ngrok
output:- ./ngrok: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=WiQDkmDKISYhEPN12k-3/C6vlWFNDOR0o0u0x3X26/VIi6gzoMVXoqHTYgeFTz/LKswZ3xo2O5g2OnUiOwZ, not stripped
cmd:- uname -a
output:- Darwin XXXXXXX-MacBook-Air.local 19.2.0 Darwin Kernel Version 19.2.0: Sat Nov 9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64 x86_64
Any update would be appreciated
It was an access permission issue but this npm module solves it https://www.npmjs.com/package/ngrok, now it working smoothly.
Related
I have a third party library file compiled for Linux, when I tried to execute using terminal I get the error:
cannot execute binary file:
File details are as follows:
ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 3.2.0, BuildID[sha1]=820d7e089c6c3cdc19fa3e759ccae22fbc672652,
with debug_info, not stripped
I tried installing Rosetta, tried running with the command with a prefix arch -x86_64
but it resulted in the same error.
If I try to execute them on the terminal application directly, it shows the error:
zsh: exec format error:
I try to compile a go program on my Linux desktop (Linux desktop 4.10.0-28-generic #32-Ubuntu SMP Fri Jun 30 05:32:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux), go version go version go1.8.3 linux/amd64 to arm:
$ GOPATH=/home/xrfang/git/hermes/ GOARM=7 GOARCH=arm go build .
the executable is generated, but seems NOT ARMv7:
$ file hermes
hermes: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped
It shows EABI5. How can I cross-compile to ARMv7? Is there anything missing on my Linux Desktop so that the cross-compile fallback to a lower ARM version?
Thanks.
I believe, it is not ARMv5. I was trying to do the same on MAC OS and 'file' command on Mac is saying v7, but the 'file' command on Linux don't. However, I do know that v7 has some good improvements and may boost the performance of your program.
But, that is out of scope of this question and you may need to dig deeper into what you're doing and why a performance improvement is expected.
All I can say is, it is compiled for v7.
I installed the golang.
~/go/bin$ ls
go godoc gofmt
Trying to test, but to no avail.
~/go/bin$ go version
-bash: /home/orc/go/bin/go: no such file or directory
My $PATH:
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/orc/go/bin:
Info:
~/go/bin$ uname -m
x86_64
~/go/bin$ file go
go: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
~/go/bin$ pwd
/home/orc/go/bin
Please tell me what's wrong?
UPDATE
~/go/bin$ ls -l
итого 28688
-rwxr-xr-x 1 orc orc 9571864 Фев 18 14:40 go
-rwxr-xr-x 1 orc orc 16164032 Фев 18 14:41 godoc
-rwxr-xr-x 1 orc orc 3594712 Фев 18 14:40 gofmt
~/go/bin$ ./go
-bash: ./go: Нет такого файла или каталога
!!!
~/go/bin$ file $(which ls)
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
~/go/bin$ uname -a
Linux olimp-web 2.6.32-5-amd64 #1 SMP Mon Jun 13 05:49:32 UTC 2011 x86_64 GNU/Linux
Please explain how to fix it?
Have you checked that you have the correct version for your architecture installed. I have just had this exact problem when I put a 32-bit binary on a 64-bit virtual machine. I removed the 32-bit version and installed the architecture appropriate version (based on the instructions on the website) and it worked. Hope that works for you too.
A couple of things to check, which may come to nothing, but they'll at least rule out things:
There's no indication in your question that your current directory is within /home/orc, a simple pwd should clarify that.
Can you run the file directly, such as with ./go or ~/go/bin/go?
Is it executable? The output of ls -l should clarify that.
Get the full machine details with uname -a.
Check the system executables in case it's somehow not 64-bit, despite the indication: file $(which ls).
Make sure there's no funny characters in the path that would prevent it being picked up there: echo $PATH | od -xcb.
Make sure your GOPATH is set up correctly (not sure this would affect go version but it's something extra to try).
In my case go compiler and language were not installed...
sudo apt install golang-go
For me this was the answer, this is on ubuntu18.04 windows subsystem linux 2 install:
export GOPATH=$HOME/go
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
I was facing the same issue in Docker, I'm writing an answer for anybody that may be using docker, In my case I had to install glibc, for context I'm using alpine3.17
And here's the portion of my dockerfile -
COPY --from=golang:1.19.5-alpine3.17 /usr/local/go/ /usr/local/go/
ENV GOPATH=/go
ENV PATH="${PATH}:/usr/local/go/bin:$GOPATH/bin"
RUN apk update && apk add --no-cache wget gcompat && apk -U upgrade
RUN wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub
RUN wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.35-r0/glibc-2.35-r0.apk
RUN apk add --force-overwrite glibc-2.35-r0.apk
I have an ARM machine that runs Linux (BusyBox).
# uname -a
# Linux XXXXXXXX 2.6.28 #1 PREEMPT Fri Sep 26 22:47:38 UTC 2014 armv5tel GNU/Linux
I've cross-compiled a simple program on my Ubuntu 32-bit desktop:
./configure --host=arm-linux-gnueabi LDFLAGS="-static"
make
But when I try to run it on the ARM machine, it gives me Segmentation Fault error.
Program is super simple:
#include <stdio.h>
int main()
{
printf("Hello, World!");
return 0;
}
Here are a few things I've already tried/checked:
I've checked md5 hashes on both machines to eliminate the possibility that something went wrong at the time of copying an executable over the network
Stripped the executable with arm-linux-gnueabi-strip. I was comparing my executable with another executable that was already in the target machine with file:
# file my_program
# my_program: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.31, BuildID[sha1]=0x4b1f2773e54b141d5157b86f0f10438a372625c9, stripped
# file their_program
# their_program: ELF 32-bit LSB executable, ARM, version 1 (GNU/Linux), statically linked, stripped
What am I doing wrong?
Apparently my cross-compile toolchain was not the right one.
I ended up using crosstool-ng. Btw it's very simple to use and a great tool, all you have to do is to choose the right toolchain for your device.
I have built an arm-unknown-linux-uclibcgnueabi toolchain with crosstool-ng, which solved my problem.
I've copied the latest version of ksh93 into the darwin computer but for some reason it doesn't work.
Whenever I execute anything with ksh (for example "ksh --version") this is the error that I get:
dyld: unknown required load command 0x80000022
Trace/BPT trap
Do you know what it might be?
My version is the following:
Darwin paramisx82614.fr.net.intra 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
The ast ksh downloads for Darwin require Mac OS X. So your kernel should be 10.x as well.
If you really need ksh for Darwin 9.x you will have to compile it from source.