*BSD support #1206
Comments
OpenBSD. Works on FreeBSD, but I believe some patches are applied to work aruond it
Flatpak is a Linux-only thing, as is AppImage.
Hacks are required, but on OpenBSD, those hacks would be stripping out C++23 specific features.
OpenBSD, out of the box, doesn't support a Clang version that supports C++23. It may in the future, but not as of now. I'd love to submit it to the ports tree but it requires that it compiles with the base compiler. The only possible solution as of now is waiting for C++23 in OpenBSD or forcing this project to use C++20. Or patching this project, but that's quite a bit of tedious work. It's probably possible to get newer version of clang built on OpenBSD, but the version of clang for *BSD is usually modified in several ways, and it would break building other ports due to conflicting clang versions The former won't work because by the time Clang 16 lands in OpenBSD base system...... well, this project presumably would be on C++26... So, no clue. I personally don't believe OpenBSD is at fault here anyway, considering that C++23 isn't even an official release right now. This project is beta testing a C++ standard as if it's already released. It's not. It should at most hold up to C++20. I'm sure there are other linux distros out there that don't support C++23 either and are forced to use a Flatpak or AppImage. |
I'm not sure I understand this. Why would we care about other ports, if we build a newer version of clang specifically to build ImHex ? Maybe I didn't make my intentions clear : I'd like to make a OpenBSD package/OpenBSD AppImage (apparently its possible, and I'd be glad to try it: AppImage/AppImageKit#98) that would be distributed through our release page: https://github.com/WerWolv/ImHex/releases/
I never said so. I understand that it's hard to always ship the latest versions of everything, and I don't blame OpenBSD one bit. That said, without talking in the place of WerWolv, I also understand his position: its his code, his project, and part of the reason he likes to maintain it is because he can use the latest C++ stuff. And so wanting more to someone who maintain a project in their free time is not an option either |
"Ports" is the term used for *BSD's to say software. There is a ports repository which contains "Ports" (Makefiles) for software.
FreeBSD only.
I generally think it's asking less, actually. |
|
i only see two choices
In my opinion 2) is going to be much easier than 1). If you think 1) is easier then please explain why and how you would go about it because I really don't think it is possible. You mention stripping c++23 features but that's something I've never heard of before so maybe you mean 1). If not please elaborate. You also mention forcing ImHex to compile using c++20 features but that's really just 1) . You can't just force the code to compile if you are using features the compiler doesn't support. you need to modify the source code so that it doesn't use those features. That requires identifying where the program uses those features, formulate an alternative approach using c++20 features, implement that approach in code and test it to make sure it works. I don't know the particulars but you yourself mention this as "quite a tedious work", so it does not seem possible and it is not fair to ask anybody to do it. If you don't know how to implement 1) and If there is the slimmest chance that 2) could work I don't see why it shouldn't be tried but I don't know anything about OpenBSD so I cannot say what is and is not possible. What doesn't seem possible is for you to submit ImHex to the ports tree but you could be instrumental to making it available to any OpenBSD user but maybe that's not possible either and then everybody looses. I think everybody who contributes to ImHex wants to make it available to as many users as possible because we think it is top notch. I wish I could help better than just saying things here but I know my limitations and this is way beyond my abilities. |
That was my idea. C++23 isn't even a stable release yet so I feel like we should just be using C++20. Bare in mind this also prevents it from being on Debian too, so you need to install the flatpak...
I know some people that I usually contact to merge in new ports into the ports tree. Other than that you can just submit them to the mailing list. |
|
It's not impossible to build clang from trunk in a chroot and build imhex from there but looking at the hardware that most OpenBSD users seem to be equipped with(decade-old laptops with Core 2 Duos), it seems like a virtually impossible task requiring dozens of hours to compile and link(and OOM'ing ;) ) or at least a massive waste of electricity and time. Looking at https://github.com/freebsd/freebsd-ports/tree/main/editors/imhex/files it doesn't really seem like much effort is needed to compile imhex on FreeBSD, most of them seem to be patching system headers and replacing C++23 features with libraries and builtins, eg std::expected and std::unreachable() as tl::expected and __builtin_unreachable(). This might not translate to OpenBSD directly since the dependencies that imhex pulls in might not support OpenBSD which would require too much effort compared to just rebooting into a Linux installation. |
As far as I know, this port also requires 64 bit cpu's. On FreeBSD there is a flag preventing it from compiling on i386 systems. So yes, portability would be haltered there too. Building Clang yourself is not a very fun solution to any such cases. As far as I know though, I guess I could try to merge some of FreeBSD's patches and work around some stuff to get it building on OpenBSD with C++20... (From what I am looking at, they don't support C++23 either so they just use older features) but I still personally feel like using C++23 is still too modern considering it is still a draft document, and that prevents it from being on Debian as well (except for Flatpaks and AppImage). For now, I feel as if rebooting into Linux is fine because once I finish my personal task, I probably won't be touching this software for a while. |
My idea was more to provide *BSD users with an already compiled binary, by cross-compiling from our CI, so they wouldn't have to compile anything. Maybe that would be a problem for them tho ? By the way, isn't there a Linux compatibility layer in *BSD ? Why doesn't that work here ? |
In all honesty, if you're trying to run ImHex on a machine like that you will most likely have a really bad time anyways.
C++23 has been finalized in March already, the only thing that hasn't happened yet is it being published as an ISO standard. The reason why I'm so reluctant with all of this is because I had a bunch of people argue about me even using anything newer than C++11 already "because all the new shit is complete garbage anyways and shouldn't be used". When I start giving in to these kind of requests, more and more people will come and want me to support lower C++ versions just so it can run on their own favorite and obscure distro / OS. And that will just take away a big part of why I enjoy working on ImHex. I haven't ever used BSD myself and it's not officially supported simply because it just lacks modern tools that I want to use. If we want to officially support BSD, the best course of action, in my personal opinion, is to simply have our CI somehow build a package that people can install then. That's the compromise I'm happily willing to make. If that's still not enough though and you absolutely want to be able to build ImHex yourself, then that's honestly not my problem anymore. |
Cross-compiling will not be easy as compiling FreeBSD software from Linux is already a pretty obscure topic which really doesn't have much information about it, and OpenBSD even more so. There are some CI services(eg Travis) that provide FreeBSD runners but they seem to use older releases of it. Also I have to mention this is a non-issue because a "port" will be compiled as an official package if it's FOSS(https://www.freshports.org/faq.php#package). Think of FreeBSD as something like if Arch Linux used a single repository for both the AUR and official repos, and only the FOSS ones get compiled into binary packages installable with pacman. So there's no need to care about releasing binaries from imhex' side, the package people will do their job. I'm not entirely sure about how OpenBSD does it but I don't think it's any different(@nekobbbbbbit, please correct me if I'm wrong).
FreeBSD does support the "Linuxulator" which can run Linux software but even the latest release of FreeBSD only supports up to Linux 4.4.0 which I can only describe as mediocre. OpenBSD doesn't have that feature at all presumably due to ideological/security reasons. Either way I don't think it's a relevant way to run ImHex on *BSD systems.
Fair enough, but those types of people tend to lack knowledge of C++ in general and make clowns of themselves. I recommend ignoring such people entirely, since they mostly do not engage in constructive conversations.
I propose closing this issue since it doesn't seem to be going anywhere with no real conclusion. The FreeBSD people already have imhex in their official package repositories(even though it's not "officially" supported) through the ports tree so I don't see why the same could be applied to OpenBSD with enough effort from someone who is willing to do the work(obviously nobody here(including me since I don't use *BSDs anymore) seems to be willing to go through the effort of maintaining a port anyways), all without modifying ImHex' master branch. |
I'm not sure about this, because as @nekobbbbbbit said, I'm pretty sure OpenBSD will often/always lag behind in terms of compiler version, meaning ImHex will never be able to be compiled with "official" compilers. Plus, that doesn't cover other *BSD distributions
Actually, I just spinned up a OpenBSD VM this morning, and I'm trying to figure out how ports work right now. Partly because I'd like ImHex to have a *BSD binary, but also because I always wanted an excuse to learn *BSD stuff, and this issue is kinda my excuse. So, taking on account what you said, my current plan is roughly:
I don't promise anything, but until I do it/give up, I think I'd like this issue to stay open Once I give up, idk if the issue should stay open/be closed as not planned. We'll see then, I guess |
*BSD's are not binary-compatible. They aren't like Linux distributions where they have a central kernel and you can just repackage other distros' packages to run on your system if there wasn't a breaking change in glibc or something. They're different operating systems with different kernels and everything, it's just that they have similar ways to install packages and some old UNIX code they share(iirc). |
|
Oh.. Well, I wasn't expecting that. I guess my whole idea isn't possible Since you are here, and seem to have a lot of knowledge about this, may I ask you another, completely off-topic question ? Weirdly enough, I can't find the answer on this Internet If FreeBSD and OpenBSD (and Linux, while we are at it) are POSIX compliant, and use the same executable format (ELF), apart from dynamic libraries issues, why can't a FreeBSD binary run on OpenBSD ? |
|
Hello, I'm the maintainer of the FreeBSD ImHex port. There are two approaches to building ImHex on FreeBSD.
I tried building ImHex with GCC and libstdc++ in the past. Though I was able to build it with significantly fewer modifications to ImHex source code, ImHex crashed at startup and it was not able to run because ImHex was linked with both libstdc++ and libc++. Its library dependencies were built with Clang and libc++ at that time. ImHex may be able to run if I build it and all library dependencies with GCC and libstdc++, but there are many library dependencies, and building all of them with GCC and libstdc++ makes package building very complex. So I take the first approach. FreeBSD (13-stable and 14-current) currently uses LLVM 16. OpenBSD uses LLVM 13 according to this discussion. I suppose that building ImHex on OpenBSD is more painful than on FreeBSD. Building ImHex on FreeBSD requires hard work because libc++'s support of C++20 and C++23 functions is far behind libstdc++. However, I don't ask ImHex developers to avoid using C++20 and C++23 functions because such requests will slow down ImHex development. |
I'm not asking you use something as older as C++11. That's a stupid argument, most everyone uses at least C++11 these days. I disagree that new version are "worse", really far from true, but we really do need some time for things to stabilize I am asking to go back to C++20 at the most. It's not even that old, and I don't personally believe you desperately need C++23 features now as in accordance with the FreeBSD response above. I understand new version provide new features, but C++20 provided a lot of what we want and I don't see why holding back from C++23 is such a difficult choice. Officially released or not, it's still fresh off the grill and will take a bit to be available for people.
Might as well just not even provide the source code with that remark. How do you think your software even gets packed on other distros? People have to compile it manually. Bare in mind, it's still not in Debian's repositories, and that's pretty embarrassing considering Debian 12 just got released recently.
I've used some of the nicer C++20 functions on OpenBSD with ease. I'm not sure about FreeBSD's case. I think trying to patch this software to not use C++20 features is definitely seeming to be the only way for me to package it, since dev seems reluctant for a stable C++ version. It's worth noting that LLVM 13 to 16, while quite the dramatic jump, is not but 2 years apart.
You are correct, porting system is similar between all the *BSD's in all honesty.
The reasoning for this is mostly history. All the *BSD's are based off the BSD4.4 (Lite?) systems. NetBSD and OpenBSD are almost interchangeable, due to OpenBSD being a fork of NetBSD (but it has branched apart). FreeBSD though has mostly strayed on it's own path. They all have different compiler versions, libraries, documentation (docs are very good on the *BSD's, IMO, which is usually a compelling reason many people like to use *BSD's for C/++ development). The *BSD's aren't like Linux Distributions. The BSD's also have different goals. FreeBSD strives for high-tier performance and great filesystem support with ZFS (this doesn't work on Linux due to license issues), OpenBSD aims for security and simplicity, good documentation and a decent base system, and NetBSD focuses on portability (and some security) For the most part, they do function quite similar and all try to remain more in the spirit of UNIX than Linux does. Also, yes, FreeBSD and NetBSD support Linux compatibility layer, which probably will allow it to be run that way too. Also Wine, but ain't that a rock in the boot... I'm tired of this debate and I will just patch it to not use newer C++ features much like how FreeBSD does it. Hell, I could probably snag some of their patches and tweak them a little bit. But I think this fresh-off-the-grill versioning decisions may hurt some of the userbase of this software in the long run. Most *BSD users are used to patching software here and there, but it's always healthy to take it directly to the repository before applying any manual patches that couldn't possibly be moved to upstream. My intention with the discussion was to see if I could avoid doing any patches if I didn't need to. |
|
@nmantani Thanks your your insight ! It's really interesting to know how you got ImHex to build on FreeBSD Though, as per the reply on binary compatibility, I don't think I'll do anything, since it would mean building one package per BSD flavor (and maybe even per version). I was more sold on the idea of one AppImage-like package for *BSD. FreeBSD is probably the most common flavor, and is already covered by you Off-topic: Since this is the first time we get to talk to you (I think), I'd like to point out that if you ever need so, we are generally happy to at least discuss ideas to make ImHex easier to package, so if you ever need help/would like us to make adjustments for you (in this case, other than changing the C++ standard), feel free to ask us ! Be it by discord/github/email Thanks for your work |
|
Closing this since there isn't any actions that ImHex could take to help |
|
Just FYI, I have added editors/imhex-current FreeBSD port (commit) for ImHex 1.33.1. This port can be built only on FreeBSD 15-current, 14-stable, 13-stable, or upcoming 13.3-RELEASE that has libc++ of LLVM 17 on the base system. editors/imhex port remains at version 1.30.1 to support older FreeBSD versions. Thanks to the C++ function support improvement of LLVM 17, the number of patches of editors/imhex-current port is greatly reduced compared with the editors/imhex port. |
|
@nmantani Thanks a lot! That's really cool! |
Hey @nekobbbbbbit , I'm moving this here because I'd like to discuss *BSD support in particular
You seem to imply that running ImHex on (some ?) *BSD systems is impossible (or maybe just not easy ?), and I'd like *BSD users to be able to use ImHex without problem.
In this issue, I'd like not to discuss using C++20 in our codebase, but rather the other steps we could take to help *BSD users
Please keep in mind that I've never used *BSD, and I know nothing of it, apart from the fact it implements UNIX just like Linux.
A few startup questions:
The text was updated successfully, but these errors were encountered: