Aseprite can't compile
As the title says, I'm unable to compile Aseprite despite following the instructions. When I copy and paste the following:
I get the following error message
Anyone know what this means and the solution to it?
Solution:Jump to solution
could not get it done this way, got an error, something to do with the "---image" part or something, I'll go over how I solved this in 3 easy steps to anyone that is interested in the future:
Step one: open BoxBuddy and create a Box using Arch (I used docker.io/library/...) and create. Call it what you want.
Step two: Install yay to make it easy and to go "yay it installed", plus pacman had it coming :^) Use the following command to make installing yay easy:...
31 Replies
use distrobox
Mind elaborating, how would I go about it?
create a distrobox container, install the packages you need to build this in that container, and then build it in the container
anything else is entirely unsupported and unsupportable
check distrobox's documentation for more info
it would seem I would need the .deb file if using the ubuntu image, but I'm not trying to run the program, trying to compile it
if you're feeling adventurous, give my toolchain a try:
https://github.com/neon-engine/buildroot
its a toolchain i made to support cross-compiling my game engine, a passion project i've been working on for a while
1. clone it and checkout the 2024.02.x branch, and execute
./sdk-tools/build-neon-sdk.sh
2. this will produce a toolchain in /opt/neon-sdk/x86_64-linux/
3. open a terminal, and run source /opt/neon-sdk/x86_64-linux/environment-setup and then try compiling by running your cmake command, no need to specify CC or CXX, the environment-setup file does this already
the toolchain now targets glibc 2.31, so will definitely be compatible with everything debian 11+, and including bazzite and modern distrosGitHub
GitHub - neon-engine/buildroot: Buildroot, making embedded Linux ea...
Buildroot, making embedded Linux easy. Note that this is not the official repository, but only a mirror. The official Git repository is at https://gitlab.com/buildroot.org/buildroot/. Do not open i...
just full disclosure, this will compile everything from scratch (gcc, binutils, etc) but its automated to the point that it cannot fail unless your internet cuts out and something doesn't download quite right, the SDK is not yet finalized or i would just point you to a tarball you can just grab. Otherwise, you can also google for x86_64 toolchains, and just use that.
This is largely inspired by godot's build process, except they delete the environment-setup file that gets generated
this has been the most painless way for me to get a full C++ toolchain without having to jump hoops through distrobox, and i actually just have most of my SDKs under /opt (like dotnet, OpenJDK, and so on) i just edit the PATH variables and other environment variables inside my IDEs to know where to look for the files
Sounds too complicated just to run a simple art programs. Don't really want to jump through all these hoops just to compile a single art program with buildroot and distrobox and the whatnot. Unless there is a clear and simple way for me to build without these hassles, I think I'm good leaving this unsolvable for the average user unless there is a clear step-by-step breakthrough, tbf/tbh.
i think ublue devs removed ld, that's the main issue
and its a layered change
nah it's just broken upstream
yeah, i type which ld, get nothing
ah i see
and it makes no sense to fix it because distrobox is a better solution
and a lack of ld forces users to make that decision
distrobox create --name fedora --image ghcr.io/ublue-os/fedora-distrobox:latest
distrobox enter fedora
you are now in a fedora box, follow build instructions for this application for Fedora
that simplewait... couldn't you just spin up an archbox and grab it from the AUR? lol
yes
or a debian box and install the .deb
all very good solutions
forcing users to do something does not sound right, better to suggest, perhaps with a popup suggesting users use distrobox when building, but forcing users is kinda... :T eh
the warning is ld is broken
the answer is use distrobox
the alternative is users layer build dependencies because they didn't use distrobox
there is no deb, Aseprite can only be compiled, unless you pay them for the .deb
I'd rather ld just never get fixed at all
it's utterly unnecessary
AUR basically compiles it when you grab the non-bin version
^^
distrobox create --name arch ---image ghcr.io/ublue-os/arch-distrobox:latest
distrobox enter arch
paru -S name-of-package
distrobox-export --app name-of-package
donelemme try that, lyk what pops up :v
with KVM technology, its near baremetal performance, you won't notice anything in terms of a performance hit
no KVM here, distrobox isn't a VM
i've used a few GUI apps this way from time to time
not too worried about performance
it is baremetal performance
ah i thought podman ran on KVM
it can, not doing that in this case
i see i see
it's a container on your running kernel
an arch container is ~3MB of ram lol
plus what you run in it
Solution
could not get it done this way, got an error, something to do with the "---image" part or something, I'll go over how I solved this in 3 easy steps to anyone that is interested in the future:
Step one: open BoxBuddy and create a Box using Arch (I used docker.io/library/...) and create. Call it what you want.
Step two: Install yay to make it easy and to go "yay it installed", plus pacman had it coming :^) Use the following command to make installing yay easy:
sudo pacman -S --needed git base-devel && git clone https://aur.archlinux.org/yay.git && cd yay && makepkg -si
Step three: Install aseprite, simply just type yay -Syu Asperite and proceed with the installation. After that, good to go. Can do distrobox-export --app aseprite to make it show up as a icon on your computer so you dont have to open the terminal or BoxBuddy again.