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
Related
I'm trying to cross-compile a modified version of the official Debian kernel for armhf on my amd64 machine. I'm using the HowToCrossBuildAnOfficialDebianKernelPackage instructions on the Debian wiki.
The kernel itself builds fine, but I get an error from ld when trying to build objtool for the linux-kbuild package:
# make -f debian/rules.real build-kbuild KBUILD_HOSTLDFLAGS="-L/usr/lib/arm-linux-gnueabihf"
[...]
arm-linux-gnueabihf-gcc /usr/src/linux.buster-backports/debian/build/build-tools/tools/objtool/objtool-in.o -lelf /usr/src/linux.buster-backports/debian/build/build-tools/tools/objtool/libsubcmd.a -L/usr/lib/arm-linux-gnueabihf -o /usr/src/linux.buster-backports/debian/build/build-tools/tools/objtool/objtool
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lelf
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:67: /usr/src/linux.buster-backports/debian/build/build-tools/tools/objtool/objtool] Error 1
You can see that make did add the -L/usr/lib/arm-linux-gnueabihf flag to gcc. And /usr/lib/arm-linux-gnueabihf does contain libelf:
# ls -l /usr/lib/arm-linux-gnueabihf/libelf*
-rw-r--r-- 1 root root 67296 May 28 2019 /usr/lib/arm-linux-gnueabihf/libelf-0.176.so
lrwxrwxrwx 1 root root 15 May 28 2019 /usr/lib/arm-linux-gnueabihf/libelf.so.1 -> libelf-0.176.so
# file /usr/lib/arm-linux-gnueabihf/libelf-0.176.so
/usr/lib/arm-linux-gnueabihf/libelf-0.176.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=51d60560aa6c0538f0bf34c07e4e2bc230c00834, stripped
I installed libelf like this:
dpkg --add-architecture armhf
apt-get update
apt-get install libelf1:armhf
The ld that's being used does appear to be for arm:
# /usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld -V
GNU ld (GNU Binutils for Debian) 2.31.1
Supported emulations:
armelf_linux_eabi
armelfb_linux_eabi
I'm stumped. How do I get ld to link libelf?
Neither libelf-0.176.so nor libelf.so.1 are searched by the -lelf option to the linker. You still need libelf.so file. This file can be created:
By installing libelf-dev package (as usual, the libraries with exact .so are installed by *-dev packages). Make sure to choose a package suitable for cross-compiling.
By creating symlink libelf.so pointed to the libelf-0.176.so file which you have.
My operating system is CoreELEC
$ uname -a
$ Linux CoreELEC 4.9.113 #1 SMP PREEMPT Thu May 21 01:00:42 CEST 2020 aarch64 GNU/Linux
My cpu arch is aarch64
$ arch
$ aarch64
qrencode is ok
$ qrencode -V
$ qrencode version 4.0.2
But, I can't use it to generate PNG images, like this:
$ qrencode -o /storage/pictures/a.png "LDL6867PM1S3KV9G111A"
$ PNG output is disabled at compile time. No output generated.
If anyone knows what the problem is, please let me know, thank you very much!!!
When you are building from source and you run the ./configure step, what it does is checks to see the capabilities of the system before running the make step.
If you looked at what it output when you ran ./configure as you were building qrencode you would have seen something like this:
checking for png... no
!!!!!!!!!!
LIBPNG is required to build the utility tools. Temporarily disabled.
!!!!!!!!!!
so it's telling you that you are missing libpng and therefore it's going to disable png output. So while you have built qrencode, your binary has png output disabled which isn't particularly helpful.
When you attempted to run your new qrencode binary and got this error message:
PNG output is disabled at compile time. No output generated.
It was just informing you that your binary was compiled with png output disabled because as far as ./configure could tell, libpng wasn't available on your system.
To solve this, install libpng then go back and re-build your qrencode binary - checking to make sure the ./configure step correctly finds libpng.
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.
When I try to execute a 32-bit file compiled with gcc -m32 main.c -o main on Windows Subsystem for Linux, I get the following error: bash: ./main: cannot execute binary file: Exec format error.
If I compile it without -m32 it runs.
Any solution for running 32-bit executable on WSL?
QEMU and binfmt support light the way :)
https://github.com/microsoft/wsl/issues/2468#issuecomment-374904520
After reading that the WSLInterop between WSL and Windows processes used binfmt, I was tinkering with QEMU to try some ARM development, and incidentally discovered how to get 32-bit support working.
Edit: requires "Fall Creators Update", 1709, build 16299 or newer
Install qemu and binfmt config:
sudo apt install qemu-user-static
sudo update-binfmts --install i386 /usr/bin/qemu-i386-static --magic '\x7fELF\x01\x01\x01\x03\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x00\x01\x00\x00\x00' --mask '\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xf8\xff\xff\xff\xff\xff\xff\xff'
You'll need to reactivate binfmt support every time you start WSL:
sudo service binfmt-support start
Enable i386 architecture packages:
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install gcc:i386
Try it out:
$ file /usr/bin/gcc-5
/usr/bin/gcc-5: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=2637bb7cb85f8f12b40f03cd015d404930c3c790, stripped
$ /usr/bin/gcc-5 --version
gcc-5 (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
Copyright (C) 2015 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.
$ gcc helloworld.c -o helloworld
$ ./helloworld
Hello, world!
$ file helloworld
helloworld: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=3a0c7be5c6a8d45613e4ef2b7b3474df6224a5da, not stripped
And to prove it really was working, disable i386 support and try again:
$ sudo service binfmt-support stop
* Disabling additional executable binary formats binfmt-support [ OK ]
$ ./helloworld
-bash: ./helloworld: cannot execute binary file: Exec format error
32-bit ELF support isn't provided by WSL (yet). There doesn't seem to be any progress since the UserVoice was raised - you are out luck.
See UserVoice: Please add 32 bit ELF support to the kernel and Support for 32-bit i386 ELF binaries.
If possible, switch to a real Linux ;-)
Since this was originally posted, the support has been available on WSL2 which does support real Linux kernel! So that should be the preferred way.
As noted in the linked github issue, there's also qemu-user which can be used if WSL1 is still used.
WSL2 runs in a real virtual machine using a real Linux kernel, therefore it's actually possible to do anything a Linux VM can do, including running 32-bit code. Just install 32-bit libs by running
sudo dpkg --add-architecture i386
sudo apt-get update
For more information read
Announcing WSL 2
WSL 2 FAQ
I am trying to create binding for a C library using Cgo. I have package which uses Cgo to import the library and make some calls to it. It compiles and installs fine. But when trying to use that package from a Go program, I get the the error "unexpected R_X86_64_64 relocation for dynamic symbol" when linking.
Any ideas?
It appears in the assembly generation routines in the 6g compiler:
case 256 + R_X86_64_64:
if(targ->dynimpname != nil && !targ->dynexport)
diag("unexpected R_X86_64_64 relocation for dynamic symbol %s",
targ->name);
r->type = D_ADDR;
return;
The R_X86_64_64 is a type of a symbol in the library. For more information about relocation in the amd64 architecture consult page ~70 here.
Is it possible that you mix 386 compiled library with amd64 code?
The compiler should report the exact symbol which caused the problem. Can you try linking with a minimal library containing other symbols, and try to locate a minimal example where it fails?
Did you manage to use cgo with any library at all?
I agree with Elazar that it seems plausible that mixing of 32-bit and 64-bit code is involved.
Have you tried gccgo?
Works like a charm :
root#Ubuntu-1304-raring-64-minimal:/etc# uname -a
Linux Ubuntu-1304-raring-64-minimal 3.8.13.4 #2 SMP Mon Jul 8 23:59:05 CEST 2013 x86_64 x86_64 x86_64 GNU/Linux
do this sequence :
cd /usr/local
mkdir /var/go
apt-get install mercurial
hg clone https://code.google.com/p/go/
After that create a /etc/profile.d/go.sh with the follewing contents and make it executable:
export GOPATH=/var/go
export GOROOT=/usr/local/go
export GOBIN=$GOPATH/bin
export PATH=$PATH:$GOBIN
export GOROOT_FINAL=/var/go
export GOHOSTARCH=amd64
export GOARCH=amd64
export CGO_ENABLED=1
And then restart your shell. NO source xxx will be working properly - be warned! In a new shell do this :
cd /usr/local/go/src
./make.bash
do the thing, and then copy all the things from /usr/local/go to /var/go - or there's a way to merge both directories by symlink, whatever you prefer. After that comment GOROOT_FINAL in go.sh script above AND restart your shell again. And you're ok with latest working Go language!
root#Ubuntu-1304-raring-64-minimal:/usr/work/golang/go/src# go version
go version devel +35d5bae6aac8 Fri Oct 18 10:45:19 2013 +0400 linux/amd64
Note bene : Two shell restarts are required - found it myself in a hard way.