Sure. I compiled these with gcc. It includes two binaries: cjpegli (encoder) and djpegli (decoder). Download zip via Dropbox. Link will probably expire eventually, when I clean up my files.
Sure. I compiled these with gcc. It includes two binaries: cjpegli (encoder) and djpegli (decoder).
Download zip via Dropbox. Link will probably expire eventually, when I clean up my files.
The customer demands even more static. Alright, I've basically bundled every dependency that your Linux system might not have. Link is updated again. If this doesn't work, I claim ignorance of...
The customer demands even more static. Alright, I've basically bundled every dependency that your Linux system might not have. Link is updated again.
If this doesn't work, I claim ignorance of using cmake as a pitiful web dev.
It may honestly be easier to build yourself, as it'll use your systems libraries. In this case, I think my C++ runtime was too new for your system. Nonetheless, one more for the road? Link is...
It may honestly be easier to build yourself, as it'll use your systems libraries. In this case, I think my C++ runtime was too new for your system.
Nonetheless, one more for the road? Link is updated...
I'm pretty confused, because libc should be included in basically every Linux distro. I can only guess that it's running in an extremely locked down environment like Docker, or a bare bones Linux...
I'm pretty confused, because libc should be included in basically every Linux distro. I can only guess that it's running in an extremely locked down environment like Docker, or a bare bones Linux distro designed for IoT or something.
In any case, I'm sorry I couldn't be of more help. Best of luck in finding an alternative solution.
It is included in every distro, but you two have different versions based on which OS you're running. It could be that one of you is very out-of-date, or just that one distro is a bit behind....
It is included in every distro, but you two have different versions based on which OS you're running. It could be that one of you is very out-of-date, or just that one distro is a bit behind. Since yours was linked against one version and OP has a different one on their system, it's failing to link properly. This is one of the reasons containerization has gotten so popular.
Also, a .so file is a shared object file (a .dll in Windows) which is dynamically linked. A .a file is a statically linked library (I don't remember what windows calls their static libraries? .lib or something?)
I'm on a rolling release, so probably too recent. It seems like glibc can be statically linked, but it's highly discouraged on Linux. I guess the solution is to simply build from an older system...
I'm on a rolling release, so probably too recent.
It seems like glibc can be statically linked, but it's highly discouraged on Linux. I guess the solution is to simply build from an older system for wider compatibility.
Sharing libraries may once have made sense for saving disk space, but fully packaging and containerizing tools definitely seems like the way forward.
So what I like to do when trying to build a project is poke around their .github/workflows if they have any. In this case, it looks like they have the build process documented in release.yaml....
So what I like to do when trying to build a project is poke around their .github/workflows if they have any. In this case, it looks like they have the build process documented in release.yaml. Edit: I like to reference the workflows directly because sometimes the written docs aren't up to date with the actual build process. (edit edit: whoops, linked to build_test, not release, fixed)
If you need further help distilling this into a local build script, add what platform you're trying to compile for (e.g. distro + version + cpu arch) and one of the other tildren will probably help you before I find the time to take a stab at it.
May I ask if you're trying to link against it for perf reasons, or just to try out the library? If the latter, it looks like someone might've compiled it to wasm here. Can't vouch for it, though,...
May I ask if you're trying to link against it for perf reasons, or just to try out the library? If the latter, it looks like someone might've compiled it to wasm here.
Can't vouch for it, though, so it might steal your photo, download a car, or hack into your mainframes. Please do exercise caution.
https://github.com/google/jpegli/blob/main/BUILDING.md
Just follow these instructions exactly.
Sure. I compiled these with gcc. It includes two binaries:
cjpegli(encoder) anddjpegli(decoder).Download zip via Dropbox. Link will probably expire eventually, when I clean up my files.
Ah, missing library. I'll have to see if I can include that in the build as well. Hang tight.
Okay, I've repackaged it and updated the link above. Give it another try.
The customer demands even more static. Alright, I've basically bundled every dependency that your Linux system might not have. Link is updated again.
If this doesn't work, I claim ignorance of using cmake as a pitiful web dev.
It may honestly be easier to build yourself, as it'll use your systems libraries. In this case, I think my C++ runtime was too new for your system.
Nonetheless, one more for the road? Link is updated...
Gosh, I don't envy C devs.
I'm pretty confused, because libc should be included in basically every Linux distro. I can only guess that it's running in an extremely locked down environment like Docker, or a bare bones Linux distro designed for IoT or something.
In any case, I'm sorry I couldn't be of more help. Best of luck in finding an alternative solution.
It is included in every distro, but you two have different versions based on which OS you're running. It could be that one of you is very out-of-date, or just that one distro is a bit behind. Since yours was linked against one version and OP has a different one on their system, it's failing to link properly. This is one of the reasons containerization has gotten so popular.
Also, a
.sofile is a shared object file (a.dllin Windows) which is dynamically linked. A.afile is a statically linked library (I don't remember what windows calls their static libraries?.libor something?)I'm on a rolling release, so probably too recent.
It seems like glibc can be statically linked, but it's highly discouraged on Linux. I guess the solution is to simply build from an older system for wider compatibility.
Sharing libraries may once have made sense for saving disk space, but fully packaging and containerizing tools definitely seems like the way forward.
This is a great use case for an LLM agent like Claude Code. OpenCode will let you use their LLM a bit for free.
So what I like to do when trying to build a project is poke around their
.github/workflowsif they have any. In this case, it looks like they have the build process documented in release.yaml. Edit: I like to reference the workflows directly because sometimes the written docs aren't up to date with the actual build process. (edit edit: whoops, linked to build_test, not release, fixed)If you need further help distilling this into a local build script, add what platform you're trying to compile for (e.g. distro + version + cpu arch) and one of the other tildren will probably help you before I find the time to take a stab at it.Aaaand they already did.
@Fishtail_Parka
build.sh
Seems to work in my limited testing. Built in ubuntu, ran on arch host.
Edit: There's also instructions for a windows build in release.yaml
May I ask if you're trying to link against it for perf reasons, or just to try out the library? If the latter, it looks like someone might've compiled it to wasm here.
Can't vouch for it, though, so it might steal your photo, download a car, or hack into your mainframes. Please do exercise caution.