GNU Astronomy Utilities - Bugs: bug #51501, Compiling arithmetic-binary...
You are not allowed to post comments on this tracker with your current authentication level.
bug #51501: Compiling arithmetic-binary library memory problems on `sh4' architecture
Submitter: | Mohammad Akhlaghi <makhlaghi> | ||
Submitted: | Tue 18 Jul 2017 09:49:05 PM UTC | ||
Category: | Libraries | Severity: | 3 - Normal |
Item Group: | Crash | Status: | Postponed |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
No changes have been made to this item
Following the correction of bug #51476, Gnuastro 0.3.33 now builds successfully on all Debian architectures, except for `sh4'.
Looking at the log, the problem is apparently due to the compiler's memory.
As you can see from arithmetic-binary.c, this file in particular heavily uses macros to deal with binary operations of many different types (all signed and unsigned integer types and floats). Since compiling all these types takes a lot of time, we have defined configure time options to avoid compiling all of them if the user is in a rush to build.
But for Debian (and generally for packaging as described in the book link above), we are compiling for all types. This is because the user just downloads the compiled binaries the processing can be much faster for an arbitrary type of data.
One fast solution to this problem will probably be to disable all types for the `sh4' architecture (if it is possible in Debian, we'll have to ask). But this is not an elagant solution! It is strange for me that more than 2Gb of memory are necessary to compile Gnuastro.
Alternatively, since we are now building in parallel, probably this issue is caused because `arithmetic-binary.c' is being compiled simultaneously with arithmetic-onlyint.c (which also heavily uses macros). So an alternative solution may be to disable parallel building on `sh4' systems.
But generally, the most elegant solution would be to find a way to implement the code that this problem is not caused in the first place (if its possible).
I can't work on this now, so any contribution would be welcome. Fortunately the `sh4' architecture is not a main Debian architecture (is colored gray in the build logs). So this isn't a major issue.