darktable-org
Please support Big-endian platforms
It is also desirable to have 32-bit archs supported, but even having only 64-bit Big-endian will be good enough.
UPD. To be clear, support here implies support for current platforms (*BSD, Linux).
It would be helpful to list the platforms you have in mind, because to "support" them it is not just necessary to find and fix code that doesn't correctly works on them, but also to test it. Presumably we don't currently have any developers that have a personal interest in this, so new ones would have to commit to this effort.
@dterrahe Thank you for responding!
Literally any convenient platform which supports Big-endian can be used to test its specifics – among currently supported are FreeBSD and a number of versions of Linux. 32-bit archs are supported likewise; I believe, 32-bit (i386) Ubuntu can be set in GitHub CI.
Personally (and for Macports) I have macOS PowerPC in mind, but I do not expect anyone to test that for me or fix anything macOS-specific. That I can handle on my end.
32-bit was disabled some time ago due to virtual memory space fragmentation concerns (and general memory size limitation). I don't see why dt should go backwards here.
Big-endian is about porting processing code and could be a substantial task. Does rawspeed support big-endian platforms BTW? Anyway, it would require a new dt developer with such platform, interest to support it, and a lot of time on his/her hands.
32-bit was dropped because running in 3GB of RAM or less (the absolute maximum available) is very limiting - you wouldn't be able to process images of more than about 16 megapixels unless you restricted which modules you used.
32-bit was dropped because running in 3GB of RAM or less (the absolute maximum available) is very limiting - you wouldn't be able to process images of more than about 16 megapixels unless you restricted which modules you used.
I think 4GB can be addressed (I may be wrong though), and that exclusive to the app, since OS can use other available RAM. Perhaps better a slowly working app than a broken one? :)
Do you know if any breaking changes were made since then, or it is largely a matter of downgrading #error to #warning in configure checks of CMake?
I think 4GB can be addressed (I may be wrong though), and that exclusive to the app, since OS can use other available RAM.
There is an option to have 4GB available to the app, but it's not a standard one (custom-built kernel is required).
Perhaps better a slowly working app than a broken one? :)
Better for whom?
@parafin
Better for whom?
Well, my point was – if the app is not incompatible with 32-bit, it makes a better sense to emit a warning, not err out. This does not seem to add any extra burden to developers. Many other ports do that, when active maintenance of 32-bit is not done.
Well, my point was – if the app is not incompatible with 32-bit, it makes a better sense to emit a warning, not err out. This does not seem to add any extra burden to developers.
It does, by generating additional bug reports from users on such platforms.
It seems you are not really asking for "support" but just to allow certain platforms (arch+os combinations) to build with an appropriate warning that they are unsupported (and with whatever compile or runtime errors the existing code would generate)? Might be worth changing the issue title as you might get a different response.
The problem with warning during compilation (or configuration) is that no-one reads them, especially the users (basically no Linux package manager even shows their users the build logs). This would have to be a runtime warning, both GUI and on terminal. Why make that effort? If someone is interested in building on unsupported platform, he should have enough knowledge to remove the #error source code lines himself, otherwise better not try it at all.
build with an appropriate warning that they are unsupported
IMHO, this doesn't stop people from generating said bug reports, complaints, etc. 🤷 Warning? What warning? 😉
Well, my point was – if the app is not incompatible with 32-bit, it makes a better sense to emit a warning, not err out. This does not seem to add any extra burden to developers.
It does, by generating additional bug reports from users on such platforms.
@parafin Therefore, emit a warning that no active support for 32-bit is provided.
UPD. Okay, I am not arguing on this, I can just enable 32-bit in Macports then. The issue stands re Big-endian – ppc64 is primarily BE on all systems.
Big-endian is about porting processing code and could be a substantial task. Does rawspeed support big-endian platforms BTW?
If it does not, i would REALLY love to know about that. I've been meaning to check that (via quemu), but didn't get to. If someone has access to ppc64be, help welcomed.
On dt's side, you mainly need to rewrite all of sidecar handling -- who could've thought that storing C structs as binary blobs is a bad idea?! Oh wait, everyone did, but common sense was never so common in this project.
It seems you are not really asking for "support" but just to allow certain platforms (arch+os combinations) to build with an appropriate warning that they are unsupported (and with whatever compile or runtime errors the existing code would generate)? Might be worth changing the issue title as you might get a different response.
@dterrahe IMO it makes sense to stress Big-endianness, since it is less trivial to fix for someone who does not know the code-base well (i.e. anyone but actual developers of darktable), while allowing the build, while desirable, is trivially fixed. 32-bit support may or may not be an issue – needs to be tried out.
And yeah, as for BE, I am requesting for actual support – given that a number of current OS and platforms exist for Big-endian. Unlike, perhaps, 32-bit ones, which are not actively developed anymore.
If it does not, i would REALLY love to know about that. I've been meaning to check that (via quemu), but didn't get to. If someone has access to ppc64be, help welcomed.
@LebedevRI I do. Have to mention that it’s 10.5.8 in that case though – Apple removed ppc64 slices already in early developer builds of 10.6 :(
Well, given that we don't support deploying to OSX older than 11.3, there's no hope for that. Is this whole issue about apple specifically?
Big-endian is about porting processing code and could be a substantial task. Does rawspeed support big-endian platforms BTW? Anyway, it would require a new dt developer with such platform, interest to support it, and a lot of time on his/her hands.
@parafin Sorry, missed this part of your reply.
So, it may or may not be a substantial task. Often endianness is a matter of sane defines in a single header, which are then used where needed. Not many – perhaps very few – software really require non-trivial changes to the code to accommodate bi-endianness.
Well, given that we don't support deploying to OSX older than 11.3, there's no hope for that.
Well, I responded to your question re access. I am not asking for any kind of Mac-specific support.
Is this whole issue about apple specifically?
No, it is not. PowerPC Big-endian exists with FreeBSD, Debian etc.
FWIW, there also a few places all over imageio code that assume LE, related to e.g. TIFF/DNG, PNM/PFM...
Endianness issues should for the most part be limited to I/O. I don't remember any processing code that looks at individual bytes of values.
This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I have got 4.4.1 to build on ppc, but it does not run correctly: X window starts, but without displaying anything, and then crashes. If I run via GDB, I get this:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0000022c
[Switching to process 9962 thread 0x4703]
0x072bff18 in Auto::Zone::register_thread ()
(gdb) bt
#0 0x072bff18 in Auto::Zone::register_thread ()
#1 0x001fdcd0 in darwin_event_thread_main ()
#2 0x0592c064 in _pthread_start ()
As it has been mentioned ad nauseam in this thread, unless the codebase is actually adjusted to support big-endian, it is only natural that it does not work on non-little-endian.
@LebedevRI Yes, I know. This is just to report that the app itself is buildable. So fixing endianness is not pointless.
@LebedevRI This issue is actually unrelated to endianness. Same on x86:
@LebedevRI This issue is actually unrelated to endianness. Same on x86:
That's a rather unfortunate argument i'm afraid.
It is my understanding that only macOS 13 and newer is supported, so if you have anything older than that, it's a warranty-void situation, and you need to ask the [downstream] person who provided you with that darktable package.
This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.
OK, no one is going to benefit from a multi-year issue that gets stale every now and then, and then gets de-stale a few months later by some comments...
Deciding whether we can support a platform shouldn't take years. Everything is simple here: if we talk about support, then support always implies the capability of testing/checking the correctness of the program's operation, as well as the capability of fixing bugs on supported platforms. Currently, only you, @barracuda156, can do it, other contributors to the project do not have the capability to support Big-endian platforms (starting with a lack of hardware, let alone a lack of personal interest). So it's really about whether you want to be the team member who will ensure correct operation on Big-endian and will be able to fix bugs on these platforms.
If you are not ready to take it on, we can't really talk about real support, and talking about some implementation details here will not lead to the desired result.
This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.
Since I see no interest in contributing from big-endian people, I'm closing this issue.