Hacker News new | past | comments | ask | show | jobs | submit login

If you cross-compile (which everybody using macOS to developer for Linux servers does), it's annoying to introduce SQLite to your project, because immediately the conventional `GOOS= GOARCH= go build` trick stops working. But, in case it's helpful, it's also really easy to set up a full cross-compiling environment, either with Zig or with Filippo's musl-cross:

https://words.filippo.io/easy-windows-and-linux-cross-compil...

I debated doing the pure-Go SQLite thing, but musl-cross worked just fine for me, and kept things simpler.




Cross compiling with zig is so easy. For example I use sqlite in Go projects on arm. The incantation is just:

    export GOARCH=arm64
    export CC=zig cc -target aarch64-linux-musl
    export CXX=zig cc -target aarch64-linux-musl


Cross compilation is always easy when there are no dependencies to the target platform SDKs. When it goes beyond basic libc stuff, then it is when the fun starts.


It seems fairly straightforward - copy over the SDK header files and libraries to the project and then add these envs to the build:

    CC="/path/to/cross/compiler" CGO_CFLAGS=—I/path/to/sdk/header/files/include" CGO_LDFLAGS="-L/path/to/sdk/obj/files/lib”
I suppose with .so files, you might have to specify "-Wl,-rpath" if the SDK libraries don’t reside under /usr/lib or /usr/local/lib on the target system. But I haven’t actually tried any of this yet, so I could be wrong. Are there any gotchas that I’m missing?


Now do the same as Windows UWP SDK, or iOS SDK.

You're missing all the tooling and OS specific steps required to produce a proper package.


For macOS: https://github.com/tpoechtrager/osxcross


Doesn't seem to do IO Kit, DriverKit, Metal, Instruments Plugins, UI frameworks, XPC, and plenty of other stuff dependent on Objective-C/Swift.


I believe it would work for all of that, given that it links to the same libraries an app made with Xcode would.

That repository won't compile Swift, but it does compile objective C.

Either way, you don't need to be able to compile Swift/Obj C to link to a library that was written in Swift/Obj C.


The following post [0] describes how to build static binaries even with cgo enabled:

    GOOS= GOARCH= CGO_ENABLED=1 go build \
      -tags osusergo,netgo,sqlite_omit_load_extension \
      -ldflags="-extldflags=-static"
[0]: https://www.arp242.net/static-go.html


As someone who has had to develop desktop software (ugh) with true cross-platform support for MacOS, Linux, and Windows (thanks Animation and VFX industry) using golang, I can assure everyone that it is not “really easy” to make things like Qt compile for different OSes on different OSes. IIRC trying to build for M1 Mac on AMD64 Windows was the worst.


Is there something like this for cross-compiling to FreeBSD?


You can check how ClickHouse is cross-compiled for FreeBSD.

1. https://github.com/ClickHouse/sysroot/

2. https://github.com/ClickHouse/ClickHouse/blob/master/cmake/f... and the `CMAKE_TOOLCHAIN_FILE` variable.


As someone who has had to develop desktop software (ugh) with true cross-platform support for MacOS, Linux, and Windows (thanks Animation and VFX industry) using golang, I can assure everyone that it is not “really easy” to make things like Qt cross-compile with golang. IIRC building for Mac on Windows was the worst.


Not really, unless you're talking about specific Go developers, and even there, that is what the CI/CD pipeline is for.

No one should touch servers directly, unless for down tracking stuff or remote development, in which case, they also don't need to cross compile.


Pretty sure lots of people still touch servers directly, and will continue to until servers are no longer a thing.


Sure, but then DevOps aren't doing their jobs.

No devs on production servers unless for tracking down issues, or servers configured for remote development.

Which in both cases, don't require cross compilation to start with.


There are less and less touching servers directly happening. Not only DevOps but the current raise of k8s and serverless deployments making it less relevant. There is also the security aspect of it.

The downside is that people (especially the ones who are just joining the workforce) are less efficient with the command line and more dependant on GUI. For example some of the junior devs do not know git cli anymore and rely on the VSCode plugin to interact with git. This becomes an issue when there is a bug in the plugin and you should use the CLI.


That is easy to sort out, like every git problem, clone the repo and start again.

I know SCM tooling since the RCS days, and couldn't be bothered to master git implementation details to fix broken repos.

Unfortunely we are stuck with git for the time being.


I agree with you based the amount of time someone needs to spend to fix a broken repo.

I just really like to understand the tools that I use. Maybe it is a waste of time.


Or worse, when what you think is a big actually is a feature. I basically use vscode git only for staging and merging and sometimes not even that, when it has issues with hunks on the beginning of the file or whatever.


Yes, we're shelling into k8s containers now


This comment leads me to believe that you’re used to working in one type of organisation to the point where you’re projecting it on your entire understanding of this incredibly broad industry.


Indeed, Fortune 500 consulting.


DevOps should IMHO not be a job role but a company philosophy.

The developer should alao maintain their software and deploy it. Has IMHO a lot of advantages


I mostly touch servers remotely


Everyone _should_ also have 100% test coverage, canary deployments, and local dev parity. Unfortunately, the real world gets in the way and means we don’t all work with optimal setups.


In that case, it starts by having a local environment that matches the OS of the servers.

Linux OEM vendors will appreciate it.


You’re running graviton arm locally? It’s all docker containers in the end, so that’s what you get.


No, and why should I?

I got into UNIX development back when the whole team shared a development server and we used telnet and X Windows for our "IDE".

No one was running SPARC, RISC System/6000, PA-RISC, MIPS, Eclipse MV locally.

When everyone keeps worshipping UNIX, maybe it is time to learn how grey beards used to develop for it.


> it starts by having a local environment that matches the OS of the servers

> No, and why should I?

These two statements are in direct conflict. CPU architecture is as much part of “matching the server” as operating system.

When I built software for SPARC, I was also running SPARC locally…


That's how I came up too. It sucked. It's good that it's being forgotten.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: