Hello,
I notice that there is no caddy_2.0.0_linux_armv5.tar.gz in official distributions. Is it possible to add caddy_2.0.0_linux_armv5.tar.gz to official distributions?
Thanks a lot.
I'm not sure it's likely we'll add support for older architectures than we already have. You can build it from source quite easily yourself though, just follow the instructions in the README!
You might run into some issues on armv5, see https://github.com/golang/go/wiki/GoArm#lack-of-floating-point-hardware-on-armv5 but you might also not have any problems!
@JACK-THINK what's your use-case for armv5? What sort of device are you running?
@hairyhenderson @francislavoie
Thanks for your reply.
I want to deploy caddy on router ASUS RT-AC68U and RT-AX89X. And a lot of device with ARMv7 CPU which has no VFP1 floating point are only capable to execute Go binaries built for ARMv5.
That's a cool use case @JACK-THINK. It seems a bit niche. Does this solution work for you: https://github.com/caddyserver/xcaddy/issues/11#issuecomment-624201069 ?
I'm not opposed to adding ARMv5 builds, but first I want to make sure it'll be used by more than 1 person :)
From the reaction on the original issue description it seems that @ubergesundheit is also interested in this, so there's a potential second person 馃槈
@mholt
Thanks for your solution, I just tried xcaddy, and it gave me a caddy binary for ARMv5 which runs perfectly on RT-AC68U. Thanks a lot!
I'm sure that there are more than 1 person who will use caddy 2 for ARMv5. I'm the owner and developer of project SCRIPTS-BOOTLOADER-FOR-ASUS-ROUTER which aims to enhance ASUS routers. And I added caddy in my project on 2019-4-23. Unfortunately, caddy 2 drops binary for ARMv5, which makes it difficult to move from caddy version 1 to version 2.
So I really hope that caddy_2.0.0_linux_armv5.tar.gz will be added in official distributions.
Okay. So is xcaddy not something you can use? I'm glad it works perfectly!
@mholt
To be frank, I prefer to use binary from its official repository directly.
Although I can add binary in my project, I don't think it's the perfect solution. Because:
Users can never authenticate the binary compiled by me and tell whether some Malicious Code is added or not.
If you offer the binary directly, users who get contacted with caddy in my project could turn to this project easily. In this way, more users and followers will be redirected to this project. It can be good for caddy.
If my project died one day, users of caddy in my project would not be influenced since the binary they use comes from its official project directly.
This is the installation program for caddy in my project, you can see how it works.
Thanks a lot.
If we have v5 bins here, it'll also be possible to add them to the official Docker image.
Here's a PR that adds this: https://github.com/caddyserver/caddy/pull/3356
@JACK-THINK Sounds good to me. We'll add that arch.
@hairyhenderson @mholt
Thanks a lot for your contribution.