Marius Bakke <mbakke@fastmail.com> writes:

> 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..

I'm still hitting some loop when building for i686-linux, but decided to
push this patch regardless to see if it works better on native platforms
(especially ARM, now that jemalloc is fixed).

Closing this bug, but will keep an eye on Hydra and open a new bug if
the build farm encounters the same problem.