https://github.com/mt-inside/envbin
A container image that prints info about its environment, and has testing features
https://github.com/mt-inside/envbin
Last synced: 4 months ago
JSON representation
A container image that prints info about its environment, and has testing features
- Host: GitHub
- URL: https://github.com/mt-inside/envbin
- Owner: mt-inside
- Created: 2020-03-10T11:05:54.000Z (over 6 years ago)
- Default Branch: master
- Last Pushed: 2024-09-19T08:49:56.000Z (almost 2 years ago)
- Last Synced: 2025-12-18T03:17:02.865Z (6 months ago)
- Language: Go
- Size: 460 KB
- Stars: 8
- Watchers: 1
- Forks: 9
- Open Issues: 29
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
## Use
Run from container image:
```bash
docker run -t --rm ghcr.io/mt-inside/envbin:v0.0.8 dump
```
Download single, statically-linked binary.
Binaries are not available for Mac, because reasons.
```bash
wget -O envbin https://github.com/mt-inside/envbin/releases/download/v0.0.8/envbin-$(uname -s)-$(uname -m)
chmod u+x envbin
./envbin dump
```
### On builds, linking, and CGO
gousb needs libusb, so we need CGO to call it.
Because we use CGO, we don't get static linking by default.
Trying to statically link is basically a folly across Linux and Darwin, and using Go's native cross-compilation (GH Actions do this when building raw binaries).
Thus we don't try, and will get dynamically-linked binaries.
libusb will need to be present when we cross-compile? Or do we just need headers?
These binaries will need libusb, and the right version of the right libc at runtime, which isn't ideal.
The `native` tag tries to exclude things that are unlikely to work in a container or other sandbox, ie not running "natively" on the host.