# binaries Published articles for binaries. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Codename One Compiles Java and Kotlin Apps to Native Windows Executables Without a JVM DevFeed: [Codename One Compiles Java and Kotlin Apps to Native Windows Executables Without a JVM]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-06-15T00:00:00Z Content type: article Language: en Sources: [CodeName One]() Topics: [Java](), [Windows](), [win32](), [Arm]() Tags: [binaries](), [compilation](), [desktop](), [java](), [native](), [win32](), [windows]() ### AI overview Codename One's new Windows port uses the ParparVM pipeline to compile Java and Kotlin bytecode into standalone native Win32 executables without bundling or installing a JVM. The build targets both x64 and arm64 Windows systems. ### Source excerpt The new native Windows port compiles your Java to a standalone Win32 executable through ParparVM, Direct2D, and DirectWrite. No JVM, no bundled runtime, a 5MB hello world, and both x64 and arm64 from one build. ## The Road to Component Model 1.0 DevFeed: [The Road to Component Model 1.0]() Original publisher: [Read original article]() Author: Eric Gregory Published: 2026-06-08T00:00:00Z Content type: article Language: en Sources: [Bytecode Alliance]() Topics: [WebAssembly](), [wasm](), [browser]() Tags: [apis](), [architecture](), [async](), [binaries](), [browser](), [compatibility](), [interfaces](), [polyfill](), [production](), [wasi](), [wasm](), [webassembly]() ### AI overview This article explains the path toward a stable, formally specified WebAssembly Component Model 1.0. It reviews how the Component Model and WASI relate, describes the Component Model as a foundational layer with WASI providing system-resource interfaces, and notes that both are already used in production while their specifications continue to evolve. ### Source excerpt WASI P3 is almost here, bringing native async support to the WebAssembly System Interface (WASI) and Component Model. In this post, we're looking to the next big milestone: a stable, formally specified Component Model 1.0. At February's Bytecode Alliance Plumbers Summit, Luke Wagner and Alex Crichton gave a preview of what the path to a stable 1.0 actually looks like. At Wasm I/O 2026 in Barcelona in March, Luke expanded on that vision. So let's take a look at where the Component Model is heading. ## wastrel milestone: full hoot support, with generational gc as a treat DevFeed: [wastrel milestone: full hoot support, with generational gc as a treat]() Original publisher: [Read original article]() Author: Andy Wingo Published: 2026-04-09T13:48:04Z Content type: article Language: en Sources: [wingolog]() Topics: [WebAssembly](), [scheme](), [toolchain](), [gcc]() Tags: [binaries](), [garbage-collection](), [gc](), [gcc](), [hoot](), [optimization](), [repl](), [scheme](), [spidermonkey](), [toolchain](), [treats](), [v8](), [wasm](), [wastrel](), [web](), [webassembly]() ### AI overview The article describes a Wastrel milestone: compiling WebAssembly files produced by the Hoot Scheme toolchain into native binaries, including a console-based read-eval-print loop. It covers the build process, runtime modules, binary size, dependencies, and initial performance observations. ### Source excerpt Hear ye, hear ye: Wastrel and Hoot means REPL! Which is to say, Wastrel can now make native binaries out of WebAssembly files as produced by the Hoot Scheme toolchain, up to and including a full read-eval-print loop. Like the REPL on the Hoot web page, but instead of requiring a browser, you can just run it on your console. Amazing stuff! try it at home First, we need the latest Hoot. Build it from source, then compile a simple REPL: echo '(import (hoot repl)) (spawn-repl)' > repl.scm ./pre-inst-env hoot compile -fruntime-modules -o repl.wasm repl.scm This takes about a minute. The resulting wasm file has a pretty full standard library including a full macro expander and evaluator. Normally Hoot would do some aggressive tree-shaking to discard any definitions not used by the program, but with a REPL we don't know what we might need. So, we pass -fruntime-modules to instruct Hoot to record all modules and their bindings in a central registry, so they can be looked up at run-time. This results in a 6.6 MB Wasm file; with tree-shaking we would have been at 1.2 MB. Next, build Wastrel from source, and compile our new repl.wasm: wastrel compile -o repl repl.wasm This takes about 5 minutes on my machine: about 3 minutes to generate all the C, about 6.6MLOC all in all, split into a couple hundred files of about 30KLOC each, and then 2 minutes to compile with GCC and link-time optimization (parallelised over 32 cores in my case). I have some ideas to golf the first part down a bit, but the the GCC side will resist improvements. Finally, the moment of truth: $ ./repl Hoot 0.8.0 Enter `,help' for help. (hoot user)> "hello, world!" => "hello, world!" (hoot user)> statics When I first got the REPL working last week, I gasped out loud: it's alive, it's alive!!! Now that some days have passed, I am finally able to look a bit more dispassionately at where we're at. Firstly, let's look at the compiled binary itself. By default, Wastrel passes the -g flag to GCC, which results in bi ## Why building from source matters DevFeed: [Why building from source matters]() Original publisher: [Read original article]() Published: 2025-11-13T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard](), [open-source-security](), [Security](), [Open Source](), [Software](), [Library](), [Compiler](), [virtual machines]() Tags: [binaries](), [building](), [building-from-source-approach](), [chainguard](), [chainguard-containers](), [chainguard-libraries](), [chainguard-open-source](), [chainguard-os](), [chainguard-vms](), [dependency](), [engineering](), [open-source](), [sealed](), [security](), [signing](), [source](), [supply-chain](), [trust]() ### AI overview Chainguard explains why building software from upstream source code can improve control and traceability in software supply chains. The article describes compiling packages and dependencies in a hermetic, network-isolated environment, then signing and attesting the resulting artifacts. ### Source excerpt Chainguard SVP of Engineering Dustin Kirkland discusses why Chainguard builds every package, library, and image directly from source and why the approach works. ## Understanding Apple Debug Info DevFeed: [Understanding Apple Debug Info]() Original publisher: [Read original article]() Author: Keith Smiley Published: 2025-09-21T17:00:00Z Content type: tutorial Language: en Sources: [Keith Smiley]() Topics: [debugging](), [Xcode](), [C](), [Linux]() Tags: [apple](), [binaries](), [build](), [c](), [clang](), [compiler](), [debug](), [debugging](), [ios](), [llvm](), [macos](), [xcode]() ### AI overview This article explains how debug information works for Apple platforms and Mach-O binaries, contrasting the approach with Linux ELF binaries. It shows how compiler-generated debug metadata is stored in intermediate object files and located by lldb, then introduces issues that can arise in complex or distributed Bazel builds, including invalid absolute paths. ### Source excerpt Apple platforms (macOS, iOS, etc), and specifically Mach-O binaries, have a slightly different approach to debug info than ELF binaries for Linux. If you are familiar with Xcode, you might have seen a few related settings that control what is produced and wondered what the trade-offs are. The goal of this post is to help you debug cases where these differences lead to a degraded debugging experience in lldb so that you can fix them. If you have a particularly complex build, potentially managed by Bazel1 or another tool, especially if you are using distributed builds, you are even more likely to hit issues. Let's dive in to how the pieces fit together. A brief explanation of debug info Debug info is metadata produced by the compiler that is consumed by debuggers (like lldb), profilers, and other tools. It is used to map runtime information, like addresses, function arguments, and stack traces, back to the source that was used to produce the binary. Without this information debugging in lldb shows primarily raw instructions and addresses, which is rarely acceptable for common debugging workflows. Inspecting debug info When building for Apple platforms debug info isn't contained in the final binary (this is the primary difference from the default Linux workflows). Instead the binary contains references to the files where lldb can find it (this is conceptually similar to if you use -gsplit-dwarf on Linux). Let's inspect some binaries to see what this really means. First we create a small binary: $ cat main.c int main() { return 0; } $ clang main.c -g -c -o main.o $ clang main.o -o main If we attempt to inspect the debug info contained in main, we find nothing: $ dwarfdump main # use llvm-dwarfdump if not on macOS main: file format Mach-O arm64 .debug_info contents: However when we debug this binary in lldb, you will correctly see the source file and line number information: $ lldb -- main (lldb) target create "main" Current executable set to '/tmp/demo/main' (arm64). (l ## Building GoReleaser: from shell script to paid product DevFeed: [Building GoReleaser: from shell script to paid product]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2025-07-19T00:00:00Z Content type: article Language: en Sources: [Carlos Becker]() Topics: [Automation](), [Go Language](), [YAML](), [GitHub](), [Open Source](), [Homebrew](), [API]() Tags: [api](), [automation](), [binaries](), [building](), [github](), [go](), [homebrew](), [open-source](), [shell-script]() ### AI overview The article recounts the history of GoReleaser, a YAML-configured release automation tool that builds binaries, creates archives and packages, publishes releases, pushes installers, and signs artifacts. It describes the tool's evolution from a shell script into a Go project and its early adoption by open-source developers. ### Source excerpt In this post, I want to share the history behind GoReleaser, how we got here, lessons I've learned along the way, and what's ahead. ## How to use a project-specific Maven repository when dependency downloads fail DevFeed: [How to use a project-specific Maven repository when dependency downloads fail]() Original publisher: [Read original article]() Author: Marco Gomiero Published: 2025-01-05T00:00:00Z Content type: tutorial Language: en Sources: [Posts on Marco Gomiero]() Topics: [Maven](), [ci](), [Gradle]() Tags: [binaries](), [build](), [ci](), [dependencies](), [dependency](), [gradle](), [incident](), [maven]() ### AI overview This tutorial explains how to keep a project building when a Maven repository is unavailable or a dependency can no longer be downloaded. It shows how to create a project-specific local Maven repository, recover the dependency binary from the Gradle cache when available, and configure Gradle to use the local repository for that library. ### Source excerpt As developers, we've all encountered build failures in CI (or on our local machines) due to Maven repository issues preventing dependency downloads. > Could not download foo-lib-1.0.aar (org.acme.foo:foo-lib:1.0) > Could not get resource 'https://mavenrepo.com/org/acme/foo/foo-lib/1.0/foo-lib-1.0.aar'. > Could not GET 'https://mavenrepo.com/org/acme/foo/foo-lib/1.0/foo-lib-1.0.aar'. Received status code 403 from server: There could be many reasons for this: the Maven repository is currently down or is having an incident, the repository has been shut down (hello, JCenter), and the dependency is old and not republished elsewhere. ## KMMBridge 1.0 Release - Kevin Galligan DevFeed: [KMMBridge 1.0 Release - Kevin Galligan]() Original publisher: [Read original article]() Published: 2024-08-28T00:00:00Z Content type: release Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [swift-package-manager](), [Tool](), [Mobile](), [Framework]() Tags: [binaries](), [cocoapods](), [configuration](), [dependencies](), [ios](), [kmmbridge](), [kotlin](), [kotlin-multiplatform](), [release](), [spm](), [swift](), [tool](), [xcode]() ### AI overview KMMBridge 1.0.0 simplifies publishing Kotlin Multiplatform XCFramework binaries for iOS, with a primary focus on Swift Package Manager. CocoaPods remains supported, while the templates and tutorials are SPM-only. ### Source excerpt KMMBridge is a tool that helps you publish iOS XCFramework binaries from Kotlin Mutliplatform. The tool has seen multiple iterations over the past few years. This version simplifies the configuration and usage of KMMBridge, with a primary focus on Swift Package Manager (SPM). ## How to switch between multiple ESP32 firmware binaries stored in the flash memory DevFeed: [How to switch between multiple ESP32 firmware binaries stored in the flash memory]() Original publisher: [Read original article]() Author: John Lee Published: 2024-07-24T00:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [ESP32](), [Microcontroller](), [Embedded Software Dev](), [Internet of things](), [ESP32-S3](), [m5stack](), [Wokwi]() Tags: [binaries](), [blog](), [boot](), [bootloader](), [bsp](), [build](), [code](), [embedded](), [embedded-systems](), [esp32](), [esp32-p4](), [esp32-s3](), [espressif](), [firmware](), [flash](), [gui](), [how-to](), [iot](), [m5stack](), [memory](), [ota](), [partition](), [quick-start](), [releases](), [simulation](), [wokwi]() ### AI overview A tutorial on using the ESP32 Graphical Bootloader to store multiple firmware images in flash memory and switch between them. It explains the bootloader flow, partition-table configuration, and steps for building, merging, flashing, and simulating the application. ### Source excerpt Introduction# The ESP32 microcontroller is a versatile and powerful device, widely used in IoT and embedded applications. One of its advanced features is the ability to store multiple firmware images in its flash memory and switch between them. This capability can be leveraged for various purposes, such as testing different firmware versions, running multiple applications, or maintaining a backup firmware. ## Teleport Community Edition will adopt a commercial license starting with version 16 DevFeed: [Teleport Community Edition will adopt a commercial license starting with version 16]() Original publisher: [Read original article]() Author: sasha@goteleport.com (Alexander Klizhentas) Published: 2024-03-08T00:00:00Z Content type: article Language: en Sources: [Teleport]() Topics: [Software](), [Open Source](), [releases]() Tags: [amazon](), [binaries](), [container-images](), [open-source](), [release](), [releases](), [software-license]() ### AI overview Teleport Community Edition will move compiled binaries, container images, and Amazon Machine Images from the Apache 2.0 license to a commercial license starting with version 16. Personal and hobby use remains unrestricted, while larger companies must contact sales. The source repository remains under AGPLv3, and pre-version-16 assets retain Apache 2.0 licensing. ### Source excerpt A detailed explanation, schedule, and FAQ on why we have switched Teleport Community Edition to a commercial software license. ## Building a macOS screen saver in Kotlin DevFeed: [Building a macOS screen saver in Kotlin]() Original publisher: [Read original article]() Author: Márton Braun Published: 2024-03-05T12:00:00Z Content type: tutorial Language: en Sources: [zsmb.co]() Topics: [kotlin-multiplatform-libraries](), [Kotlin Multiplatform](), [macOS](), [multiplatform](), [interoperability](), [Code](), [GitHub]() Tags: [android](), [binaries](), [build](), [code](), [contributions](), [development](), [github](), [installation](), [interoperability](), [kotlin](), [kotlin-multiplatform](), [macos](), [marton-braun](), [multiplatform](), [zsmb](), [zsmb-co](), [zsmb13](), [zsmbco]() ### AI overview This tutorial documents the creation of a custom macOS screen saver built almost entirely in Kotlin with Kotlin Multiplatform. It covers customization options, release binaries, installation, and the challenges of working with macOS screen saver APIs and interoperability. ### Source excerpt This article documents how I created my own custom screen saver for macOS, built almost entirely in Kotlin, using the powers of Kotlin Multiplatform compiled to macOS. Join me for a tale of Kotlin success and macOS failures. ## Teleport OSS will relicense to AGPLv3 DevFeed: [Teleport OSS will relicense to AGPLv3]() Original publisher: [Read original article]() Author: sasha@goteleport.com (Alexander Klizhentas) Published: 2023-12-01T00:00:00Z Content type: release Language: en Sources: [Teleport]() Topics: [Open Source](), [Software](), [Code](), [client library]() Tags: [apache](), [binaries](), [change](), [client-library](), [container](), [open-source](), [oss](), [software](), [software-license]() ### AI overview Teleport announced that its core repository source code would switch from the Apache 2.0 license to AGPLv3 on December 1, 2023. Documentation, company-compiled OSS binaries, and client libraries would remain under Apache 2.0, while enterprise binaries would continue under a commercial license. ### Source excerpt A detailed explanation, schedule, and FAQ on why we have switched Teleport OSS to AGPLv3 software license. ## KMP Team Workflows with KMMBridge - Kevin Galligan DevFeed: [KMP Team Workflows with KMMBridge - Kevin Galligan]() Original publisher: [Read original article]() Published: 2023-10-06T10:00:28Z Content type: tutorial Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Kotlin Multiplatform](), [kotlin-multiplatform-libraries](), [Tooling](), [Xcode](), [cocoapods](), [SDKs](), [Template](), [Android](), [iOS]() Tags: [android](), [binaries](), [build](), [cocoapods](), [ios](), [kmp](), [kotlin](), [kotlin-multiplatform](), [libraries](), [project](), [sdk](), [xcode]() ### AI overview This article explains how KMMBridge supports Kotlin Multiplatform team workflows by assembling and publishing Xcode Framework binaries for distribution through Swift Package Manager, CocoaPods, or private repositories. It also introduces a Quick Start template for publishing Android and iOS binaries. ### Source excerpt Team workflows with Kotlin Multiplatform vary in structure. KMMBridge is a tool that allows you to publish Xcode Framework binaries from Kotlin that can be distributed, for your team internally, or to outside developers. ## Run My Code! (code injection on Windows) DevFeed: [Run My Code! (code injection on Windows)]() Original publisher: [Read original article]() Author: Tim Misiak Published: 2023-08-27T22:13:28Z Content type: tutorial Language: en Sources: [TimDbg]() Topics: [Code](), [Processes](), [Windows](), [Programming]() Tags: [binaries](), [buffer-overflow](), [code](), [processes](), [programming](), [windbg](), [windows]() ### AI overview This article explains code injection on Windows, focusing on ways to run code inside another process without relying on a security vulnerability. It introduces static injection through patching, DLL injection, and dynamic code injection, and discusses drawbacks of modifying binaries on disk, including effects on repeated runs and code signing. ### Source excerpt The first time I realized it was possible to get a process to run some extra little code I had written, it felt like the ultimate cheat code. My first attempt was a little patch for Civilization 2 to fix some high CPU usage. Then I discovered that you could inject code at run-time. And when I discovered the ability to change how OS functions worked, it started to feel like I could do anything! ## Fully bootstrapping Go from source in Wolfi DevFeed: [Fully bootstrapping Go from source in Wolfi]() Original publisher: [Read original article]() Published: 2023-08-11T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [Go](), [Go Language](), [Compiler](), [toolchain](), [gcc](), [C++](), [backdoor]() Tags: [backdoor](), [binaries](), [bootstrapping](), [c-plus-plus](), [gcc](), [go](), [provenance](), [source](), [supply-chain](), [toolchain](), [wolfi]() ### AI overview The article explains how to fully bootstrap Go from source in Wolfi to improve provenance and reduce trust risks associated with pre-built binaries. It describes using the C++-based gcc-go or gollvm implementations to build the official Go toolchain without requiring an existing Go compiler. ### Source excerpt Dive into fully bootstrapping Go from source in Wolfi, paving the way for secure, independent development. ## Installing Age Encryption Tool DevFeed: [Installing Age Encryption Tool]() Original publisher: [Read original article]() Author: Techno Tim Published: 2023-01-30T15:00:00Z Content type: tutorial Language: en Sources: [Techno Tim]() Topics: [Encryption](), [Tutorial](), [Open Source](), [GitHub]() Tags: [binaries](), [download](), [encryption](), [github](), [library](), [open-source](), [tutorial](), [utilities]() ### AI overview A tutorial for installing age, a modern file-encryption tool, format, and Go library. It describes downloading the latest release, extracting and moving the binaries, testing the installation, and uninstalling it. ### Source excerpt What is Age? age is a simple, modern and secure file encryption tool, format, and Go library. It features small explicit keys, no config options, and UNIX-style composability.It is commonly used in tandem with Mozilla SOPS.It's open source and you can read more about it on the GitHub repo. Looking for a tutorial on how use this? Checkout this video on how to use SOPS and Age for your Git Repo... ## Introducing KMMBridge for Teams DevFeed: [Introducing KMMBridge for Teams]() Original publisher: [Read original article]() Author: Kevin Galligan Published: 2022-10-10T20:10:44Z Content type: release Language: en Sources: [Stories by Kevin Galligan on Medium]() Topics: [Kotlin Multiplatform](), [Mobile](), [Gradle](), [SDKs](), [Tooling](), [Xcode]() Tags: [binaries](), [build-tools](), [gradle](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [mobile](), [sdk](), [xcode]() ### AI overview Touchlab announces KMMBridge, part of its Faktory tooling suite, to help mobile teams publish and consume pre-built Kotlin Multiplatform Mobile Xcode Framework binaries as an internal SDK. The article explains the Internal SDK Flow, in which a team member or CI builds and publishes the framework so iOS developers can integrate it without building Kotlin locally. ### Source excerpt Today we are announcing KMMBridge, part of Touchlab's new Faktory* tooling suite. This set of build tools allows mobile teams to successfully publish shared code faster than ever with Kotlin Multiplatform Mobile. Specifically targeted at iOS publishing, teams can now implement the Internal SDK Flow approach, today's best practice to quickly integrate KMM into production app builds. GitHub - touchlab/KMMBridge: KMMBridge is a set of Gradle tooling that facilitates publishing and consuming pre-built KMM (Kotlin Multiplatform Mobile) Xcode Framework binaries. See https://touchlab.github.io/KMMBridge/intro/ to get started. KMMBridge allows teams to publish and integrate Kotlin Multiplatform Mobile (KMM) Xcode Frameworks as an internal SDK.When you're ready to get started, head to our KMMBridge Quick Start Tutorial.Why We Built a Team-Focused Tool Touchlab has spent years working with teams at different stages of their Kotlin Multiplatform journey. Evaluating KMP, putting KMP into production, and yes, even a fair bit of time talking to teams who looked at KMP and decided against it. One of the key lessons we've learned seems obvious in retrospect. Different types of teams work in different ways. Of course, every team is different. Every situation will be different. However, there are common patterns. Out of the box, the KMP and the Kotlin/Native toolkit will let you build an Xcode Framework, then integrate it locally into your Xcode project. This works well if everybody on the team builds Kotlin. And in an ideal world, everybody would be able to build Kotlin. But in the real world, most teams who have succeeded followed the Internal SDK Flow approach. The Internal SDK Flow Approach As with adopting any technology on a team, early wins help build momentum and confidence so the team can unlock the full potential over time. The Internal SDK Flow has emerged as the best practice to get faster ROI when adopting KMM. At its simplest, this approach means the Kotlin Xcode Framew ## Symbol and Binary Indexing DevFeed: [Symbol and Binary Indexing]() Original publisher: [Read original article]() Author: Tim Misiak Published: 2022-08-10T15:30:09Z Content type: tutorial Language: en Sources: [TimDbg]() Topics: [debugging](), [Windows](), [Visual Studio]() Tags: [binaries](), [debug](), [debugger](), [debugging](), [files](), [symbols](), [windbg](), [windows]() ### AI overview This article explains why WinDbg debugging benefits from indexing both symbols and binaries. Symbols provide names, type definitions, and source files, while indexed binaries help debuggers reconstruct missing module data and perform reliable stack walking, especially when analyzing crash dumps from another machine. ### Source excerpt Symbol indexing is one of those features of WinDbg that can make things "just work" in a way that seems like magic. But it can also be the most painful things when it goes wrong. Why should I index symbols and binaries? Most of us have tried to debug without symbols at one point, and it can quickly become an exercise in frustration. It's much more productive to debug an executable where you have symbols because it gives you function names, variable names, type definitions, and source files. ## Remote debugging DevFeed: [Remote debugging]() Original publisher: [Read original article]() Author: Tim Misiak Published: 2022-08-05T14:00:00Z Content type: tutorial Language: en Sources: [TimDbg]() Topics: [debugging](), [Development](), [Tooling](), [Server](), [Kernel]() Tags: [binaries](), [debugger](), [debugging](), [development](), [exceptions](), [how-to](), [kernel](), [os](), [remote](), [server](), [symbols](), [windbg]() ### AI overview This tutorial explains how to set up remote debugging with WinDbg and NTSD. It defines target and host terminology, compares NTSD/CDB with DbgSrv, and explains how debugger logic, binaries, symbols, memory, registers, and debugging events are distributed between machines. ### Source excerpt A key feature of WinDbg and NTSD is the ability to debug a target "remotely" from a separate computer. For kernel debugging, this is often the only way to debug, since the entire OS is "frozen" when broken into a kernel debugger. Remote debugging is also available for usermode debugging, and is often just as useful. Sometimes it's useful because the target that you are testing on is different from the one you are using for development. ## New Red binaries DevFeed: [New Red binaries]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2022-07-29T16:18:00Z Content type: release Language: en Sources: [Red]() Topics: [Red](), [toolchain](), [Command-line interface](), [GUI](), [Compiler](), [releases]() Tags: [availability](), [binaries](), [cli](), [compiler](), [console](), [download](), [gui](), [releases]() ### AI overview Red introduces separate pre-built binaries for its GUI console, CLI console, and toolchain to reduce first-use delays. The project is temporarily dropping semantic versioning before version 1.0 and will primarily provide binaries for the latest commit. ### Source excerpt Since many years, we are offering pre-built binaries for the Red toolchain, as a more convenient way to use Red, even if it is not strictly needed, as Red can be run from its sources, the toolchain being run by a Rebol2 interpreter. As the Red REPL and toolchain are not run by the same engine, the console (REPL) used to be compiled on first run of the `red` executable (when no arguments was provided or a Red script was passed). This resulted in a significant delay on the first use of the console (both for the GUI and CLI versions). We have now decided to change that by providing separate pre-built binaries for the consoles and toolchain. This is a temporary split until Red gets self-hosted, at which point we can recombine everything into a single binary. Another change is the temporary dropping of the semantic versioning until version 1.0 and related "stable" releases, as it seems to be too confusing to some users (Red being still in alpha stage). This also will remove a tendency from some users to care more about version increments than feature availability and work being done overall. We will now be proposing only pre-built binaries for latest commit, though older binaries will still be available if that can be of any help to anyone. So the pre-built binaries now are: Red GUI : Red interpreter + View + GUI console Red CLI : Red interpreter + CLI console Red Toolchain : Encapper for Red + Red/System compiler We are also considering ways to merge the GUI and CLI consoles into a single binary which can work even if no GUI API is available, falling back on CLI mode. We will also have the console(s) act as a front-end for the toolchain, even downloading it for you in the background when needed. Though for that we need a proper asynchronous `call` function implementation. More news about this soon. In the meantime, enjoy running Red consoles almost instantly from just a click on the Download page! ## Printing rpaths with objdump DevFeed: [Printing rpaths with objdump]() Original publisher: [Read original article]() Author: Keith Smiley Published: 2022-03-16T17:00:00Z Content type: tutorial Language: en Sources: [Keith Smiley]() Topics: [LLVM](), [macOS](), [Xcode](), [Swift](), [debugging](), [Tooling]() Tags: [binaries](), [commands](), [debugging](), [llvm](), [macos](), [swift](), [xcode]() ### AI overview The article explains how to inspect runtime library search paths in Mach-O binaries. It compares a verbose otool pipeline with the more concise LLVM objdump --macho --rpaths command, introduced with LLVM 13 and Xcode 13.3 on macOS. ### Source excerpt MachO binaries contain load commands to indicate to dyld where it should search for the libraries the binary depends on. These paths are often useful to inspect when debugging why your binary isn't discovering the libraries you'd expect. Previously you could discover these with: % otool -l `xcrun -f swiftc` \ | grep -A2 LC_RPATH \ | grep "^\s*path" \ | cut -d " " -f 11 @executable_path/../lib/swift/macosx @executable_path/../lib/swift/macosx This example is quite verbose and fragile for such a common action, so recently I committed a change to add an easier option with LLVM's objdump. This change shipped with LLVM 13 or Xcode 13.3 on macOS, allowing you to run: % objdump --macho --rpaths `xcrun -f swiftc` /Applications/Xcode-13.3.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc: @executable_path/../lib/swift/macosx This is much more succinct and memorable, but also has slightly different output. This is because objdump automatically detects the current machine's architecture, and only prints the rpaths for that slice of the fat binary. It also outputs the path of the binary being run on, which you can disable with --no-leading-headers. Hopefully you find this as useful as I do! ## Building static Rust binaries for Linux DevFeed: [Building static Rust binaries for Linux]() Original publisher: [Read original article]() Author: Harsh Shandilya Published: 2021-10-17T06:30:00Z Content type: tutorial Language: en Sources: [Posts on Harsh Shandilya]() Topics: [Rust](), [Linux]() Tags: [binaries](), [building](), [curl](), [dependencies](), [linux](), [openssl](), [rust](), [rust-build-static-binary](), [rust-static-binary](), [rust-static-linking](), [static](), [wasm]() ### AI overview A tutorial on building statically linked Rust binaries for Linux. It explains static linking with MUSL and glibc, describes a Cargo-related issue, and shows how to identify and remove dependencies that require dynamic linking. ### Source excerpt Some tips on building static binaries of Rust projects targeting Linux ## Reproducible codesigning on Apple Silicon DevFeed: [Reproducible codesigning on Apple Silicon]() Original publisher: [Read original article]() Author: Keith Smiley Published: 2021-10-06T03:00:00Z Content type: article Language: en Sources: [Keith Smiley]() Topics: [Arm](), [x86](), [C](), [Command-line interface](), [toolchain](), [Open Source]() Tags: [apple](), [architecture](), [arm](), [binaries](), [c](), [clang](), [code](), [command-line](), [identifier](), [open-source](), [reproducible-builds](), [signing](), [source](), [x86]() ### AI overview The article explains why codesigning universal macOS binaries can produce different results on Apple Silicon and Intel Macs, despite the binaries being identical before signing. It traces the issue through Apple's open-source code and identifies architecture-dependent UUID handling as the cause of non-reproducible codesigning. ### Source excerpt For people who expect reproducible builds, Apple Silicon machines provide an interesting challenge. Apple Silicon requires arm64 binaries, including command line tools you build yourself, be codesigned. This change is mostly transparent to developers, because Apple updated their linker to automatically ad-hoc sign binaries1. Unfortunately, if you're interested in producing binaries that support both Intel Macs and Apple Silicon Macs, you likely want to produce a fat binary. When codesigning this binary you hit some behavior that depends on your current machine's architecture. Example You can consistently produce the same result across multiple machines when compiling a binary without signing it. Here's an example with a simple C program: $ echo "int main() { return 0; }" > main.c $ clang main.c -Wl,-no_adhoc_codesign -arch arm64 -arch x86_64 -o main $ shasum main 113033b3d9a247210b49a476bbfadb2e347846fe main The shasum of main should always be the same regardless of your host machine2. On Apple Silicon machines you can see this binary has the same sha1 even if you run clang under Rosetta 23: $ arch -x86_64 clang main.c -Wl,-no_adhoc_codesign -arch arm64 -arch x86_64 -o main $ shasum main 113033b3d9a247210b49a476bbfadb2e347846fe main The issue is introduced when you codesign the binary on Apple Silicon machines versus Intel machines. You can immediately see the difference3: $ codesign --force --sign - main $ shasum main 84631e812bd480c306766ba03a728dd2565dd672 main % arch -x86_64 codesign --force --sign - main % shasum main f631b6c0daf3ffd0bb5f65d19fa045acf447a72d main We get closer to identifying the problem when you compare the details of these differences: $ codesign --force --sign - main $ codesign -dvvv main > arm.txt 2>&1 $ arch -x86_64 codesign --force --sign - main $ codesign -dvvv main > intel.txt 2>&1 $ diff -Nur intel.txt arm.txt --- intel.txt 2021-10-05 21:26:32.731918710 -0700 +++ arm.txt 2021-10-05 21:26:29.473702845 -0700 @@ -1,14 +1,14 @@ Executable=/ ## Using the new prebuilt builder on GoReleaser DevFeed: [Using the new prebuilt builder on GoReleaser]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2021-09-12T00:00:00Z Content type: tutorial Language: en Sources: [Carlos Becker]() Topics: [import](), [builds]() Tags: [binaries](), [build](), [import](), [performance](), [split]() ### AI overview GoReleaser adds support for importing pre-built binaries into its release process. The article explains using another build tool and splitting builds across multiple machines, including for performance or CGO-related reasons. ### Source excerpt You can now import pre-built binaries into GoReleaser! [Next page]()