Git Product home page Git Product logo

viceroy's Introduction

Viceroy logo

Viceroy is a base Docker image which provides a viceroycc binary to cross compile to multiple architectures. It was designed to help ease the burden of cross compiling Go projects which have C dependencies.

Viceroy is not very useful on its own; it should be extended to add libraries and other tools needed to build projects.

Supported Platforms

Viceroy examines the following environment variables to determine which target system to cross-compile for:

  • VICEROYOS (or GOOS)
  • VICEROYARCH (or GOARCH)
  • VICEROYARM (or GOARM)

These environment variables determine which compiler toolchain to use and some defaults for environment variables (such as LD_LIBRARY_PATH). The environment variables will default to values appropriate for the worker container's environment when unspecified.

The following target platforms are currently supported:

linux darwin freebsd windows
amd64 x x x x
386 x x x
armv5 x
armv6 x
armv7 x
arm64 x x x
ppc64le x
s390x x

Usage

  1. Use rfratto/viceroy as your Docker base image.
  2. Set CC=viceroycc.
  3. Set VICEROYOS, VICEROYARCH, and VICEROYARM as appropriate.
  4. Compile!

Building locally

The Viceroy image can be built for your local platform by running make build.

The OSXCROSS_SDK_URL environment variable should be set to a URL or path on the host machine to a .tar.xz of an osxcross packaged macOS 11.1 SDK.

Legal note

OSX/Darwin/Apple builds: Please ensure you have read and understood the Xcode license terms before continuing.

viceroy's People

Contributors

rfratto avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar

Forkers

isgasho tuananh missingcharacter

viceroy's Issues

Upgrade to version 12 of the MacOS SDK

Version 11 of the SDK doesn't work for libraries such as [email protected]. This version of go-m1cpu is used by the OpenTelemetry Collector. We could work around this by using version v0.1.6, but it would be even better to just update the SDK.

The reason we cannot use v.0.1.4 is that apparently "the kIOMainPortDefault variable is only available on MacOS 12.0+ (Monterey); before that, it was named kIOMasterPortDefault.".

Remove extra mount for /proc

The workaround added for darwin support requires mounting /proc on top of the chroot:

viceroy/cmd/viceroyfs/main.go

Lines 240 to 267 in f99e9f9

// Overlay special filesystems on top of FUSE so clang can read from /proc.
//
// NOTE(rfratto): This is a terrible hack, and I couldn't get clang to work
// for Darwin builds until these paths were mounted. We can't read from these
// files without CUSE, and it's easier just to overlay them on top.
//
// Ideally we can find a way to configure clang to not read from /proc so we
// can avoid the hacky mounts here.
bindMounts := []struct{ From, To string }{
{"/dev", filepath.Join(t.mountPath, "/dev")},
{"/proc", filepath.Join(t.mountPath, "/proc")},
{"/sys", filepath.Join(t.mountPath, "/sys")},
}
for _, bm := range bindMounts {
err := syscall.Mount(bm.From, bm.To, "", syscall.MS_BIND, "")
if err != nil {
return fmt.Errorf("creating %q mount: %w", bm.To, err)
}
}
defer func() {
for i := len(bindMounts) - 1; i >= 0; i-- {
bm := bindMounts[i]
err := syscall.Unmount(bm.To, syscall.MNT_DETACH)
if err != nil {
level.Warn(t.log).Log("msg", "failed to unmount", "mount", bm.To, "err", err)
}
}
}()

Aside from feeling hacky, it's likely prone to deadlocking if the process only has one thread available to it (Go expecting all syscalls to support async I/O causes issues with FUSE, which is also why viceroyfs is launched as a child process of viceroyworkerd)

We currently need /proc because OSXCross expects it to be mounted. Unless I'm missing something, it should be possible to remove the requirement by adding in various fallbacks similar to the ones found in Clang.

At the moment, I don't see a reason to need /proc available in the viceroy chroot outside of this issue. It seems worthwhile to have OSXCross support chroots rather than finding a permanent way to add these extra mounts on top of the viceroy overlay chroot.

Find a way to expose project-specific build dependencies

The default libraries installed in Viceroy worker containers may not be enough to build any given project. There is currently no way for projects to expose their extra build dependencies in a way Viceroy can use.

Viceroy needs a way to allow projects to define extra build dependencies, which may be need for any combination of Linux, macOS, Windows, and FreeBSD builds.

Security is the biggest concern here; Viceroy allows access to the host filesystem, and we'd want users to be able to audit the custom containers used for building.

So far, I can think of two ways to do this:

  1. Allow projects to specify custom build containers. Exposing security auditing capabilities would be likely very difficult here.

  2. Allow some kind of project manifest to list extra Deb repositories, dependencies, files/folders (with a checksum) to add into the worker containers. This one is harder to implement, but easier to audit from a security perspective.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.