[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#35666] [PATCH 0/2] Build a thread-safe hdf5 library
From: |
Ludovic Courtès |
Subject: |
[bug#35666] [PATCH 0/2] Build a thread-safe hdf5 library |
Date: |
Fri, 10 May 2019 15:07:29 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
Hi!
Ricardo Wurmus <address@hidden> skribis:
> Ludovic Courtès <address@hidden> writes:
[…]
>> It also tells you that, if you insist, you can go ahead and pass
>> ‘--enable-unsupported’, but you’re on your own.
>>
>> We found that Debian chose to pass ‘--enable-unsupported’, and indeed
>> that seems to be saner than providing a variant that does very little,
>> but does it in a thread-safe way.
>
> What other effects does “--enable-unsupported” have? I see that in
> Fedora “--enable-threadsafe” was removed in 2008 because it’s
> “incompatible with --enable-cxx and --enable-fortran”.
“--enable-unsupported” allows you to force a build that combines C++,
Fortran, and thread-safety. If you don’t pass that flag, you have to
choose between thread-safety and C++/Fortran¹. A tough choice!
> Instead they seem to be building different flavours: one with
> --enable-fortran, another with --enable-cxx, yet another with MPI and
> --enable-parallel.
Problem is, my colleagues have code that expects both C++ and
thread-safety (as crazy as it might seem). They were using the Debian
package until now and hadn’t realized about this.
> Do we have contact to the hdf5 developers to ask what the implications
> of “enable-unsupported” are?
I think it’s a warranty-void kind of flag: by passing it, the user
asserts they understand they’re using a configuration not “officially
supported” by the HDF Group, meaning that if it’s buggy, we’re on our
own.
Thoughts?
Ludo’.
¹ You would think it’s an April fool’s day prank, but it’s not! We’re
in May, at least in my timezone.