Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> * gnu/packages/databases.scm (rocksdb)[arguments]: Make #:tests? conditional.
>> Delete unnecessary 'build' phase.
>> ---
>>  gnu/packages/databases.scm | 12 +++++++++++-
>>  1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
>> index b87e8a210..e73635910 100644
>> --- a/gnu/packages/databases.scm
>> +++ b/gnu/packages/databases.scm
>> @@ -533,12 +533,20 @@ types are supported, as is encryption.")
>>                    #t))))
>>      (build-system gnu-build-system)
>>      (arguments
>> -     '(#:make-flags (list "CC=gcc"
>> +     `(#:make-flags (list "CC=gcc"
>>                            ;; Make the resulting library position-independent so the
>>                            ;; static version can be included in shared objects.
>>                            "EXTRA_CXXFLAGS=-fPIC"
>>                            (string-append "INSTALL_PATH="
>>                                           (assoc-ref %outputs "out")))
>> +       ;; Many tests fail on 32-bit platforms. There are multiple reports about
>> +       ;; this upstream, but it's not going to be supported any time soon.
>> +       #:tests? (let ((system ,(or (%current-target-system)
>> +                                   (%current-system)))
>> +                      (supported-systems '("x86_64-linux" "aarch64-linux")))
>> +                  (if (member system supported-systems)
>> +                      #t
>> +                      #f))
>
> This doesn’t work because (%current-target-system) is a GNU triplet,
> like “arm-linux-gnueabihf”, whereas (%current-system) is a “system
> type”, like “armhf-linux”.
>
> Instead you should use ‘string-prefix?’ or similar.
>
> Other than that, I think it should go in!

Well, I actually tried this recently (also disabling the individual
tests, which was a rabbit hole that ultimately gave an inexplicable
error).

Anyway, when building for i686-linux on x86_64, the compiler appears to
hit a never-ending loop at the linking stage! I'm pretty sure this was
not the case before the core-updates merge (when I tested this), so I
wonder if it's a case of
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26497 .

To be continued, but now it would just cause the build to take up a CPU
core until it times out, rather than failing early..