I cannot pass build tests when I build Golang from source:
hg clone -u release https://code.google.com/p/go
cd go/src
./all.bash
....
ok net/url 0.005s
ok os 0.595s
--- FAIL: TestExtraFiles (0.12 seconds)
exec_test.go:230: TestExtraFiles: Something already leaked - closed fd 3
exec_test.go:403: Run: exit status 1; stdout "leaked parent file. fd = 10; want 9\n", stderr ""
FAIL
FAIL os/exec 0.822s
ok os/signal 0.511s
please help. this is on my webfaction shared machine.
[~] lsb_release -a
LSB Version: :core-4.0-ia32:core-4.0-noarch:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-ia32:printing-4.0-noarch
Distributor ID: CentOS
Description: CentOS release 5.10 (Final)
Release: 5.10
Codename: Final
It's a bug in CentOS 5/RHEL 5 according to issue 3001, basicly the kernel ignores O_CLOEXEC.
So either ignore the error (bad idea) or move to a more recent Linux version.
Related
I am trying to compile linux for RISCV Arch using buildroot(busybox). I was using 18.04 and 20.04 previously and had no issues compiling it. Right now, I have upgraded it to 21.10 for building some other stuffs. I have moved my toolchain and I can find it using the which command. When I try to compile linux I get some error which I havn't faced in the earlier versions.
>>> host-m4 1.4.18 Building
In file included from /usr/include/signal.h:328,
from ./signal.h:52,
from c-stack.c:49:
c-stack.c:55:26: error: missing binary operator before token "("
55 | #elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
| ^~~~~~~~
CC closein.o
c-stack.c:134:8: error: variably modified 'buffer' at file scope
134 | char buffer[SIGSTKSZ];
| ^~~~~~
CC closeout.o
I am confused on how different versions can cause this error.
Thanks in advance.
It looks like you have hit a change in GNU C Library version 2.34 that can make SIGSTKSZ non-constant.
From the GNU C Library 2.34 release announcement:
Add _SC_MINSIGSTKSZ and _SC_SIGSTKSZ. When _DYNAMIC_STACK_SIZE_SOURCE or _GNU_SOURCE are defined, MINSIGSTKSZ and SIGSTKSZ are no longer constant on Linux. MINSIGSTKSZ is redefined to sysconf(_SC_MINSIGSTKSZ) and SIGSTKSZ is redefined to sysconf (_SC_SIGSTKSZ). This supports dynamic sized register sets for modern architectural features like Arm SVE.
A possible workaround is to configure buildroot to build host-m4 version 1.4.19 instead of 1.4.18, because it no longer uses SIGSTKSZ.
I saw that error when building on Ubuntu 22.04 for an embedded Linux board using Buildroot. It got stuck when building the host-m4 package. #Ian Abbott is right:
A possible workaround is to configure buildroot to build host-m4 version 1.4.19 instead of 1.4.18, because it no longer uses SIGSTKSZ.
In Buildroot, to update from m4 v 1.4.18 to 1.4.19, simply grab the latest files here: https://github.com/buildroot/buildroot/tree/master/package/m4
As of right now (9 Jan. 2023), the upstream Buildroot m4 version there is
1.4.19, as shown here: https://github.com/buildroot/buildroot/blob/master/package/m4/m4.mk#L7:
################################################################################
#
# m4
#
################################################################################
M4_VERSION = 1.4.19
M4_SOURCE = m4-$(M4_VERSION).tar.xz
M4_SITE = $(BR2_GNU_MIRROR)/m4
M4_LICENSE = GPL-3.0+
M4_LICENSE_FILES = COPYING
$(eval $(host-autotools-package))
How to upgrade/update any buildroot package to the latest upstream version, from the command-line
Here is an example of how to upgrade any buildroot package from the command-line. In these commands, I am upgrading the m4 package, to solve the problem in the OP's question. Change the word m4 in all 3 places to the name of the package you'd like to update:
# initially:
cd path/to/buildroot
git remote add upstream https://github.com/buildroot/buildroot.git
git fetch upstream master
# then (from within the "buildroot" repo or subrepo)
rm -r package/m4
git checkout upstream/master -- package/m4
git add -A
git status
git commit -m "Update m4 library"
My system is WSL 2 in Windows 10.
OS: Debian 10 buster
Kernel: x86_64 Linux 4.19.104-microsoft-standard
Shell: zsh 5.7.1
CPU: AMD Ryzen 9 4900HS with Radeon Graphics # 16x 2.994GHz
Golang info:
go version go1.15.2 linux/amd64
GOROOT="/usr/local/go"
GOPATH="/mnt/c/workspace/6.824"
And I met a problem when I build a project by plugin model:
$ go build -buildmode=plugin ../mrapps/wc.go
build command-line-arguments: cannot find module for path _/mnt/c/workspace/6.824/src/mr
It is so strange that "_/mnt"
How can I solve it?
Why has a "_" before the path?
Help me, please.
I would try and use go mod instead of relying on GOPATH
unset GOPATH
cd /mnt/c/workspace/6.824/
go mod init "yourProject"
go build -buildmode=plugin mrapps/wc.go
You are using go mod. And you can try the following command to fix:
cd 6.824
go mod init "6.824-golabs-2020"
# change file src/mrapps/wc.go line9 to `import "6.824-golabs-2020/src/mr"`
cd src
go build -buildmode=plugin mrapps/wc.go
More details about mod you can refer to https://golang.org/ref/mod
I'm seeing
standard_init_linux.go:207: exec user process caused "exec format
error"
error while running my helloWorldC image as a container. What could be the problem? Any help is appreciated.
I tried the following steps on MacOS with Docker Desktop community edition.
Wrote a simple C++ program, compiled and created an executable.
$ cat helloWorldC.cc
#include<iostream>
using namespace std;
int main() {
cout << "###############################################################\n";
cout << "\tHello from basic C++ HelloWorld Dockerized image \n ";
cout << "###############################################################\n";
return 0;
}
$
$ clang++ -o helloWorldC helloWorldC.cc
$ ./helloWorldC
###############################################################
Hello from basic C++ HelloWorld Dockerized image
###############################################################
$
Then created a minimalistic Dockerfile for my 'helloWorldC' executable -
$ cat Dockerfile
FROM scratch
ADD helloWorldC /
CMD ["/helloWorldC"]
$
Built a docker image -
$ docker build --tag helloworldc .
Sending build context to Docker daemon 550.9kB
Step 1/3 : FROM scratch
--->
Step 2/3 : ADD helloWorldC /
---> 35c21b2c67c9
Step 3/3 : CMD ["/helloWorldC"]
---> Running in bc22fbf4bf85
Removing intermediate container bc22fbf4bf85
---> 96e44669461a
Successfully built 96e44669461a
Successfully tagged helloworldc:latest
$
The Docker image is successfully created -
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
.
.
helloworldc latest 96e44669461a About a minute ago 15.4kB
registry 2 f32a97de94e1 44 hours ago 25.8MB
.
.
$
While running the Docker container, I'm seeing following error.
$ docker run helloworldc
standard_init_linux.go:207: exec user process caused "exec format error"
$
Following is my docker version -
$ docker version
Client: Docker Engine - Community
Version: 18.09.1
API version: 1.39
Go version: go1.10.6
Git commit: 4c52b90
Built: Wed Jan 9 19:33:12 2019
OS/Arch: darwin/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 18.09.1
API version: 1.39 (minimum version 1.12)
Go version: go1.10.6
Git commit: 4c52b90
Built: Wed Jan 9 19:41:49 2019
OS/Arch: linux/amd64
Experimental: false
$
I would like to suggest an alternative solution which makes you able to compile your code and also keep the final image minimal as you wish. This can be done using multi-stage builds which provided by docker. So your Dockerfile can be like this:
FROM gcc:5 as builder
COPY ./helloWorldC.cc /helloWorldC.cc
RUN g++ -o helloWorldC -static helloWorldC.cc && chmod +x helloWorldC
FROM scratch
COPY --from=builder /helloWorldC /helloWorldC
CMD ["/helloWorldC"]
Then after the build you will have a minimal image like this:
REPOSITORY TAG IMAGE ID CREATED SIZE
helloworldimage latest 89800885c997 22 seconds ago 2.17MB
And finally you can run it without any issues:
docker run --rm -it helloworldimage:latest
###############################################################
Hello from basic C++ HelloWorld Dockerized image
###############################################################
You created a dynamically-linked executable, and then tried to run it in a container without any of its libraries, or even the linker. A quick-fix is to call clang++ with the -static flag, but note that glibc isn't really meant to be used that way, so you'll probably want to use musl or some other libc instead if this is more than a toy.
Also, you seem to be trying to compile a Linux binary on your Mac host. If you want that to work, you need to cross-compile. Alternatively, you can run clang on a Linux host, where it will work.
After upgrading haskell platform package, stack command does not work.
$ stack path
No compiler found, expected minor version match with ghc-8.0.1 (x86_64) (based on resolver setting in /home/eii/exercism/haskell/linked-list/stack.yaml).
To install the correct GHC into /home/eii/.stack/programs/x86_64-linux/, try running "stack setup" or use the "--install-ghc" flag.
$
I tried stack setup but it is trying to download an old GHC (ghc-8.0.1). I just installed Haskell platform 8.0.2 (haskell-platform-8.0.2-unknown-posix--full-x86_64.tar.gz). I am using a 64 bit Linux.
$ stack setup
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
ghc-8.0.1: 15.69 MiB / 108.01 MiB ( 14.52%) downloaded...^Cuser interrupt
$
I can compile with ghc-8.0.2 and ghci is working fine.. but I can't use stack nor install new packages.
$ stack update
Downloading package index from https://s3.amazonaws.com/hackage.fpcomplete.com/00-index.tar.gz
Updating package index Hackage (mirrored at https://s3.amazonaws.com/hackage.fpcomplete.com/00-index.tar.gz) ...
$ stack upgrade
Current Stack version: 1.3.2, available download version: 1.3.2
Skipping binary upgrade, your version is already more recent
$ which stack
/usr/local/bin/stack
$ ls -la /usr/local/bin/stack
lrwxrwxrwx. 1 root root 45 Feb 1 18:39 /usr/local/bin/stack -> /usr/local/haskell/ghc-8.0.2-x86_64/bin/stack
$ which ghc
/usr/local/bin/ghc
$ ls -la /usr/local/bin/ghc
lrwxrwxrwx. 1 root root 43 Feb 1 18:39 /usr/local/bin/ghc -> /usr/local/haskell/ghc-8.0.2-x86_64/bin/ghc
$
Please help.
I encountered this the other day on Arch Linux 4.17.4. The error was:
No setup information found for ghc-8.4.3 on your platform.
This probably means a GHC bindist has not yet been added for OS key 'linux64-ncurses6', 'linux64-tinfo6'.
Supported versions: ghc-7.8.4, ghc-7.10.2, ghc-7.10.3, ghc-8.0.1, ghc-8.0.2, ghc-8.2.1, ghc-8.2.2, ghc-8.4.1, ghc-8.4.2
As a workaround, I edited stack.yml to change
lts-12.0
to
lts-11.15
I'm working on packaging up some work into an rpm. I am doing this on Mac OSX after brew installing rpm. I have a basic .spec file, but I am getting an error and have been unable to diagnose it:
$ rpmbuild -ba myapp.spec
Executing(%prep): %{__spec_prep_cmd} /usr/local/Cellar/rpm/5.4.10/var/tmp/rpm-tmp.14478
error: Bad exit status from /usr/local/Cellar/rpm/5.4.10/var/tmp/rpm-tmp.14478 (%prep)
RPM build errors:
Bad exit status from /usr/local/Cellar/rpm/5.4.10/var/tmp/rpm-tmp.14478 (%prep)
The spec files is as follows:
Name: myapp
Version: 0.1.0
Release: 1
Summary: Web service to do stuff
URL: http://myapp.com
BuildRoot: %{_tmppath}/myapp-build-root
%description
My app
%prep
%build
%install
%pre
%preun
%postun
%clean
%files
%defattr(-,www-data,www-data,-)
%doc
This is my first time building an rpm, what am I doing wrong, and how can I fix this. Thanks in advance!
I ran into the same issue today. For no obvious reason the %prep macro fails, even without any content.
Running your spec on my Ubuntu box seems to work just fine after adding those two values:
License: yourLicense
Group: yourGroup
I have reason to believe, that rpm didn't get installed correctly on my box via homebrew. I think I aborted the process at some point, then forgot about it over lunch, but rpmbuild was available to use from within my script and I ran into the issue above.
I will try doing a clean install of the rpm formula in verbose mode to see whether my assumption is correct.
Update:
I've installed rpm successfully, but it took an awful long time:
/usr/local/Cellar/rpm/5.4.10: 187 files, 9.7M, built in 92.4 minutes
Nevertheless, it keeps on failing with the same error
rpmbuild -ba so.spec
Executing(%prep): %{__spec_prep_cmd} /usr/local/Cellar/rpm/5.4.10/var/tmp/rpm-tmp.69701
error: Bad exit status from /usr/local/Cellar/rpm/5.4.10/var/tmp/rpm-tmp.69701 (%prep)
With the content of /usr/local/Cellar/rpm/5.4.10/var/tmp/rpm-tmp.69701 saying:
%{__spec_prep_template}%{__spec_prep_post}